On Wed, Mar 26, 2008 at 08:32:50PM +0100, Benjamin Kircher wrote: > Hi there, > > > need some advice over here. Installed Etch from netinstall iso and upgraded > to sid, which works flawlessly. All partitions except /boot are in a LVM > group (even my root fs is a LVM volume). Then I removed (more precise: > purged) 2.6.18-5-486 kernel in favor of 2.6.24-1-686. After running a > "update-initramfs -u" and a "shutdown -r now" my box fails to boot up. It > complains: > > (nah nah nah, a lot of this not and a lot of that not, neh neh ney) > ... > /scripts/local-top/lvm2: line 68 tr not found > /scripts/local-top/lvm2: line 68 sed not found > (I guess, this part of the script tries to activate my volume group) > ... > /proc/mounts: fopen %s failed: No such file or directory > Failed to create lvm type filter > Waiting for root file system ... > > ... which my box never gets. Hereafter it throws me to a very limited shell. > Indeed, /proc and /dev are empty ;( Hey wow! I'm seeing this too (though i can boot). I thought it was from moving to an amd64 kernel on i386 userland. But apparently not. It seems that the initrd environment is broken at the moment. I'm not sure, maybe it's ash (I think that's the initrd shell) that's broken. You'll notice that this limited shell (busybox) doesn't function properly -- ls doesn't exist for example. But you can fake it with `busybox <cmd>` to get it to execute. So, for example, to get an ls of the current directory, use `busybox ls` and there it will be. So to boot this thing, you need to duplicate the processes that happen in the initrd phase. This means you need to activate your lvm and possible any encrypted stuff (if you have encryption as well, let me know and we'll work through that). to activate lvm, do this from the busybox shell: vgchange -ay <name-of-volume-group> -ay for "activate yes" essentially. this will create your volume group in /dev/mapper. Check it with busybox ls /dev/mapper if that's working, then you should be able to just exit the busybox shell and your boot should continue. Essentially, certain necessary functions are missing from the initrd causing these scripts to fail. It should be fairly simple for you to get booted, and once that's done just stay up until a fix comes through, or keep track of what you did to successfully boot so you can reproduce it. And this warrants a bug report, if one doesn't exist already. hmmm... a little quick searching doesn't reveal anything specific. I would file it with initramfs-tools as they know who get's included in the initrd and can forward it on if required. A
Attachment:
signature.asc
Description: Digital signature