bodhi, while I am fiddling around with the OXNAS boxes, I naturally also wanted to try this. However, it looks like this is not working either for me, because I get very much the same result I get when I try to influence ethaddr during the boot process (either with uEnv.txt or through a setenv hidden in another procedure during boot). I.e., the box seems to boot (eventually the LED becomes greby chessplayer - Rescue System
bodhi Wrote: ------------------------------------------------------- > chessplayer, > > > Thus, with netconsole still not working, the > only > > solution is to set the MAC address in > > /etc/network/interfaces. > > Do this first to get it running. Then SSH in, set > up netconsole. In netconsole set the ethaddr > variable. See if it is allowed.by chessplayer - uBoot
Continued ... So, it seems that the box takes offense when I try to overwrite the ethaddr using uEnv.txt. If the file holds other settings, that seems to be ok. Thus, with netconsole still not working, the only solution is to set the MAC address in /etc/network/interfaces. What I am currently wondering is whether it would not be better to read uEnv.txt before the boot process, so as part ofby chessplayer - uBoot
bodhi Wrote: ------------------------------------------------------- > chessplayer, > > > > > the question remains why you suggest setting up > > the boot env like this in step 6 of your > > > FTD > kernel thread: > > Thanks for raising this question! I simply forgot > to update the kernel thread to mention that if you > have installby chessplayer - uBoot
bodhi Wrote: ------------------------------------------------------- > Regarding the ethaddr setting, I'll take look > later to see why it could not be set in Debian. Maybe this gives a clue: Debian bug report Cheers, chessplayerby chessplayer - uBoot
bodhi, the question remains why you suggest setting up the boot env like this in step 6 of your FTD kernel thread: fw_setenv uinitrd_addr '0x60e00000' fw_setenv uimage_addr '0x60500000' fw_setenv dtb_addr '0x62c00000' fw_setenv usb_set_bootargs 'setenv bootargs console=ttyS0,115200 root=/dev/sda1 rootdelay=10' fw_setenv dt_bootm 'bootm $uimby chessplayer - uBoot
LeggoMyEggo, thanks for your suggestion. I must have updated my post in parallel, since I figured out this solution as well. And, actually, I just used the drive I had, did the renaming, booted the box, corrected the uBoot environment, reverted the renaming and that was it. Too easy, but it is getting late (early) ... Cheers, chessplayerby chessplayer - uBoot
Some Issues + Stupidity So, I got both my B04 and my Pro boxes working with one and the same USB drive. Then I ran into the problem of not being able to set the ethaddr with fw_setenv as reported earlier. Unfortunately, netconsole is not working either for those two boxes (although it is for the Kirkwoods I have ...; why???). At first, it seemed that using uEnv.txt I was able to get aroundby chessplayer - uBoot
bodhi, thanks for getting back so quickly. One question (since this is beginning to look a bit like a hen and egg problem): after flashing new uboot, will it still be possible at all to boot the old system (WarheadsSE kernel + Debian Squeeze)? Or do I have to do more or less everything in one step: a1) flash new uBoot a2) install new kernel + rootfs a3) reboot Not quite sure at the moby chessplayer - uBoot
Hi bodhi, once again, thanks for all the work you put into these boxes. In the sense of "triple checking", let me do this here. As in rynax's case, I get $ cat /proc/mtd dev: size erasesize name mtd0: 08000000 00020000 "NAND 128MiB 3,3V 8-bit" mtd1: 00e00000 00020000 "boot" mtd2: 07200000 00020000 "rootfs" In addition, I am not qby chessplayer - uBoot
My apologies ... to anyone who read and thought about the ANSI_X3.4-1968 problem. The solution was so easy and damn obvious, that I feel more than just a little embarrassed. It turns out that the locales package was installed, but not configured correctly in that the default language was not set. So dpkg-reconfigure locales with setting German as the default language did the trick ...by chessplayer - Debian
bodhi Wrote: ------------------------------------------------------- > chessplayer, > > The clue here is > > May 2 01:07:32 3.14.0-VDR user.debug vdr: [3552] > found 0 locales in /usr/share/locale > > > It seems to indicate that the locale on that > 3.14.0-tld-2 system was not properly installed > somehow. Because if you follow the standard > prby chessplayer - Debian
bodhi Wrote: ------------------------------------------------------- [... snip ...] > > It seems you don't have any locale in your new > 3.14.0-tld-2 rootfs (kernel does not have any > locale specific stuff). [... snip ...] Hi bodhi, sorry for not making this clear in my earlier post: I do have locales installed on both systems. I get the following from locale in bby chessplayer - Debian
More serious matters Hi bodhi, I am currently in the process of testing the latest VDR on my plugs. Most of the things work fine, but the web interface never uses the German language as it does on my "production systems", but rather defaults to English. The production systems are still running your 3.8.11-tld-3 kernel and Wheezy 7.1. So, I had a look in the syslog and found theby chessplayer - Debian
bodhi Wrote: ------------------------------------------------------- > Hi chessplayer, > > Here is the patched > linux_logo. > md5: > 7ae1817502a0246e49616d07e6df4e8c > > Run this on your boxes and let me know what you > see :) if you see no problem with it, you can > replace this binary where it is installed (e.g. > usr/local or where you've deby chessplayer - Debian
Hi bodhi, thanks. I am at work right now, so will test later today. P.S.: Don't you have anything better to do than giving other people their broken toys back? ;-))by chessplayer - Debian
Hi bodhi, thanks for looking into it. And I actually do not do anything to get the info: it is the program called linuxlogo which is installed via the package by the same name, as I already pointed out in my original post on the subject. So I guess the developer should be informed, which is what I just did. Whether there is going to be an update, however, I do not know, since the software wby chessplayer - Debian
A (very, very) small matter Hi bodhi, first of all, thanks once more for all the effort you are putting into supporting our little toys! I just germanized and beautified your basic install, as I always do to get my own base system. It booted ok, can't say anything about stability, though. Will test VDR on it soon. One thing is strange, however. Compared with the last of your kernby chessplayer - Debian
Ok, thanks. I guess you will be announcing here when this is done. Until then, I will keep myself occupied with updating kernels ...by chessplayer - uBoot
Hi guys, in case you were wondering: yes, I am still alive ... Also, I am hoping to be able to play around with my Kirkwood machines a little again in the next few weeks (and maybe stay online, at least intermittently, even after that). Which is why I would like to ask two things: a) What is the current status concerning consolidation? Especially, what about the NSA3xx? According to the curby chessplayer - uBoot
Hi Bodhi, this is what uBoot is saying: U-Boot 2011.12 (May 03 2012 - 17:04:23) ZyXEL NSA320 2-Bay Power Media Server arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2009q3-67) 4.4.1 GNU ld (Sourcery G++ Lite 2009q3-67) 2.19.51.20090709 Hit any key to stop autoboot: 0 About the LEDs: no, they are not quite ok. Only the top one and the USB LED show up at all; to start with, they are bby chessplayer - Debian
Hi, I know for a fact (learned the hard way) that if the server is not reachable (in your case 192.168.11.149), it will seem as if the thing does not boot. After over an hour, it might actually relent and boot ... So, for some reason, the ZyXel does not just skip that part then, but hangs there seemingly forever. So try either setting the serverip to your router's address (probably 192by chessplayer - Debian
@bodhi, thank you very much for providing the tarball dated June 19th. I "germanized" it and tried it on all types of machines I have (Dockstar, GoFlex Net/Home, Pogoplug, NSA320) and all worked very well. I especially like the fact that on most of the machines the LED flashes during boot and will be solid green when fully booted. On the Zyxel, things seem a bit different, but sinceby chessplayer - Debian
sxk Wrote: ------------------------------------------------------- ... snip ... > blinks furiously for a little > while and then sits there - no ip or anything on > router. ... snip ... This could possibly be a problem with 70-persistent-net.rules (see this post; didn't help there, but problem seems to have been different).by chessplayer - uBoot
@nick2012, it would definitely help to know which tarball you are talking aboutby chessplayer - Debian
@wolfgangn, when updating to wheezy just the other day, I ran into a problem I had long since forgotten: when using the same stick on different machines, it seemingly leads to the second one not "booting", when, in fact, it just does not get an IP-Address. In netconsole, it will look as if it was stuck at "Starting kernel ..." The reason is the file /etc/udev/rules.d/70-by chessplayer - Debian
@bodhi: this worked, thanks. But even better: your 3.8.11 kernel boots the Zyxel NSA320 (see here). Great!by chessplayer - Debian
@bodhi, you are my hero. Things worked out with some gotchas: First, I downloaded the file from your link above. However, the archive manager complained, that this was not a bzip-file and would not open it. By sheer coincidence, I renamed it to ...gz2 (instead of ...bz2) and voilá, it opened. So I repacked and transferred to the USB-Stick, where I unpacked it. Then I did the following:by chessplayer - Debian
@bodhi, I will do that, but it may take until tomorrow night.At the same time, I will try your advice concerning the wheezy upgrade. In any case: thanks a real lot for your efforts!by chessplayer - Debian
Hi bodhi, thanks for the reply. To clarify: why do you say "similar"? Do I have to somehow determine the parameters after the -C -a and -e options or can I take the ones you posted without further checking (getting a bit more cautious now after bricking my NSA325 despite better advice from WarheadsSE ...) chessplayerby chessplayer - Debian