[Grml 1.0] cannot boot anymore after upgrade

Hi all,
I am quite new to GRML (and Debian/Knoppix based distributions). However, I have some experience with other Linux distris.
So recently I got a virtual appliance with Grml installed already. One of the first things was to use apt-get (first attempt) and aptitude (second attempt) to upgrade all upgradable packages. The results was the same: I could not boot anymore. The only thing that appears is 'GRUB' without any further error message.
I have spent two days already to figure out what happens. I have seen reports about similar errors when updating ubuntu versions. The reason was a switch from hdX to sdX (and a mismatch of the UUIDs).
I checked all that: UUIDs are fine. And even with the device names the symptoms are the same.
I then tried to reinstall GRUB. The installation process yielded no errors (the menu.lst and the device map are fine). Nevertheless I get the same error :-(
Then I thought: Maybe it's only a GRUB problem and tried LILO. With lilo I get some more information, but also the boot process stops very early. I get error messages about some modules that cannot be loaded. (I currently have no access and, thus, cannot type the exact error message here.)
I am wondering whether this has something to do with the linux-kernel-header-grml package which apt-get/aptitude were keen to remove?
I am also wondering: I surely am not the only one who ever upgraded a GRML 1.0 system, or? Did noone ever encountered a similar problem?
I appreciate every hint which might bring me closer to a solution of this most annoying problem.
Thanks in advance,
Jan
http://toolbar.Care2.com Make your computer carbon-neutral (free).
http://www.Care2.com Green Living, Human Rights and more - 7 million members!

* Ja Bu jb_int@care2.com [20071003 01:53]:
I am quite new to GRML (and Debian/Knoppix based distributions). However, I have some experience with other Linux distris.
So recently I got a virtual appliance with Grml installed already. One of the first things was to use apt-get (first attempt) and aptitude (second attempt) to upgrade all upgradable packages. The results was the same: I could not boot anymore. The only thing that appears is 'GRUB' without any further error message.
I have spent two days already to figure out what happens. I have seen reports about similar errors when updating ubuntu versions. The reason was a switch from hdX to sdX (and a mismatch of the UUIDs).
I checked all that: UUIDs are fine. And even with the device names the symptoms are the same.
I then tried to reinstall GRUB. The installation process yielded no errors (the menu.lst and the device map are fine). Nevertheless I get the same error :-(
Ok.
Then I thought: Maybe it's only a GRUB problem and tried LILO. With lilo I get some more information, but also the boot process stops very early. I get error messages about some modules that cannot be loaded. (I currently have no access and, thus, cannot type the exact error message here.)
The last 1-2 lines of the output would be interesting.
I am wondering whether this has something to do with the linux-kernel-header-grml package which apt-get/aptitude were keen to remove?
No, linux-kernel-header-grml does not contain any files used for booting stuff.
I am also wondering: I surely am not the only one who ever upgraded a GRML 1.0 system, or? Did noone ever encountered a similar problem?
I appreciate every hint which might bring me closer to a solution of this most annoying problem.
Can you please provide the output of:
dpkg --list mdadm lvm2 initramfs-tools lilo grub udev
of the system? (Just boot grml live and chroot into your system)
If you change the root=UUID=... line within grub/lilo to something like root=/dev/... (where the later device corresponds with your root partition) - does it boot then?
JFYI: I'll try to reproduce the problem on my own here, so you definitely won't be lost with a not-bootable system.
regards, -mika-

* Michael Prokop mika@grml.org [20071003 07:46]:
- Ja Bu jb_int@care2.com [20071003 01:53]:
[...]
I am also wondering: I surely am not the only one who ever upgraded a GRML 1.0 system, or? Did noone ever encountered a similar problem?
I appreciate every hint which might bring me closer to a solution of this most annoying problem.
Can you please provide the output of:
dpkg --list mdadm lvm2 initramfs-tools lilo grub udev
of the system? (Just boot grml live and chroot into your system)
If you change the root=UUID=... line within grub/lilo to something like root=/dev/... (where the later device corresponds with your root partition) - does it boot then?
JFYI: I'll try to reproduce the problem on my own here, so you definitely won't be lost with a not-bootable system.
Just verified it on my own: root=UUID=... still/again does not work with initramfs-tools. So just use root=/dev/... on your grub cmdline in the meanwhile to boot your system, I'm debugging the problem.... Stay tuned...
regards, -mika-

* Michael Prokop mika@grml.org [20071003 12:49]:
- Michael Prokop mika@grml.org [20071003 07:46]:
- Ja Bu jb_int@care2.com [20071003 01:53]:
JFYI: I'll try to reproduce the problem on my own here, so you definitely won't be lost with a not-bootable system.
Just verified it on my own: root=UUID=... still/again does not work with initramfs-tools. So just use root=/dev/... on your grub cmdline in the meanwhile to boot your system, I'm debugging the problem.... Stay tuned...
See http://bugs.debian.org/431291 for more information, as soon as we found a persistent solution I'll provide it here as well.
regards, -mika-

* Michael Prokop mika@grml.org [20071003 13:26]:
- Michael Prokop mika@grml.org [20071003 12:49]:
Just verified it on my own: root=UUID=... still/again does not work with initramfs-tools. So just use root=/dev/... on your grub cmdline in the meanwhile to boot your system, I'm debugging the problem.... Stay tuned...
See http://bugs.debian.org/431291 for more information, as soon as we found a persistent solution I'll provide it here as well.
The problem is located in the udev hook used inside initramfs-tools. I uploaded an updated udev package to the grml pool so upgrading a harddisk installation should not result in a not-bootable system any longer.
Big credits to maks who helped me in debugging and locating the problem.
regards, -mika-
Teilnehmer (2)
-
Ja Bu
-
Michael Prokop