Skip to contentSkip to conversation

Linux not adhering to BIOS Drive boot order?

DISCUSSION David Balazic 2 participants 3 messages Jan 17, 2001 – Jan 18, 2001

lore
Share & tools
lore
#0 lore raw
Quoted 10 lines · Andreas Dilger
Quoted 4 lines · David Woodhouse

There are patches available for the 2.2 kernel which provide the facility to mount by UUID or volume label. It seems that nobody is actively maintaining those at the moment. If you want to update those to the current 2.2 and 2.4 kernels, well volunteered.

I'm quite interested in this patch, and have taken a good look at it. Some changes are in order (IMHO) to make it more usable. It should take parameters that are the same as in /etc/fstab (i.e. LABEL= and UUID= instead of L: and UUID:).

A trivial change...

Quoted 4 lines

In the end I re-wrote most of the patch, so
that we resolve ROOT_DEV before calling mount_root(), just to be a bit more consistent. I will release a new patch for 2.2.18 and 2.4.0 after David Balazic has a look at it.

Cool, send it to me !

Quoted 2 lines

I know a bit about LILO, so I should be able to get the "root=LABEL=" to work there as well.

There were no problems with the original patch with LILO. You just must use append="root=xxxxx" instead of simply root=xxx , because LILO tries to be "smart" .... at least the version I used then did.

Quoted 9 lines

I also need to do some work like this in e2fsprogs, so it may make sense to create a little library that can be updated to handle other kinds of filesystem/partition LABELs and UUIDs as the need arises. They were talking about putting a LABEL/UUID into reiserfs recently. This saves us from having to fix ext2-specific in dozens of utilities (e.g. LILO, mount, fsck, dump, etc).

One reason why this may NOT ever make it into the kernel is that I know "kernel poking at devices" is really frowned upon.

This an ugly hack , if you ask me. The identificators ( be it labels , UUIDs
or whatever ) should be outside the partitions. Otherwise cases with swap partitions , <any FS that doesn't support labels/UUIDs> unformatted partitions etc. can not be handled.

Signature · 8 lines
David Balazic
--------------
"Be excellent to each other." - Bill & Ted
- - - - - - - - - - - - - - - - - - - - - -
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#1 lore raw
Quoted 7 lines · David Balazic
Quoted 4 lines · Andreas Dilger

In the end I re-wrote most of the patch, so
that we resolve ROOT_DEV before calling mount_root(), just to be a bit more consistent. I will release a new patch for 2.2.18 and 2.4.0 after David Balazic has a look at it.

Cool, send it to me !

Need to test it a bit first (i.e. at least compile it)...

Quoted 7 lines
Quoted 2 lines

I know a bit about LILO, so I should be able to get the "root=LABEL=" to work there as well.

There were no problems with the original patch with LILO. You just must use append="root=xxxxx" instead of simply root=xxx , because LILO tries to be "smart" .... at least the version I used then did.

Actually, there are 2 ways to go about this: LILO could do the UUID/LABEL resolution at the time lilo is run (to store root dev into kernel), and _also_ append "root=LABEL=X" to kernel options, so that if the kernel can't resolve the UUID/LABEL (i.e. no support for this option) we can fall back to the root dev from when LILO was run.

Quoted 7 lines
Quoted 2 lines

One reason why this may NOT ever make it into the kernel is that I know "kernel poking at devices" is really frowned upon.

This an ugly hack , if you ask me. The identificators ( be it labels , UUIDs or whatever ) should be outside the partitions. Otherwise cases with swap partitions , <any FS that doesn't support labels/UUIDs> unformatted partitions etc. can not be handled.

LVM now has UUID-like identifiers for all "partitions" (Logical Volumes), although they are not really accessible by any tools right now. The "LABEL" is actually the LV name, so it is used directly all the time:

/dev/vgroot/lvroot / ext3 defaults 1 1
/dev/vgroot/lvswap none swap sw,pri=100 0 0

This obviates most of the reason for the UUID/LABEL support, but not everyone runs LVM (yet ;-) and ext2 UUID/LABELs are still useful.

Cheers, Andreas

Signature · 7 lines
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#2 lore raw
Quoted 11 lines · Andreas Dilger
Quoted 7 lines · David Balazic
Quoted 4 lines · Andreas Dilger

In the end I re-wrote most of the patch, so
that we resolve ROOT_DEV before calling mount_root(), just to be a bit more consistent. I will release a new patch for 2.2.18 and 2.4.0 after David Balazic has a look at it.

Cool, send it to me !

Need to test it a bit first (i.e. at least compile it)...

I will just throw a quick look into it , nothing more , as my setup is a mess right now. I no kernel guru either, I just wrote the patch :-)

Quoted 1 line
Quoted 1 line
Quoted 1 line

I know a bit about LILO, so I should be able to get the

"root=LABEL=" to

Quoted 21 lines
Quoted 6 lines
Quoted 1 line

work there as well.

There were no problems with the original patch with LILO. You just must use append="root=xxxxx" instead of simply root=xxx , because LILO tries to be "smart" .... at least the version I used then did.

Actually, there are 2 ways to go about this: LILO could do the UUID/LABEL resolution at the time lilo is run (to store root dev into kernel), and _also_ append "root=LABEL=X" to kernel options, so that if the kernel can't resolve the UUID/LABEL (i.e. no support for this option) we can fall back to the root dev from when LILO was run.

Quoted 7 lines
Quoted 2 lines

One reason why this may NOT ever make it into the kernel is that I know "kernel poking at devices" is really frowned upon.

This an ugly hack , if you ask me. The identificators ( be it labels , UUIDs or whatever ) should be outside the partitions. Otherwise cases with swap partitions , <any FS that doesn't support labels/UUIDs> unformatted partitions etc. can not be handled.

Quoted 6 lines

LVM now has UUID-like identifiers for all "partitions" (Logical Volumes), although they are not really accessible by any tools right now. The "LABEL" is actually the LV name, so it is used directly all the time:

/dev/vgroot/lvroot      /       ext3    defaults        1       1
/dev/vgroot/lvswap      none    swap    sw,pri=100      0       0

Is /dev/vgroot some kind of pseudo filesystem ?
With plain device files you have the same problems as with the "old" partitions , I think. ( they have to be mapped to minors and nodes for them must be created somehow ). I didn't try it yet and with devfs it should work OK.

Quoted 2 lines

This obviates most of the reason for the UUID/LABEL support, but not everyone runs LVM (yet ;-) and ext2 UUID/LABELs are still useful.

And LVM is not windows compatible , AFAIK, is it ?

Signature · 8 lines
David Balazic
--------------
"Be excellent to each other." - Bill & Ted
- - - - - - - - - - - - - - - - - - - - - -
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/