dosfslabel linux-base grub mess
TWIMC: The following is a summary of the problems I encountered when the
kernel image vmlinuz-2.6.32-5-amd64 was released.
1. A dist-upgrade loaded and tried to install linux-base and the
2.6.32-5 kernel image. The install failed with error messages from
dosfslabel.
2. Running dosfslabel on each partition of the systems hard drives gave
an error only for the partition /dev/hda1. In the distant past this
partition had been a windoze partition but long ago had been reformated
as an ext2 partition. To remove any trace of the old windoze
installation all the files were backed up and every partition on
/dev/hda was deleted, re-created and formated as ext3 partitions. After
this dosfslabel no longer gave an error when run on the individual
partitions but the installation of linux-base still failed with an error
message from dosfslabel.
3. There remained the possibility of a remnant of windoze in the MBR so
lilo was used to write a new MBR to boot kernel image 2.6.32-3 on
/dev/hda. The MBR's on the other two hard drives, sda and sdb, were
written by grub. The system booted normally from any of the three hard
drives but the installation of linux-base still failed with an error
message from dosfslabel.
4. It was suggested that the presence of usb devices was causing the
problem so all were disconnected. The installation of linux-base still
failed with an error message for dosfslabel.
5. The fstab contained entries cdrom drives and usb storage devices
which accessed vfat files. The fstab was backed up and edited to
include only the ext3 hard drive partitions. Finally linux-base and the
2.6.32-5 kernel image were successfully installed.
6. During the installation of the new kernel the fstab was modified to
identify the hard drives by their UUID's. The system then could no
longer be booted from MBR's installed by grub. The boot tried to load
the new 2.6.32-5 kernel but failed when the root directory could not be
found.
7. The system still booted normally to the 2.6.32-3 kernel from the MBR
installed on /dev/hda by lilo. At this point the entries for the cdrom
drives and usb drives were restored to fstab, lilo.conf was edited to
include the new 2.6.32-5 kernel image, lilo was run and the system
rebooted. Reboots from /dev/sda and from /dev/sdb still failed but
boots from /dev/hda worked fine loading the 2.6.32-5 kernel image.
8. The astounding current difficulty is made clear by the following
listing of fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# /dev/sdb1 / ext3 errors=remount-ro 0 1
UUID=bfcd3316-153a-4279-ab86-286906857b98 / ext3 errors=remount-ro 0 1
# /dev/sdb5 none swap sw 0 0
UUID=4b1523d0-bec9-4565-b085-0a151469b8db none swap sw 0 0
# formerly named /dev/sda1 is now:
UUID=507caf8f-f9cd-4ed2-91cc-3e46ae942e9d /bkups ext3 rw,user,noauto 0 2
# /dev/sda5 /ubuntu ext3 defaults 0 2
UUID=28a4eb99-6213-4b82-96a2-42b45097e256 /ubuntu ext3 defaults 0 2
# /dev/sda6 /data ext3 defaults 0 2
UUID=36cb29b0-2694-4dee-9ae4-10351963b979 /data ext3 defaults 0 2
/dev/fd0 /media/floppy0 auto rw,user,noauto 0 0
# /dev/hda1 /temp ext2 rw,user,auto 0 2
UUID=4a2915d8-60cf-498e-a15c-f0bc6ebdb25e /temp ext2 rw,user,auto 0 2
# /dev/hda5 /storage ext2 defaults 0 2
UUID=408287f4-8b15-42d1-b6d3-bfeaefde3002 /storage ext2 defaults 0 2
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/cdrom /cdrom iso9660 ro,user,noauto 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/scd0 /media/cddata auto ro,user,noauto 0 0
/dev/scd1 /media/cdrom1 udf,iso9660 user,noauto 0 0
/dev/sdc1 /usbkey auto rw,user,noauto 0 0
/dev/sdc5 /media/bkup ext3 rw,user,noauto 0 0
/dev/sdc /media/fuze vfat rw,user,noauto 0 0
/dev/sr0 /media/cdrw iso9660 rw,user,noauto 0 0
/dev/sr1 /dvdrw iso9660 rw,user,noauto 0 0
/dev/sg0 /sony iso9660 rw,user,noauto 0 0
/dev/sg1 /usbdrive vfat rw,user,noauto 0 0
as compared to the output of df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sdc1 71G 39G 29G 58% /
tmpfs 2.0G 0 2.0G 0% /lib/init/rw
udev 2.0G 252K 2.0G 1% /dev
tmpfs 2.0G 0 2.0G 0% /dev/shm
/dev/sda5 44G 180M 42G 1% /ubuntu
/dev/sda6 276G 43G 219G 17% /data
/dev/sdb1 1.7G 35M 1.6G 3% /temp
/dev/sdb5 27G 13G 13G 51% /storage
Note that the root directory is shown on /dev/sdc1 which should be an
empty cdrom drive! There are no entries for /dev/hda1 and /dev/hda5 but
their contents are shown on /dev/sdb1 and /dev/sdb5! The root directory
is really on sdb1 and lilo knows this.
I have no idea how to straighten out this mess.
Tom
Reply to: