FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 07-31-2010, 04:42 PM
"Thomas H. George"
 
Default 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


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100731164235.GA4929@tomgeorge.info">http://lists.debian.org/20100731164235.GA4929@tomgeorge.info
 
Old 07-31-2010, 06:05 PM
Andrei Popescu
 
Default dosfslabel linux-base grub mess

On Sb, 31 iul 10, 12:42:35, Thomas H. George wrote:
>
> 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.

I assume this is grub1 (legacy). Edit /boot/grub/menu.lst and change the
line:

# kopt=root=/dev/Xda other_kernel_opts

to

# kopt=root=UUID=uuid_of_root_part other_kernel_opts

and then run 'update-grub'

Regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
 
Old 07-31-2010, 06:46 PM
"Thomas H. George"
 
Default dosfslabel linux-base grub mess

On Sat, Jul 31, 2010 at 09:05:45PM +0300, Andrei Popescu wrote:
> On Sb, 31 iul 10, 12:42:35, Thomas H. George wrote:
> >
> > 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.
>
> I assume this is grub1 (legacy). Edit /boot/grub/menu.lst and change the
> line:
>
> # kopt=root=/dev/Xda other_kernel_opts
>
> to
>
> # kopt=root=UUID=uuid_of_root_part other_kernel_opts
>
> and then run 'update-grub'
>
> Regards,
> Andrei
> --
It is grub2. I checked and the # kopt is in the new format and the
UUID is that of the root partition. I ran update-grub just to be sure
and now the system will boot from a MBR written by grub. The output of
df -h is still the same mixed up mess.

Regards,

Tom
> Offtopic discussions among Debian users and developers:
> http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100731184655.GA2632@tomgeorge.info">http://lists.debian.org/20100731184655.GA2632@tomgeorge.info
 
Old 07-31-2010, 07:51 PM
Andrei Popescu
 
Default dosfslabel linux-base grub mess

On Sb, 31 iul 10, 14:46:55, Thomas H. George wrote:
> It is grub2. I checked and the # kopt is in the new format and the
> UUID is that of the root partition. I ran update-grub just to be sure
> and now the system will boot from a MBR written by grub. The output of
> df -h is still the same mixed up mess.

Device names are not stable (not changing), only UUIDs and LABELs are.

Regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
 
Old 07-31-2010, 09:15 PM
Paul E Condon
 
Default dosfslabel linux-base grub mess

On 20100731_225121, Andrei Popescu wrote:
> On Sb, 31 iul 10, 14:46:55, Thomas H. George wrote:
> > It is grub2. I checked and the # kopt is in the new format and the
> > UUID is that of the root partition. I ran update-grub just to be sure
> > and now the system will boot from a MBR written by grub. The output of
> > df -h is still the same mixed up mess.
>
> Device names are not stable (not changing), only UUIDs and LABELs are.

UUID is not entirely stable. If during a new install you choose to have
a partition re-initialized, the partitioning software also writes a new,
different UUID into its superblock. For a label, you have the option of
giving the same value as it had before.


--
Paul E Condon
pecondon@mesanetworks.net


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100731211516.GA2161@big.lan.gnu">http://lists.debian.org/20100731211516.GA2161@big.lan.gnu
 
Old 07-31-2010, 09:20 PM
Andrei Popescu
 
Default dosfslabel linux-base grub mess

On Sb, 31 iul 10, 15:15:16, Paul E Condon wrote:
> On 20100731_225121, Andrei Popescu wrote:
> > On Sb, 31 iul 10, 14:46:55, Thomas H. George wrote:
> > > It is grub2. I checked and the # kopt is in the new format and the
> > > UUID is that of the root partition. I ran update-grub just to be sure
> > > and now the system will boot from a MBR written by grub. The output of
> > > df -h is still the same mixed up mess.
> >
> > Device names are not stable (not changing), only UUIDs and LABELs are.
>
> UUID is not entirely stable. If during a new install you choose to have
> a partition re-initialized, the partitioning software also writes a new,
> different UUID into its superblock. For a label, you have the option of
> giving the same value as it had before.

Of course UUID changes or re-format What I meant was that device
names can change for other reasons (I remember posts about machines
having different device names across reboots with the *same* kernel).

Regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
 
Old 07-31-2010, 09:21 PM
"Boyd Stephen Smith Jr."
 
Default dosfslabel linux-base grub mess

On Saturday 31 July 2010 11:42:35 Thomas H. George wrote:
> 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.

Do an (ls -ld /dev/[sh]d*) for me. I think you'll see there are no longer any
"hd" devices and that your cdrom and usb-key now have a different "sd" letter.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
 
Old 07-31-2010, 09:23 PM
"Boyd Stephen Smith Jr."
 
Default dosfslabel linux-base grub mess

On Saturday 31 July 2010 16:15:16 Paul E Condon wrote:
> On 20100731_225121, Andrei Popescu wrote:
> > On Sb, 31 iul 10, 14:46:55, Thomas H. George wrote:
> > > It is grub2. I checked and the # kopt is in the new format and the
> > > UUID is that of the root partition. I ran update-grub just to be sure
> > > and now the system will boot from a MBR written by grub. The output of
> > > df -h is still the same mixed up mess.
> >
> > Device names are not stable (not changing), only UUIDs and LABELs are.
>
> UUID is not entirely stable. If during a new install you choose to have
> a partition re-initialized, the partitioning software also writes a new,
> different UUID into its superblock. For a label, you have the option of
> giving the same value as it had before.

UUIDs are attached to the file system and are stable.

In the case above, you have a new file system, so you get a new UUID.

UUIDs and LABELs are not unique though. LVM snapshots (and similar
technologies) can result in two file systems have the same UUID and LABEL.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
 
Old 08-02-2010, 03:43 PM
Henrique de Moraes Holschuh
 
Default dosfslabel linux-base grub mess

On Sat, 31 Jul 2010, Andrei Popescu wrote:
> On Sb, 31 iul 10, 14:46:55, Thomas H. George wrote:
> > It is grub2. I checked and the # kopt is in the new format and the
> > UUID is that of the root partition. I ran update-grub just to be sure
> > and now the system will boot from a MBR written by grub. The output of
> > df -h is still the same mixed up mess.
>
> Device names are not stable (not changing), only UUIDs and LABELs are.

/dev/md device names are designed to be stable. LVM LV device names are also
designed to be stable.

Half-baked search for UUIDs and LABELs can cause the detection of component
devices, which can result in data loss or corruption. So you must be able
to limit the search scope.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100802154357.GC32757@khazad-dum.debian.net">http://lists.debian.org/20100802154357.GC32757@khazad-dum.debian.net
 

Thread Tools




All times are GMT. The time now is 04:03 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org