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


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100731164235.ga4...@tomgeorge.info

Reply via email to