My only differences from "standard" set-up:
(1) Old hardware
(2) DIY disk partitioning.
On completion of the intallation, it failed to boot, with messages like this:
VFS: cannot open root deveice "UUID=<hex stuff>" or unknown block (0,0)
Please append a correct "root=" boot option; here are the available partitions:
kernel panic - not syncing: VFS: unable to mount root fs on unknown-block (0,0)
Eventually I worked out that
- the "initrd" command is missing from /boot/grub/menu.lst
- the file /boot/initrd.img-2.6.24-16-generic is missing
(actially, it's there, but called /boot/initrd.img-2.6.24-16-generic.bak)
After correcting this, the new system booted correctly.
Another thing that confused matters was that my internal IDE disk
that had been called /dev/hda was now called /dev/sda which I thought
meant a SCSI disk.
On further investigation, I found that the "installer" failed to create initrd.img
The relevant part of /var/log/installer/syslog is attached.
For the enlightenment of novices like me:
"grub" is part of the bootstrapping process, and loads the operating system kernel;
to do this, it needs the executable binary of the kernel itself
and also a minimal filesystem, which is what initrd.img provides
(this is a gzip-compressed cpio-image of /bin, /conf, /etc, /init, /lib, /modules, /sbin, /scripts, /usr and /var)
There are tools such as update_initramfs and others to create this image,
but I could not work out how to do so unless you already have the target filesystem in place,
which seems to require the target kernel too; in particular, I don't know how to set things
up to use chroot.
Since there is an initrd.img...bak file, somebody was presumably aware of the possibility
that creation of the new initrd.img might fail during the installation process. There
should be a check for this, and in this case the .bak file should be installed.
As psl says, this is a critical bug, and one that could easily put people off using Linux for life.
Ubuntu sells itself as "Linux for human beings", which this kind of failure clearly is not.
However, what makes me angry about this is not the bug itself, but the enthusiasm that
the installation cd has for trashing my disk and pre-existing system (which was Ubuntu 6.10).
Even though I had backed everything up, it took me about 20 hours work from giving the
go-ahead to the Xubuntu 8.04 installation to recovering my old system in an approximately
usable state. (cpio had very kindly changed many of the directory permissions to drwx------,
making much the system unusable.)
Ubuntu and other Linux distributions go to some length to provide "dual boot" with
Micros**t, so why not a dual boot with the pre-existing Unix (Ubuntu) system? Then,
after a failure like this one, the user can revert to the old but working system. If that's
too difficult, then at least please move the old / /usr and /var to OLD, so that they can be
restored using some other tool like Knoppix.
If I hadn't had a Knoppix CD for fixing things, and a laptop to look stuff up on the Web,
It would have had no way of recovering my computer.
Xubuntu 8.04 (24 April 2008) CD image downloaded
My only differences from "standard" set-up:
(1) Old hardware
(2) DIY disk partitioning.
On completion of the intallation, it failed to boot, with messages like this:
VFS: cannot open root deveice "UUID=<hex stuff>" or unknown block (0,0)
Please append a correct "root=" boot option; here are the available partitions:
kernel panic - not syncing: VFS: unable to mount root fs on unknown-block (0,0)
Eventually I worked out that img-2.6. 24-16-generic is missing img-2.6. 24-16-generic. bak)
- the "initrd" command is missing from /boot/grub/menu.lst
- the file /boot/initrd.
(actially, it's there, but called /boot/initrd.
After correcting this, the new system booted correctly.
Another thing that confused matters was that my internal IDE disk
that had been called /dev/hda was now called /dev/sda which I thought
meant a SCSI disk.
On further investigation, I found that the "installer" failed to create initrd.img installer/ syslog is attached.
The relevant part of /var/log/
For the enlightenment of novices like me:
"grub" is part of the bootstrapping process, and loads the operating system kernel;
to do this, it needs the executable binary of the kernel itself
and also a minimal filesystem, which is what initrd.img provides
(this is a gzip-compressed cpio-image of /bin, /conf, /etc, /init, /lib, /modules, /sbin, /scripts, /usr and /var)
There are tools such as update_initramfs and others to create this image,
but I could not work out how to do so unless you already have the target filesystem in place,
which seems to require the target kernel too; in particular, I don't know how to set things
up to use chroot.
Since there is an initrd.img...bak file, somebody was presumably aware of the possibility
that creation of the new initrd.img might fail during the installation process. There
should be a check for this, and in this case the .bak file should be installed.
As psl says, this is a critical bug, and one that could easily put people off using Linux for life.
Ubuntu sells itself as "Linux for human beings", which this kind of failure clearly is not.
However, what makes me angry about this is not the bug itself, but the enthusiasm that
the installation cd has for trashing my disk and pre-existing system (which was Ubuntu 6.10).
Even though I had backed everything up, it took me about 20 hours work from giving the
go-ahead to the Xubuntu 8.04 installation to recovering my old system in an approximately
usable state. (cpio had very kindly changed many of the directory permissions to drwx------,
making much the system unusable.)
Ubuntu and other Linux distributions go to some length to provide "dual boot" with
Micros**t, so why not a dual boot with the pre-existing Unix (Ubuntu) system? Then,
after a failure like this one, the user can revert to the old but working system. If that's
too difficult, then at least please move the old / /usr and /var to OLD, so that they can be
restored using some other tool like Knoppix.
If I hadn't had a Knoppix CD for fixing things, and a laptop to look stuff up on the Web,
It would have had no way of recovering my computer.