debian 6.0 boot failure after update to grub2
Hi there,
I have a debian server that doesn't boot anymore since I ran upgrade-from-grub-legacy. It uses xen. I managed to upgrade to Debian 6 and got everything working. Well, a power outage caused my domUs to not boot anymore and while trying to deal with that I also figured I didn't complete the upgrade to grub2 and thought it might fix things. Well, now nothing boots anymore. The main issue appears to be that it can't find the root device for some reason. The grub2 menu shows up, I can select boot options, some of those seem to boot but can't find the root device (the very disk grub2 and everything else is on). I tried adding "dummy=dummy" as the first parameter in the grub.cfg file for "multiboot" and all occurrences of"module", but that didn't help. (from: http://wiki.xensource.com/xenwiki/XenCommonProblems#head-d038e27f4f3ad6b96ef1643c1812237cb1408730) On a sidenote, vga out on the server doesn't seem to work, so I'm trying to boot in qemu. As a consequence I get mdadm errors because the raid disks aren't present, but since those are used for data storage only to my knowledge this shouldn't matter. Any advice on how to get the system to boot again is appreciated. Regards, Philipp -- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: 1309006321-sup-5676@eris">http://lists.debian.org/1309006321-sup-5676@eris |
debian 6.0 boot failure after update to grub2
Excerpts from Philipp's message of 2011-06-25 15:12:26 +0200:
> Hi there, > I have a debian server that doesn't boot anymore since I ran > upgrade-from-grub-legacy. It uses xen. I managed to upgrade to Debian > 6 and got everything working. Well, a power outage caused my domUs to > not boot anymore and while trying to deal with that I also figured I > didn't complete the upgrade to grub2 and thought it might fix things. > Well, now nothing boots anymore. > > The main issue appears to be that it can't find the root device for some > reason. The grub2 menu shows up, I can select boot options, some of > those seem to boot but can't find the root device (the very disk grub2 > and everything else is on). > > I tried adding "dummy=dummy" as the first parameter in the grub.cfg file > for "multiboot" and all occurrences of"module", but that didn't help. > (from: > http://wiki.xensource.com/xenwiki/XenCommonProblems#head-d038e27f4f3ad6b96ef1643c1812237cb1408730) > > On a sidenote, vga out on the server doesn't seem to work, so I'm trying > to boot in qemu. As a consequence I get mdadm errors because the raid > disks aren't present, but since those are used for data storage only to > my knowledge this shouldn't matter. > > Any advice on how to get the system to boot again is appreciated. > > Regards, > Philipp Just to add a little more information: The system waits for the root file system for a while and then drops into a shell with the (initramfs) prompt. There's no /dev/sd* or /dev/disk for some reason. The currently installed kernels are: vmlinuz-2.6.32-5-xen-amd64 vmlinuz-2.6.26-2-xen-amd64 vmlinuz-2.6.26-2-amd64 None of those boots. Following is my current grub.cfg Thanks for any hints. Regards, Philipp ### BEGIN /etc/grub.d/00_header ### if [ -s $prefix/grubenv ]; then load_env fi set default="0" if [ "${prev_saved_entry}" ]; then set saved_entry="${prev_saved_entry}" save_env saved_entry set prev_saved_entry= save_env prev_saved_entry set boot_once=true fi function savedefault { if [ -z "${boot_once}" ]; then saved_entry="${chosen}" save_env saved_entry fi } function load_video { insmod vbe insmod vga insmod video_bochs insmod video_cirrus } insmod part_msdos insmod jfs set root='(/dev/sdd,msdos1)' search --no-floppy --fs-uuid --set 4745f09d-c277-4113-b84a-898fa406e61f if loadfont /usr/share/grub/unicode.pf2 ; then set gfxmode=640x480 load_video insmod gfxterm fi terminal_output gfxterm insmod part_msdos insmod jfs set root='(/dev/sdd,msdos1)' search --no-floppy --fs-uuid --set 4745f09d-c277-4113-b84a-898fa406e61f set locale_dir=($root)/boot/grub/locale set lang=en insmod gettext set timeout=5 ### END /etc/grub.d/00_header ### ### BEGIN /etc/grub.d/05_debian_theme ### set menu_color_normal=cyan/blue set menu_color_highlight=white/blue ### END /etc/grub.d/05_debian_theme ### ### BEGIN /etc/grub.d/20_linux_xen ### menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-xen-amd64 and XEN 4.0-amd64' --class debian --class gnu-linux --class gnu --class os --class xen { insmod part_msdos insmod jfs set root='(/dev/sdd,msdos0)' search --no-floppy --fs-uuid --set 4745f09d-c277-4113-b84a-898fa406e61f echo 'Loading Linux 2.6.32-5-xen-amd64 ...' multiboot /boot/xen-4.0-amd64.gz /boot/xen-4.0-amd64.gz placeholder module /boot/vmlinuz-2.6.32-5-xen-amd64 placeholder root=UUID=4745f09d-c277-4113-b84a-898fa406e61f ro echo 'Loading initial ramdisk ...' module /boot/initrd.img-2.6.32-5-xen-amd64 } menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-xen-amd64 and XEN 4.0-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os --class xen { insmod part_msdos insmod jfs set root='(/dev/sdd,msdos1)' search --no-floppy --fs-uuid --set 4745f09d-c277-4113-b84a-898fa406e61f echo 'Loading Linux 2.6.32-5-xen-amd64 ...' multiboot /boot/xen-4.0-amd64.gz /boot/xen-4.0-amd64.gz placeholder module /boot/vmlinuz-2.6.32-5-xen-amd64 placeholder root=UUID=4745f09d-c277-4113-b84a-898fa406e61f ro single echo 'Loading initial ramdisk ...' module /boot/initrd.img-2.6.32-5-xen-amd64 } menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-xen-amd64 and XEN xen_domU_initrd_xfs.img' --class debian --class gnu-linux --class gnu --class os --class xen { insmod part_msdos insmod jfs set root='(/dev/sdd,msdos1)' search --no-floppy --fs-uuid --set 4745f09d-c277-4113-b84a-898fa406e61f echo 'Loading Linux 2.6.32-5-xen-amd64 ...' multiboot /boot/xen_domU_initrd_xfs.img placeholder module /boot/vmlinuz-2.6.32-5-xen-amd64 placeholder root=UUID=4745f09d-c277-4113-b84a-898fa406e61f ro echo 'Loading initial ramdisk ...' module /boot/initrd.img-2.6.32-5-xen-amd64 } menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-xen-amd64 and XEN xen_domU_initrd_xfs.img (recovery mode)' --class debian --class gnu-linux --class gnu --class os --class xen { insmod part_msdos insmod jfs set root='(/dev/sdd,msdos1)' search --no-floppy --fs-uuid --set 4745f09d-c277-4113-b84a-898fa406e61f echo 'Loading Linux 2.6.32-5-xen-amd64 ...' multiboot /boot/xen_domU_initrd_xfs.img placeholder module /boot/vmlinuz-2.6.32-5-xen-amd64 placeholder root=UUID=4745f09d-c277-4113-b84a-898fa406e61f ro single echo 'Loading initial ramdisk ...' module /boot/initrd.img-2.6.32-5-xen-amd64 } menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-xen-amd64 and XEN xen_domU_initrd_xfs_raid.img' --class debian --class gnu-linux --class gnu --class os --class xen { insmod part_msdos insmod jfs set root='(/dev/sdd,msdos1)' search --no-floppy --fs-uuid --set 4745f09d-c277-4113-b84a-898fa406e61f echo 'Loading Linux 2.6.32-5-xen-amd64 ...' multiboot /boot/xen_domU_initrd_xfs_raid.img placeholder module /boot/vmlinuz-2.6.32-5-xen-amd64 placeholder root=UUID=4745f09d-c277-4113-b84a-898fa406e61f ro echo 'Loading initial ramdisk ...' module /boot/initrd.img-2.6.32-5-xen-amd64 } menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-xen-amd64 and XEN xen_domU_initrd_xfs_raid.img (recovery mode)' --class debian --class gnu-linux --class gnu --class os --class xen { insmod part_msdos insmod jfs set root='(/dev/sdd,msdos1)' search --no-floppy --fs-uuid --set 4745f09d-c277-4113-b84a-898fa406e61f echo 'Loading Linux 2.6.32-5-xen-amd64 ...' multiboot /boot/xen_domU_initrd_xfs_raid.img placeholder module /boot/vmlinuz-2.6.32-5-xen-amd64 placeholder root=UUID=4745f09d-c277-4113-b84a-898fa406e61f ro single echo 'Loading initial ramdisk ...' module /boot/initrd.img-2.6.32-5-xen-amd64 } ### END /etc/grub.d/20_linux_xen ### ### BEGIN /etc/grub.d/30_os-prober ### ### END /etc/grub.d/30_os-prober ### ### BEGIN /etc/grub.d/40_custom ### # This file provides an easy way to add custom menu entries. Simply type the # menu entries you want to add after this comment. Be careful not to change # the 'exec tail' line above. ### END /etc/grub.d/40_custom ### ### BEGIN /etc/grub.d/41_custom ### if [ -f $prefix/custom.cfg ]; then source $prefix/custom.cfg; fi ### END /etc/grub.d/41_custom ### ### BEGIN /etc/grub.d/50_linux ### menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-xen-amd64' --class debian --class gnu-linux --class gnu --class os { insmod part_msdos insmod jfs set root='(/dev/sdd,msdos1)' search --no-floppy --fs-uuid --set 4745f09d-c277-4113-b84a-898fa406e61f echo 'Loading Linux 2.6.32-5-xen-amd64 ...' linux /boot/vmlinuz-2.6.32-5-xen-amd64 root=UUID=4745f09d-c277-4113-b84a-898fa406e61f ro quiet echo 'Loading initial ramdisk ...' initrd /boot/initrd.img-2.6.32-5-xen-amd64 } menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-xen-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os { insmod part_msdos insmod jfs set root='(/dev/sdd,msdos1)' search --no-floppy --fs-uuid --set 4745f09d-c277-4113-b84a-898fa406e61f echo 'Loading Linux 2.6.32-5-xen-amd64 ...' linux /boot/vmlinuz-2.6.32-5-xen-amd64 root=UUID=4745f09d-c277-4113-b84a-898fa406e61f ro single echo 'Loading initial ramdisk ...' initrd /boot/initrd.img-2.6.32-5-xen-amd64 } menuentry 'Debian GNU/Linux, with Linux 2.6.26-2-xen-amd64' --class debian --class gnu-linux --class gnu --class os { insmod part_msdos insmod jfs set root='(/dev/sdd,msdos1)' search --no-floppy --fs-uuid --set 4745f09d-c277-4113-b84a-898fa406e61f echo 'Loading Linux 2.6.26-2-xen-amd64 ...' linux /boot/vmlinuz-2.6.26-2-xen-amd64 root=UUID=4745f09d-c277-4113-b84a-898fa406e61f ro quiet echo 'Loading initial ramdisk ...' initrd /boot/initrd.img-2.6.26-2-xen-amd64 } menuentry 'Debian GNU/Linux, with Linux 2.6.26-2-xen-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os { insmod part_msdos insmod jfs set root='(/dev/sdd,msdos1)' search --no-floppy --fs-uuid --set 4745f09d-c277-4113-b84a-898fa406e61f echo 'Loading Linux 2.6.26-2-xen-amd64 ...' linux /boot/vmlinuz-2.6.26-2-xen-amd64 root=UUID=4745f09d-c277-4113-b84a-898fa406e61f ro single echo 'Loading initial ramdisk ...' initrd /boot/initrd.img-2.6.26-2-xen-amd64 } menuentry 'Debian GNU/Linux, with Linux 2.6.26-2-amd64' --class debian --class gnu-linux --class gnu --class os { insmod part_msdos insmod jfs set root='(/dev/sdd,msdos1)' search --no-floppy --fs-uuid --set 4745f09d-c277-4113-b84a-898fa406e61f echo 'Loading Linux 2.6.26-2-amd64 ...' linux /boot/vmlinuz-2.6.26-2-amd64 root=UUID=4745f09d-c277-4113-b84a-898fa406e61f ro quiet echo 'Loading initial ramdisk ...' initrd /boot/initrd.img-2.6.26-2-amd64 } menuentry 'Debian GNU/Linux, with Linux 2.6.26-2-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os { insmod part_msdos insmod jfs set root='(/dev/sdd,msdos1)' search --no-floppy --fs-uuid --set 4745f09d-c277-4113-b84a-898fa406e61f echo 'Loading Linux 2.6.26-2-amd64 ...' linux /boot/vmlinuz-2.6.26-2-amd64 root=UUID=4745f09d-c277-4113-b84a-898fa406e61f ro single echo 'Loading initial ramdisk ...' initrd /boot/initrd.img-2.6.26-2-amd64 } ### END /etc/grub.d/50_linux ### -- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: 1309019149-sup-2755@eris">http://lists.debian.org/1309019149-sup-2755@eris |
debian 6.0 boot failure after update to grub2
Philipp Überbacher <hollunder@lavabit.com> writes:
> The system waits for the root file system for a while and then drops > into a shell with the (initramfs) prompt. > > There's no /dev/sd* or /dev/disk for some reason. A few weeks ago I found that I was suddenly unable to boot a self-compiled kernel after making a change to only one option which wouldn't affect booting at all. The kernel couldn't find the root fs and after some waiting put me into an emergency shell. Apparently the lvm volumes the root fs resides on were unavailable for unknown reasons. Fortunately, kernels from Debian packages still boot. I haven't found a solution other than to run stock kernels yet. The only thing I could find out is that it eventually has something to do with the initramfs not being built correctly by the update-initramfs tool. -- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: 87boxl23bb.fsf@yun.yagibdah.de">http://lists.debian.org/87boxl23bb.fsf@yun.yagibdah.de |
debian 6.0 boot failure after update to grub2
Excerpts from lee's message of 2011-06-25 20:06:48 +0200:
> Philipp Überbacher <hollunder@lavabit.com> writes: > > > The system waits for the root file system for a while and then drops > > into a shell with the (initramfs) prompt. > > > > There's no /dev/sd* or /dev/disk for some reason. > > A few weeks ago I found that I was suddenly unable to boot a > self-compiled kernel after making a change to only one option which > wouldn't affect booting at all. The kernel couldn't find the root fs and > after some waiting put me into an emergency shell. Apparently the lvm > volumes the root fs resides on were unavailable for unknown reasons. > > Fortunately, kernels from Debian packages still boot. I haven't found a > solution other than to run stock kernels yet. The only thing I could > find out is that it eventually has something to do with the initramfs > not being built correctly by the update-initramfs tool. Thanks lee, I think I saw a bug report regarding your problem. However, in my case no LVM is involved. Could it be that the initramfs is messed up for some reason? -- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: 1309027997-sup-7704@eris">http://lists.debian.org/1309027997-sup-7704@eris |
debian 6.0 boot failure after update to grub2
Philipp Überbacher <hollunder@lavabit.com> writes:
> Excerpts from lee's message of 2011-06-25 20:06:48 +0200: >> Philipp Überbacher <hollunder@lavabit.com> writes: >> >> > The system waits for the root file system for a while and then >> > drops into a shell with the (initramfs) prompt. >> > >> > There's no /dev/sd* or /dev/disk for some reason. >> >> A few weeks ago I found that I was suddenly unable to boot a >> self-compiled kernel after making a change to only one option which >> wouldn't affect booting at all. The kernel couldn't find the root fs >> and after some waiting put me into an emergency shell. Apparently the >> lvm volumes the root fs resides on were unavailable for unknown >> reasons. >> >> Fortunately, kernels from Debian packages still boot. I haven't found >> a solution other than to run stock kernels yet. The only thing I >> could find out is that it eventually has something to do with the >> initramfs not being built correctly by the update-initramfs tool. > > Thanks lee, I think I saw a bug report regarding your > problem. However, in my case no LVM is involved. Could it be that the > initramfs is messed up for some reason? The initramfs image for a particular kernel comes in a Debian package with the kernel, doesn't it? If generating the images were to produce broken images, wouldn't there be quite a few people having similar problems? I really don't know ... What if you install a more recent kernel from a rescue system? -- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: 87iprtzlt0.fsf@yun.yagibdah.de">http://lists.debian.org/87iprtzlt0.fsf@yun.yagibdah.de |
debian 6.0 boot failure after update to grub2
Excerpts from lee's message of 2011-06-25 22:40:59 +0200:
> Philipp Überbacher <hollunder@lavabit.com> writes: > > > Excerpts from lee's message of 2011-06-25 20:06:48 +0200: > >> Philipp Überbacher <hollunder@lavabit.com> writes: > >> > >> > The system waits for the root file system for a while and then > >> > drops into a shell with the (initramfs) prompt. > >> > > >> > There's no /dev/sd* or /dev/disk for some reason. > >> > >> A few weeks ago I found that I was suddenly unable to boot a > >> self-compiled kernel after making a change to only one option which > >> wouldn't affect booting at all. The kernel couldn't find the root fs > >> and after some waiting put me into an emergency shell. Apparently the > >> lvm volumes the root fs resides on were unavailable for unknown > >> reasons. > >> > >> Fortunately, kernels from Debian packages still boot. I haven't found > >> a solution other than to run stock kernels yet. The only thing I > >> could find out is that it eventually has something to do with the > >> initramfs not being built correctly by the update-initramfs tool. > > > > Thanks lee, I think I saw a bug report regarding your > > problem. However, in my case no LVM is involved. Could it be that the > > initramfs is messed up for some reason? > > The initramfs image for a particular kernel comes in a Debian package > with the kernel, doesn't it? If generating the images were to produce > broken images, wouldn't there be quite a few people having similar > problems? I really don't know ... > > What if you install a more recent kernel from a rescue system? I managed to install the normal most recent kernel (.32-5) by chroot and it doesn't boot either. In addition I uninstalled mdadm to make sure it's not the cause of those issues, yet no luck, it fails at init-bottom because it doesn't manage to mount root. Could it be that grub2 can't handle a jfs root? I'm pretty much out of ideas. I'll try downgrading to grub1 tomorrow.. -- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: 1309055672-sup-414@eris">http://lists.debian.org/1309055672-sup-414@eris |
debian 6.0 boot failure after update to grub2
Excerpts from Philipp Überbacher's message of 2011-06-26 04:38:27 +0200:
> Excerpts from lee's message of 2011-06-25 22:40:59 +0200: > > Philipp Überbacher <hollunder@lavabit.com> writes: > > > > > Excerpts from lee's message of 2011-06-25 20:06:48 +0200: > > >> Philipp Überbacher <hollunder@lavabit.com> writes: > > >> > > >> > The system waits for the root file system for a while and then > > >> > drops into a shell with the (initramfs) prompt. > > >> > > > >> > There's no /dev/sd* or /dev/disk for some reason. > > >> > > >> A few weeks ago I found that I was suddenly unable to boot a > > >> self-compiled kernel after making a change to only one option which > > >> wouldn't affect booting at all. The kernel couldn't find the root fs > > >> and after some waiting put me into an emergency shell. Apparently the > > >> lvm volumes the root fs resides on were unavailable for unknown > > >> reasons. > > >> > > >> Fortunately, kernels from Debian packages still boot. I haven't found > > >> a solution other than to run stock kernels yet. The only thing I > > >> could find out is that it eventually has something to do with the > > >> initramfs not being built correctly by the update-initramfs tool. > > > > > > Thanks lee, I think I saw a bug report regarding your > > > problem. However, in my case no LVM is involved. Could it be that the > > > initramfs is messed up for some reason? > > > > The initramfs image for a particular kernel comes in a Debian package > > with the kernel, doesn't it? If generating the images were to produce > > broken images, wouldn't there be quite a few people having similar > > problems? I really don't know ... > > > > What if you install a more recent kernel from a rescue system? > > I managed to install the normal most recent kernel (.32-5) by chroot > and it doesn't boot either. In addition I uninstalled mdadm to make sure > it's not the cause of those issues, yet no luck, it fails at > init-bottom because it doesn't manage to mount root. > Could it be that grub2 can't handle a jfs root? I'm pretty much out of > ideas. I'll try downgrading to grub1 tomorrow.. Well, after downgrading to grub1 the system still doesn't boot, so it seems like grub2 was the trigger but isn't the problem. The normal kernel and removal of mdadm should pretty much rule xen and mdadm out as well, so what's left? Udev? Something else? I tried manual mounting from busybox: mount /dev/sda1 /root fails with Invalid Argument mount -t jfs /dev/sda1 /root fails with No such device So this is what happens during boot as well. I found a post suggesting that it might be a missing driver because the device is there. I tried modprobing a couple of modules in busybox, but nothing I tried helped. initramfs.conf is set to most and I rebuilt it a couple of times. Ideas please? -- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: 1309103480-sup-8335@eris">http://lists.debian.org/1309103480-sup-8335@eris |
debian 6.0 boot failure after update to grub2
On Sun, 26 Jun 2011 18:44:49 +0200
Philipp Überbacher <hollunder@lavabit.com> wrote: > > I tried manual mounting from busybox: > mount /dev/sda1 /root > fails with Invalid Argument > > mount -t jfs /dev/sda1 /root > fails with No such device > > So this is what happens during boot as well. I found a post suggesting > that it might be a missing driver because the device is there. I tried > modprobing a couple of modules in busybox, but nothing I tried helped. > > initramfs.conf is set to most and I rebuilt it a couple of times. > > Ideas please? > > A wild guess, but you sound just about ready for that: A few months ago, I copied (offline) a Lenny installation to a new drive, and then tried to install grub (-legacy) to the MBR from the running system. No luck, though it might be that I did not find the right method. Anyway, I removed the working drive, moved the cables, then booted from a CD and tried to restore the MBR to the new drive. There are instructions for doing that everywhere on the Net, the only problem being that they didn't work for me. Once I could see what I was doing I tried a few syntax variations, still with no luck. Trying different boot media, I got several different failure messages, mostly to do with files and folders not being found, when they were clearly visible to the rescue OS, and I was able to mount the hard drive partitions and even write to them. I know grub has its own disc drivers, and I guessed that the version installed on the hard drive was not the same as the rescue version. So I tried every grub-legacy boot medium I had and eventually found one that worked. I can't remember now what it was, but it was either the last CD Knoppix I have, 3.9, or an old Ubuntu. Most recent live distros use grub2, which was no use at all. So it looks to me that grub is changing quickly (as was grub-legacy), and to make a successful rescue you need to be using a grub version which is the same as or very close to the one on the hard drive. As it happens, a couple of years ago I had your problem on Sid. The two-grubs-in-series booting was working OK, so I ran the command to upgrade fully to grub2 and the drive never booted again. I reinstalled Sid, which was fine with a new grub2. Had I had the time then, I might have investigated further and found the grub version issue, which was almost certainly what stopped me repairing things. I assumed then that if the SuperGrub2 disc didn't work, nothing would. Never used to have this trouble with lilo.... ...though of course in the last few years before grub appeared, lilo was very mature and stable. I still have a tomsrtbt floppy... -- Joe -- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: 20110626204647.19369d1d@jresid.jretrading.com">htt p://lists.debian.org/20110626204647.19369d1d@jresid.jretrading.com |
debian 6.0 boot failure after update to grub2
Excerpts from Joe's message of 2011-06-26 21:46:47 +0200:
> On Sun, 26 Jun 2011 18:44:49 +0200 > Philipp Überbacher <hollunder@lavabit.com> wrote: > > > > > I tried manual mounting from busybox: > > mount /dev/sda1 /root > > fails with Invalid Argument > > > > mount -t jfs /dev/sda1 /root > > fails with No such device > > > > So this is what happens during boot as well. I found a post suggesting > > that it might be a missing driver because the device is there. I tried > > modprobing a couple of modules in busybox, but nothing I tried helped. > > > > initramfs.conf is set to most and I rebuilt it a couple of times. > > > > Ideas please? > > > > > > A wild guess, but you sound just about ready for that: > > A few months ago, I copied (offline) a Lenny installation to a new > drive, and then tried to install grub (-legacy) to the MBR from the > running system. No luck, though it might be that I did not find the > right method. Anyway, I removed the working drive, moved the cables, > then booted from a CD and tried to restore the MBR to the new drive. > There are instructions for doing that everywhere on the Net, the only > problem being that they didn't work for me. Once I could see what I was > doing I tried a few syntax variations, still with no luck. > > Trying different boot media, I got several different failure messages, > mostly to do with files and folders not being found, when they were > clearly visible to the rescue OS, and I was able to mount the hard > drive partitions and even write to them. > > I know grub has its own disc drivers, and I guessed that the version > installed on the hard drive was not the same as the rescue version. So > I tried every grub-legacy boot medium I had and eventually found one > that worked. I can't remember now what it was, but it was either the > last CD Knoppix I have, 3.9, or an old Ubuntu. Most recent live distros > use grub2, which was no use at all. > > So it looks to me that grub is changing quickly (as was grub-legacy), > and to make a successful rescue you need to be using a grub version > which is the same as or very close to the one on the hard drive. > > As it happens, a couple of years ago I had your problem on Sid. The > two-grubs-in-series booting was working OK, so I ran the command to > upgrade fully to grub2 and the drive never booted again. I reinstalled > Sid, which was fine with a new grub2. Had I had the time then, I might > have investigated further and found the grub version issue, which was > almost certainly what stopped me repairing things. I assumed then that > if the SuperGrub2 disc didn't work, nothing would. > > Never used to have this trouble with lilo.... > > ...though of course in the last few years before grub appeared, lilo > was very mature and stable. I still have a tomsrtbt floppy... > > -- > Joe Thanks Joe, this didn't help me unfortunately. However, after spending many hours on this (thanks phcoder from #grub) it turned out that necessary modules were missing from initramfs. Adding jfs was enough for the system to boot in qemu but not for the real hardware. I've not yet found out what's necessary for that. So, almost solved.. and not sure what to put into the bug report yet. -- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: 1309141075-sup-9689@eris">http://lists.debian.org/1309141075-sup-9689@eris |
debian 6.0 boot failure after update to grub2
Philipp Überbacher <hollunder@lavabit.com> writes:
> However, after spending many hours on this (thanks phcoder from #grub) > it turned out that necessary modules were missing from initramfs. > Adding jfs was enough for the system to boot in qemu but not for the > real hardware. I've not yet found out what's necessary for that. So, > almost solved.. and not sure what to put into the bug report yet. Since I'm not using JFS and had similar symptoms, it's probably not only related to JFS modules. You could say in the bug report that systems eventually become unable to boot because of modules missing from initramfs. IIRC, there has been an update of mkinitramfs or update-initramfs a while ago in Testing --- that was after I found myself unable to boot my kernel. I don't know whether this updated is related at all, though. -- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: 87y60nksp8.fsf@yun.yagibdah.de">http://lists.debian.org/87y60nksp8.fsf@yun.yagibdah.de |
| All times are GMT. The time now is 07:07 AM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.