On Sat, Mar 29, 2008 at 3:44 PM, Benjamin Kircher < [EMAIL PROTECTED]> wrote:
> > On Thu, Mar 27, 2008 at 5:00 PM, Andrew Sackville-West < > [EMAIL PROTECTED]> wrote: > > > 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 > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.6 (GNU/Linux) > > > > iD8DBQFH68SiaIeIEqwil4YRAg5cAKCUit3yyl47C5TQUEdzBbc6t4xXtwCdGwSl > > VFJplL3c2mRDs2MIbP6Xw5U= > > =YJYt > > -----END PGP SIGNATURE----- > > > > > > > Hi Andrew, > > > I'm not able to activate lvm from within busybox, a "vgchange -ay group0" > gives me: > /proc/mounts: fopen %s failed: No such file or directory > /proc/devices: fopen failed: No such file or directory > Failed to create lvm type filter > > /proc and /dev (except /dev/console) are empty like the ocean. > > I think you're right: My initrd is really f'd up. The first lines I > noticed during boot up: > /init: line 11: mount: not found > cat: can't open '/proc/cmdline': No such file or directory > ... > /scripts/init-top/framebuffer: line 100: mknod: not found > ... > /init: line 157: printf: not found > ... > > I took a look at the initramfs-tools bug page and couldn't find any > similar reports. I'll do some further investigations (need to know how > initramfs works in detail). > > > Benjamin > Okay, I got it. My bad. I purged the running kernel while installing the new one, which leaves my initrd image broken and the system unbootable. Well, I did this every time without problems... until Wednesday. So the correct procedure is to install the new kernel first, then reboot with the new one and finally purge the old one. Next time I do such a stunt, I'll examine the contents of the initrd first. Cheers anyway! Benjamin
