Fixing fstab & menu.lst UUID - Ubuntu

This is a discussion on Fixing fstab & menu.lst UUID - Ubuntu ; I have UUID problems in a couple of different places since Mepis replaced my Ub 8.04 grub with its own and also I changed up some partitions. I'm confused about fstab. The current partition structure (which gparted scanning btw takes ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: Fixing fstab & menu.lst UUID

  1. Fixing fstab & menu.lst UUID

    I have UUID problems in a couple of different places since Mepis replaced
    my Ub 8.04 grub with its own and also I changed up some partitions. I'm
    confused about fstab.

    The current partition structure (which gparted scanning btw takes a long
    time) is:

    sda1 fat32 W2K
    sda2 ext3 Mepis
    sda3 extended
    sda5 swap
    sda6 ext3 Ub804

    The Mepis is the last added (or maybe I replaced something) and is at the
    top of the grub.

    The /etc/fstab in the Ub part sda6 sez in part (this is going to wrap
    badly):

    # /dev/sda6
    UUID=69c7c703-c30d-4e16-9253-f6541b753662 / ext3
    errors=remount-ro 0 1
    # /dev/sda1
    UUID=447D-AA2B /media/sda1 vfat utf8,umask=007,gid=46 0 1
    # /dev/sda2
    UUID=d96339e1-66b3-4d9b-917f-f9602acbc90b /media/sda2 ext3 defaults
    0 2
    # /dev/sda5
    UUID=1c8bcc19-2955-43b9-8283-9eb3a3e813e7 none swap sw
    0 0

    The /boot/grub/menu.lst in Mepis sda2 sez in part:

    title MEPIS at sda2, newest kernel
    root (hd0,1)
    kernel /boot/vmlinuz root=/dev/sda2 nomce quiet splash vga=normal nousb
    resume=/dev/sda5
    boot

    title MEPIS at sda2, previous kernel (if any)
    root (hd0,1)
    kernel /boot/vmlinuz.old root=/dev/sda2 nomce quiet splash vga=normal
    nousb resume=/dev/sda5
    boot

    title MEPIS at sda2, kernel 2.6.22-1-mepis-smp
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.22-1-mepis-smp root=/dev/sda2 nomce quiet splash
    vga=normal nousb resume=/dev/sda5
    boot

    title Microsoft Windows 2000 Professional at sda1
    rootnoverify (hd0,0)
    chainloader +1

    title Ubuntu hardy (development branch), kernel 2.6.24-16-generic
    root (hd0,5)
    kernel /boot/vmlinuz-2.6.24-16-generic
    root=UUID=69c7c703-c30d-4e16-9253-f6541b753662 ro quiet splash

    This condition causes errors in the bootup process for Ub because the UUID
    isn't recognized.

    I can get around the problem during grub boot managing by replacing the
    root=UUID business with root=/dev/sda6.

    I think I'm understanding that I should fix the fstab somewhere, such as
    the Ub part, and naturally I can and should fix the menu.lst in the Mepis
    part. My questions are: is that correct? how exactly should it be
    changed, and which ones? The fstab in Mepis doesn't do/show the UUID
    business at all.

    One place I read about UUID fixing of fstab & menu.lst is here, but it
    doesn't fit my case exactly
    http://linuxmint.com/wiki/index.php/..._is_it_a_probl
    em UUID -what is it and why is it a problem


    --
    Mike Easter


  2. Re: Fixing fstab & menu.lst UUID

    I should say what I think I should do.

    Mike Easter wrote:
    > I have UUID problems in a couple of different places since Mepis
    > replaced my Ub 8.04 grub with its own and also I changed up some
    > partitions. I'm confused about fstab.


    > The /etc/fstab in the Ub part sda6 sez in part (this is going to wrap
    > badly):


    I think the Ub fstab is the one I should fix.

    > # /dev/sda6
    > UUID=69c7c703-c30d-4e16-9253-f6541b753662 / ext3
    > errors=remount-ro 0 1
    > # /dev/sda1
    > UUID=447D-AA2B /media/sda1 vfat utf8,umask=007,gid=46 0 1
    > # /dev/sda2
    > UUID=d96339e1-66b3-4d9b-917f-f9602acbc90b /media/sda2 ext3
    > defaults 0 2
    > # /dev/sda5
    > UUID=1c8bcc19-2955-43b9-8283-9eb3a3e813e7 none swap sw
    > 0 0


    ....like maybe this, or at least fix the sda6 one and maybe not bother with
    the other lines:

    /dev/sda6 ext3

    > The /boot/grub/menu.lst in Mepis sda2 sez in part:


    > title Ubuntu hardy (development branch), kernel 2.6.24-16-generic
    > root (hd0,5)
    > kernel /boot/vmlinuz-2.6.24-16-generic
    > root=UUID=69c7c703-c30d-4e16-9253-f6541b753662 ro quiet splash


    I know this works:

    root=/dev/sda6

    > I think I'm understanding that I should fix the fstab somewhere, such as
    > the Ub part, and naturally I can and should fix the menu.lst in the
    > Mepis part.


    It seems strange to me that I'm changing the fstab in the Ub part and the
    menu.lst in the Mepis part to solve a boot problem that reads from the
    Mepis part.

    --
    Mike Easter


  3. Re: Fixing fstab & menu.lst UUID

    On Fri, 11 Jul 2008 15:36:19 -0700, Mike Easter wrote:
    > I have UUID problems in a couple of different places since Mepis replaced
    > my Ub 8.04 grub with its own and also I changed up some partitions. I'm
    > confused about fstab.


    Yep, different distributions and/or version of same distributions
    can give you those kinds of problems.

    Extra feature. reformat drive and UUID changes. :-(
    Install your backup and you are AFU.


    My solution, I used e2label to label linux ext* partitions.
    Modified fstab and menu.lst to use LABEL. Example snippets follow:

    $ head -4 /etc/fstab
    LABEL=vm2008_1 / ext3 relatime 1 1
    LABEL=local /local ext3 relatime 1 2
    LABEL=20081_64 /20081_64 ext3 user,noauto,relatime 1 2
    LABEL=2008_1 /2008_1 ext3 user,noauto,relatime 1 2

    $ grep -i =label /boot/grub/menu.lst
    kernel (hd0,10)/boot/vmlinuz BOOT_IMAGE=linux root=LABEL=vm2008_1 resume=/dev/sda6 splash=0 vga=791

    To make life easy on news installs, I created a post install script to modify
    my system config files.

    Dave took my script and created an ambidexterous script.
    http://groups.google.com/group/alt.o...686da010e24cfc

  4. Re: Fixing fstab & menu.lst UUID

    Mike Easter wrote:
    > I have UUID problems in a couple of different places since Mepis replaced
    > my Ub 8.04 grub with its own and also I changed up some partitions. I'm
    > confused about fstab.
    >
    > The current partition structure (which gparted scanning btw takes a long
    > time) is:
    >
    > sda1 fat32 W2K
    > sda2 ext3 Mepis
    > sda3 extended
    > sda5 swap
    > sda6 ext3 Ub804
    >
    > The Mepis is the last added (or maybe I replaced something) and is at the
    > top of the grub.
    >
    > The /etc/fstab in the Ub part sda6 sez in part (this is going to wrap
    > badly):
    >
    > # /dev/sda6
    > UUID=69c7c703-c30d-4e16-9253-f6541b753662 / ext3
    > errors=remount-ro 0 1
    > # /dev/sda1
    > UUID=447D-AA2B /media/sda1 vfat utf8,umask=007,gid=46 0 1
    > # /dev/sda2
    > UUID=d96339e1-66b3-4d9b-917f-f9602acbc90b /media/sda2 ext3 defaults
    > 0 2
    > # /dev/sda5
    > UUID=1c8bcc19-2955-43b9-8283-9eb3a3e813e7 none swap sw
    > 0 0
    >
    > The /boot/grub/menu.lst in Mepis sda2 sez in part:
    >
    > title MEPIS at sda2, newest kernel
    > root (hd0,1)
    > kernel /boot/vmlinuz root=/dev/sda2 nomce quiet splash vga=normal nousb
    > resume=/dev/sda5
    > boot
    >
    > title MEPIS at sda2, previous kernel (if any)
    > root (hd0,1)
    > kernel /boot/vmlinuz.old root=/dev/sda2 nomce quiet splash vga=normal
    > nousb resume=/dev/sda5
    > boot
    >
    > title MEPIS at sda2, kernel 2.6.22-1-mepis-smp
    > root (hd0,1)
    > kernel /boot/vmlinuz-2.6.22-1-mepis-smp root=/dev/sda2 nomce quiet splash
    > vga=normal nousb resume=/dev/sda5
    > boot
    >
    > title Microsoft Windows 2000 Professional at sda1
    > rootnoverify (hd0,0)
    > chainloader +1
    >
    > title Ubuntu hardy (development branch), kernel 2.6.24-16-generic
    > root (hd0,5)
    > kernel /boot/vmlinuz-2.6.24-16-generic
    > root=UUID=69c7c703-c30d-4e16-9253-f6541b753662 ro quiet splash
    >
    > This condition causes errors in the bootup process for Ub because the UUID
    > isn't recognized.
    >
    > I can get around the problem during grub boot managing by replacing the
    > root=UUID business with root=/dev/sda6.
    >
    > I think I'm understanding that I should fix the fstab somewhere, such as
    > the Ub part, and naturally I can and should fix the menu.lst in the Mepis
    > part. My questions are: is that correct? how exactly should it be
    > changed, and which ones? The fstab in Mepis doesn't do/show the UUID
    > business at all.
    >
    > One place I read about UUID fixing of fstab & menu.lst is here, but it
    > doesn't fit my case exactly
    > http://linuxmint.com/wiki/index.php/..._is_it_a_probl
    > em UUID -what is it and why is it a problem
    >
    >
    > --
    > Mike Easter
    >

    I have had great problems with the UUID scheme Ubuntu uses in fstab.
    Why they don't use an fstab which references a device (/dev/sda1 for
    example beats nme. I will never hand edit Ubunut fstab in the future.

    Marty

  5. Re: Fixing fstab & menu.lst UUID

    Mike Easter wrote:

    > title Ubuntu hardy (development branch), kernel 2.6.24-16-generic
    > root (hd0,5)
    > kernel /boot/vmlinuz-2.6.24-16-generic
    > root=UUID=69c7c703-c30d-4e16-9253-f6541b753662 ro quiet splash


    > This condition causes errors in the bootup process for Ub because the UUID
    > isn't recognized.


    I suppose the root= etc. is on the kernel line not the next line?

    What's the error message?

    > I can get around the problem during grub boot managing by replacing the
    > root=UUID business with root=/dev/sda6.


    What happens when you put /dev/sda6 into fstab instead of UUID= etc.?

    Does
    ls -l /dev/disk/by-uuid
    show the same UUID for /dev/sda6 as in fstab and menu.lst?

    --
    Niklaus

  6. Re: Fixing fstab & menu.lst UUID

    Marty Felker wrote:

    > I have had great problems with the UUID scheme Ubuntu uses in fstab.
    > Why they don't use an fstab which references a device (/dev/sda1 for
    > example beats nme. I will never hand edit Ubunut fstab in the future.
    >
    > Marty



    I've always heard to, "never say 'never.'"

    The Canonical reasoning for UUID was posted here by me a couple of weeks
    ago. It was a link to their site.

    Perhaps if you read it you would then know the why? Possibly even agree?

    Besides, you are free to create your own version of fstab, to use a
    different distro of GNU/Linux, to use Windows instead, or just pitch it
    all and go fishing.

    Where would you be the most happy?


    --
    John

    No Microsoft, Apple, AT&T, Intel, Novell, Trend Micro, nor Ford products were used in the preparation or transmission of this message.

    The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do. The GPL sounds like it was written by a human being, who wants me to know what I can do.

  7. Re: Fixing fstab & menu.lst UUID

    On 2008-07-15, Marty Felker wrote:

    > I have had great problems with the UUID scheme Ubuntu uses in fstab.
    > Why they don't use an fstab which references a device (/dev/sda1 for
    > example beats nme. I will never hand edit Ubunut fstab in the future.


    The reason becomes quite obvious when you use systems that are more
    complex than the standard home desktop with one or two IDE or SATA
    drives.

    For instance, most of our servers have Fibre Channel connections to
    SANs. They also have internal RAID adapters, and an IDE adapter for
    the CD/DVD.

    Now, this FC connection is often inserted before the RAID adapter.
    So, if I have 5 SAN connections and 2 Logical RAID volumes, and a CD,
    the devices will look like this:

    sda, sdb, sdc, sdd, sde = FC
    sdf, sdg = RAID
    sdh (or hda) = CD/DVD

    The boot partition is, of course, on the RAID adapter, at sdf1.

    So, what happens if I boot, but the FC adapter isn't working for some
    reason (be it a card issue, a SAN issue, or a cable issue)? The boot
    partition is now at sda1.

    If fstab were coded with /dev/sdf1 for /boot, I cannot boot. But, if
    the fstab is using either labels or UUID's, I can still boot, no
    problem, and start troubleshooting my SAN issue.

    The the question arises: Why use UUID's instead of labels?

    Well, a UUID is (theoretically) unique. A label, not so much. So,
    now, if somehow the SAN gets screwy and has the wrong assignments to
    the server, there may still be a volume labeled DATA, and the database
    residing there could get screwed up by being attached to the wrong
    server. BUT, if I am using UUID's, the mount doesn't happen, no
    corruption occurs, I troubleshoot the SAN, and all is good.

    Now, what about on your workstation. You don't have a SAN, so why
    does this matter?

    Well, you have USB. Now, perhaps (like me) you have several USB
    drives. These can get different dev assignments per boot, and they
    also would change if you are removing or inserting drives live. Label
    would work OK here, as you have limited drives and can manage them
    more easily, but UUID works too, and stays consistent...


    --
    Joe - Linux User #449481/Ubuntu User #19733
    joe at hits - buffalo dot com
    "Hate is baggage, life is too short to go around pissed off all the
    time..." - Danny, American History X

  8. Re: Fixing fstab & menu.lst UUID

    Marty Felker wrote:

    >I have had great problems with the UUID scheme Ubuntu uses in fstab.
    >Why they don't use an fstab which references a device (/dev/sda1 for
    >example beats nme. I will never hand edit Ubunut fstab in the future.


    If you reformat a partition with mkfs.ext3, then the UUID gets re-spun,
    and the label gets deleted. Changing UUIDs (and vanishing labels, even)
    have caused more trouble for me in a few months than any confusion over
    device ids ever did in years. But at least a label can normally be put
    back from memory.

    I'd recommend adding labels to all partitions and mod fstab for those.
    Grub's menu.lst as well, although I've reverted to device ids there.
    Non-unique labels are a potential source of problems, so just don't use
    labels like "data" or "ubuntu". BTW, only recent versions of mount can
    handle dos/ntfs labels/UUIDS.

    Useful stuff:

    display/set label on ext2/3 e2label [new-label]
    set swap label - BEWARE: ALTERS UUID mkswap -L /dev/sdaX
    set dos label (in mtools) mlabel -i /dev/sdaX ::
    set ntfs label (in ntfsprogs) ntfslabel /dev/sdaX
    shows UUID, label, and more vol_id /dev/sdaX
    list all labels blkid -s LABEL /dev/sda*
    Show mount points with labels mount -l

    Once you've set labels on all partitions, then you can convert UUIDs to
    labels in a file with this script. It might need to be run as root for
    some versions of the findfs and vol_id utilities. Supply the filename as
    a parameter, and a new file is created with the suffix .new

    #!/bin/bash
    [[ ! -r $1 ]] && echo "Can't read $1" && exit
    cp /dev/null $1.new
    [[ $? != 0 ]] && echo "Use file copy in user directory" && exit
    while read line; do
    if [[ "$line" == *UUID=* ]]; then
    uuid1=${line#*UUID=}
    uuid=${uuid1%%[[:blank:]]*}
    dev=$(findfs UUID="$uuid")
    label=$(vol_id -l "$dev")
    [[ -n "$label" ]] && line=${line//UUID=$uuid/LABEL=$label}
    fi
    echo $line >>$1.new
    done < $1

  9. Re: Fixing fstab & menu.lst UUID

    On 2008-07-17, Dave Farrance wrote:
    > Marty Felker wrote:
    >
    >>I have had great problems with the UUID scheme Ubuntu uses in fstab.
    >>Why they don't use an fstab which references a device (/dev/sda1 for
    >>example beats nme. I will never hand edit Ubunut fstab in the future.

    >
    > If you reformat a partition with mkfs.ext3, then the UUID gets re-spun,
    > and the label gets deleted. Changing UUIDs (and vanishing labels, even)
    > have caused more trouble for me in a few months than any confusion over
    > device ids ever did in years. But at least a label can normally be put
    > back from memory.


    Sure it does, as it should. And it takes no more than a couple of
    seconds to get the new information, and a few more to update fstab.
    No more time, AAMOF, than:

    >
    > I'd recommend adding labels to all partitions and mod fstab for those.
    > Grub's menu.lst as well, although I've reverted to device ids there.
    > Non-unique labels are a potential source of problems, so just don't use
    > labels like "data" or "ubuntu". BTW, only recent versions of mount can
    > handle dos/ntfs labels/UUIDS.
    >
    > Useful stuff:
    >
    > display/set label on ext2/3 e2label [new-label]
    > set swap label - BEWARE: ALTERS UUID mkswap -L /dev/sdaX
    > set dos label (in mtools) mlabel -i /dev/sdaX ::
    > set ntfs label (in ntfsprogs) ntfslabel /dev/sdaX
    > shows UUID, label, and more vol_id /dev/sdaX
    > list all labels blkid -s LABEL /dev/sda*
    > Show mount points with labels mount -l
    >
    > Once you've set labels on all partitions, then you can convert UUIDs to
    > labels in a file with this script. It might need to be run as root for
    > some versions of the findfs and vol_id utilities. Supply the filename as
    > a parameter, and a new file is created with the suffix .new
    >
    > #!/bin/bash
    > [[ ! -r $1 ]] && echo "Can't read $1" && exit
    > cp /dev/null $1.new
    > [[ $? != 0 ]] && echo "Use file copy in user directory" && exit
    > while read line; do
    > if [[ "$line" == *UUID=* ]]; then
    > uuid1=${line#*UUID=}
    > uuid=${uuid1%%[[:blank:]]*}
    > dev=$(findfs UUID="$uuid")
    > label=$(vol_id -l "$dev")
    > [[ -n "$label" ]] && line=${line//UUID=$uuid/LABEL=$label}
    > fi
    > echo $line >>$1.new
    > done < $1


    Doing all of this... ;-)


    --
    Joe - Linux User #449481/Ubuntu User #19733
    joe at hits - buffalo dot com
    "Hate is baggage, life is too short to go around pissed off all the
    time..." - Danny, American History X

  10. Re: Fixing fstab & menu.lst UUID

    Joe wrote:

    >On 2008-07-17, Dave Farrance wrote:


    >> ..Changing UUIDs (and vanishing labels, even) have caused more trouble
    >> for me in a few months than any confusion over device ids ever did in
    >> years. But at least a label can normally be put back from memory.

    >
    >Sure it does, as it should. And it takes no more than a couple of
    >seconds to get the new information, and a few more to update fstab.


    It's a bit more fiddly if the boot process has dropped you into the admin
    shell, but at least we agree that restoring a label to a partition is
    easy enough. I didn't like the way that UUIDs damaged the visual
    comprehensibility of fstab, with long strings of random digits making
    each entry wrap over two lines in the text editor.

    >No more time, AAMOF, than: Doing all of this... ;-)


    Yes, but "all of this" just the once to switch from UUIDs to labels --
    and then I found that fixing subsequent glitches was relatively easy.

    --
    Dave Farrance

  11. Re: Fixing fstab & menu.lst UUID

    On 2008-07-17, Dave Farrance wrote:
    > Joe wrote:
    >
    >>On 2008-07-17, Dave Farrance wrote:

    >
    >>> ..Changing UUIDs (and vanishing labels, even) have caused more trouble
    >>> for me in a few months than any confusion over device ids ever did in
    >>> years. But at least a label can normally be put back from memory.

    >>
    >>Sure it does, as it should. And it takes no more than a couple of
    >>seconds to get the new information, and a few more to update fstab.

    >
    > It's a bit more fiddly if the boot process has dropped you into the admin
    > shell, but at least we agree that restoring a label to a partition is
    > easy enough. I didn't like the way that UUIDs damaged the visual
    > comprehensibility of fstab, with long strings of random digits making
    > each entry wrap over two lines in the text editor.


    It's not more fiddly at all... ls -l /dev/disk/by-uuid to get the
    id's. nano /etc/fstab to fix the entries, then reboot. Takes no more
    time...

    And none of my entries wrap at all in my editor. Just change the size
    of the Window... ;-)

    >
    >>No more time, AAMOF, than: Doing all of this... ;-)

    >
    > Yes, but "all of this" just the once to switch from UUIDs to labels --
    > and then I found that fixing subsequent glitches was relatively easy.
    >


    It is. Either way. And UUID's are much more Unique than labels...
    Either way is much better than using the /dev/sdx designation, and for
    home use, labels are fine, but the system already comes configured
    with UUID's, so it just makes sense (to me, anyhow) to continue to use
    them...

    It's what makes Linux great... Choice! ;-)


    --
    Joe - Linux User #449481/Ubuntu User #19733
    joe at hits - buffalo dot com
    "Hate is baggage, life is too short to go around pissed off all the
    time..." - Danny, American History X

+ Reply to Thread