pretty awesome, bnms. thank you.

this might be useful.

your boot arguments are:

bootargs_console=console=ttyS0,115200
bootargs_root=rootdelay=30
bootcmd_usb=usb start; ext2load usb 0:1 0x01100000 /uInitrd; ext2load usb 0:1 0x00800000 /uImage
bootcmd=setenv bootargs $(bootargs_console) $(bootargs_root); run bootcmd_usb; bootm 0x00800000 0x01100000; reset

you are not specifying a root; bootargs_root should look something like 'root=/dev/sda2 rootdelay=10'.

the details are dependent on whether or not you are booting your kernel from NAND or from usb/sd.

boot into your environment
download the appropriate README from here (wget http://sheeva.with-linux.com/sheeva/README-2.6.33)

for nand:
1) run the readme with --nandkernel option (bash ./README-2.6.33 --nandkernel)
2) create or modify the file /etc/sysctl.d/10-process-security.conf and add the following line: 'vm.mmap_min_addr = 32768'
3) reboot
4) interrupt uboot and ensure you have the following parameters defined (printenv): mainlineLinux=yes; arcNumber=2097. otherwise 'setenv mainlineLinux yes' then 'setenv arcNumber 2097' and 'saveenv' then 'reset'

for usb/sd:
1) make sure your /boot is mounted
2) run the readme with --rootkernel option (bash ./README-2.6.33 --rootkernel)
3) take note of the message it leaves act accordingly (cd /boot && mv uInitrd uInitrd_bak && mv uImage uImage_bak && ln -s sheeva-2.6.33-uImage uImage)
4) create or modify the file /etc/sysctl.d/10-process-security.conf and add the following line: 'vm.mmap_min_addr = 32768'
5) reboot
6) interrupt uboot, record your current boot parameters, then change your boot parameters to remove uInitrd similar to as described here
7) ensure you have the following parameters defined (printenv): mainlineLinux=yes; arcNumber=2097. otherwise 'setenv mainlineLinux yes' then 'setenv arcNumber 2097' and 'saveenv' then 'reset'

alternately, you can not run the commands in usb/sd step 3 and instead modify the the boot parameters in step 5 to refer to sheeva-2.6.33-uImage instead of uImage

can you post the output of a printenv at the uboot prompt?

the progression goes:

2.6.32
2.6.32.1
...
2.6.32.12 (until they decide to rollover to .33)
2.6.33
2.6.33.1
...

if you notice the dates on the kernel directories at http://sheeva.with-linux.com/sheeva/, 2.6.31 is located in the sort order after 2.6.31.12 but by date falls between 2.6.30.9 and 2.6.31.1. i don't know for sure but i would assume that the 2.6.32.x revs are all bug fixes/security updates to the major changes brought up in 2.6.32. 2.6.33 then brings new things and gets bug fixes as well. theoretically then, the last .x build would be the most stable compared to a non-.x build.

this is just post-drinking conjecture, mind you.

oh, found a link (http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering).

shplug: based on this you will need to use backports if you are using lenny? (i think; not super familiar with debian)

here's a link which doesn't directly apply to the plug, but is good for reference. i've never edited the boot commands to go into single user mode, but you could try that. doing something like booting a kernel pointing to a usb/sd root and then mounting and editing /etc/passwd or /etc/shadow on NAND should work.

here's more on the passwd and shadow files.

darkscout: the solution you found is the correct one. as long as you did a saveenv, you shouldn't need to mess with the serial console anymore. on subsequent kernel updates you will just need to rename/link the updated kernel so that it is found by uboot.

i am assuming you are running everything from NAND (internal memory chip). formatting to ubifs will erase NAND so you would want to copy your system to a usb stick/sd card first in order to be able to restore it. upgrading the kernel would also require you to write it to NAND. if you are using the sheeva.with-linux.com kernels, running the README with --nandkernel takes care of it automatically.

i find myself continually linking this guide because it seems to do a good job explaining things.

try the wiki. that refers to a pdf; there's also another wiki entry that details it as well.

i would advise against performing any actions until reading what you can to become comfortable with the process.

the only thing i was trying to point out is that


is wrong and should instead be


even though you aren't using it in your boot command, you should be aware of the possibility of environment variable corruption.

i believe this is also a problem:
as per this link it looks like pintoo's patched .27 uboot is the way to resolve this. i've been using .19 without any problems, however.

good catch, pingtoo. i looked over that with bleary eyes and had no idea.

hideoushog, the saveenv is writing the uboot environment variables to NAND. the reset is restarting uboot as would happen if you were to cycle power on the sheeva.

once you do the saveenv, you shouldn't have to do


ever again.

likewise, if the following worked:


you should reboot, update bootcmd_sd and bootargs_sd appropriately based on what's above, saveenv, reset and be done.

the default daily cronjob involving dpkg is trying to write to /var/backups, so i added this to my ramstore.

i found this link for setting up tmpfs fstab entries similar to how cjm has them.

since flashybrid creates tmpfs mounts and does the syncing, the options we have :

1) stay with flashybrid and use the rc.local restart workaround
2) put tmpfs entries in fstab and a) comment out flashybrid parts that create the tmpfs mounts or b) write your own scripts to sync (i think the link above actually has a script that does this)