grub2 supports LABEL=
Hi
in another thread I was asked this question and finally got around to looking at it....Version 1.98-1 1) Create label :: Code ::
su tune2fs -L sexy /dev/sda1 tune2fs -l /dev/sda1 | grep sexy Filesystem volume name: sexy 2) Create some lines in 40_custom or manually test in your grub.cfg remember that unless you use 40_custom any ....update-grub command done by you or done by smxi....will revert to old style....hint hint Put in a box to highlight the entries to add to 40_custom then run update-grub Test 1 and test 2 both boot ok for me...YMMV :: Quote ::
menuentry "test1" { insmod search_label set root=(hd0,1) search --no-floppy --fs-label --set sexy linux /boot/vmlinuz-2.6.34-0.slh.4-sidux-686 root=LABEL=sexy ro vga=791 initrd /boot/initrd.img-2.6.34-0.slh.4-sidux-686 } :: Quote ::
menuentry "test2" { insmod search_label set root=(hd0,1) linux /boot/vmlinuz-2.6.34-0.slh.4-sidux-686 root=LABEL=sexy ro vga=791 initrd /boot/initrd.img-2.6.34-0.slh.4-sidux-686 } Back to top |
|||||
While theoretically interesting, this isn't what i was referring to.
What i mean is LABEL= functioning exactly as UUID= in for example /etc/grub.default or whatever that main file is. there's some flag to set UUID in that main config, and that's what is missing, to simply say, use this LABEL when updating grub. That's what the debian patch did, but I can't find it or the issue report, google wasn't helpful, but I read it, it was a simple patch, not clear on why it was even needed in the first place, it should have been a built in to begin with. The example you gave is hardcoded, and wouldn't really help in a real scenario, in other words, when the kernel upgrades, that would fail to boot, or would boot into the wrong kernel. Hopefully one day grub2 will actually have the basic capacities of grub1, plus the new stuff, but it looks like it's still quite far off. By the way, your sample to me is a clear example of just what is wrong with grub2. You shouldn't need to insert the label module manually, that's absurd, that's what programming is for, to detect that syntax and do it for you. I'm really starting to wonder about just who it was who designed and coded grub2, they seem to basically have no programming ability at all, or ran out of time and weren't able to actually finish anything except the most basic functionality, stuff you'd expect from pre alpha software. Same for that programming syntax, why on earth is that required? It's just totally absurd. One of the biggest overall regressions I've seen so far in any major project. Like why was grub1 smart enough to know that the string: root= means that is going to be the root, but grub2 requires the pointless extra word 'set' to tell it? Examples like this really make me wonder about the guy who designed this, it's like geek to the nth power, totally absurd. Back to top |
|||||
hi
my bad test, I inserted that module but have just tested my 40_custom way without needing it so :: Quote ::
menuentry "test3" { set root=(hd0,1) linux /boot/vmlinuz-2.6.34-0.slh.4-sidux-686 root=LABEL=sexy ro vga=791 initrd /boot/initrd.img-2.6.34-0.slh.4-sidux-686 } 2) yes you are correct yet again.... /etc/default/grub has no mention of being able to set label or not. My way requires an edit to 40_custom on each kernel upgrade 4) Maybe smxi could symlink the latest kernel to vmlinuz and then 40_custom would never change? Ditto the initrd? Its a work-a-round I know but we could always do it manually after exitting smxi, just run a command before reboot?....if its too much work to have in smxi Maybe something like :: Quote ::
menuentry "test3" { set root=(hd0,1) linux /boot/vmlinuz root=LABEL=sexy ro vga=791 initrd /boot/initrd.img } Back to top |
|||||
I believe the new kernel always sym links to that file. But that's such an extreme hack I wouldn't even consider it, though I do have to use a method like that to boot ubuntu for some reason from grub1.
But this isnt' the fix I was talking about, I'm not sure why I couldn't find the patch, it's very simple, so simple I have no idea why it's not in grub2 default yet. Back to top |
|||||
Ok, found parts of it: launchpad bug 431179
That is not the right bug, but it's part of it, though a lesser part. I don't know why I can't find that patch/bug report again, it used to come up in google easily. What I'm talking about is a patch to make a new global default value in /etc/grub/default for LABEL mounting in grub2. The patch was from Debian I believe. Back to top |
|||||
hi
well I have not searched for bugs that way but found this which may help explain it? bugs.launchpad.net/ubuntu/+source/util-linux/+bug/197311 post 16 + 19 seemed worthy? :: Quote :: The vol_id patches to mount will fail to resolve LABEL= and UUID= parameters for newly created filesystems until you reboot:: Quote :: SuSE's patches (which we inherited) to util-linux get around the fact
that libvolume_id doesn't behave this way by actually not using it at all. Instead they map UUID= and LABEL= mounts into /dev/disk/by-uuid and /dev/disk/by-label paths. These are maintained by udev based on its own probing calls with libvolume_id. Obviously because they're maintained by udev, there's a big drawback - it doesn't know if the filesystem changes. And that's why you have to reboot (or write the word "change" to the uevent file of the block device). EDIT Is this the Debian patch you were looking for? groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/cade1cfe23e9766a/1da81e826ece3338?lnk=gst&q=554790+#1da81e826ece3338 Back to top |
|||||
The debian one, no, it's something else.
The one I remember was a few patches to the config files that would then enable using LABEL but looks like you're finding parts of it. Back to top |
|||||
hi
sorry to disappoint you again..I am no longer looking at debian bugs but the concept of getting rid of of /etc scripts. Instead I am playing with Tinycore and grub2 using no /etc scripts and treating grub.cfg as an absolute config file similar to menu.lst 1) It works where I install direct to mbr but my first attempts to generate an core.img and force install into sda1 (etc) are not so good. Meaning chainload stage is not available this way. Some of the issues appear to relate to www.linuxfromscratch.org/hints/downloads/files/grub2.txt namely: TC uses bzImage and not vmlin* (2) grub-setup=/bin/true fails for me with either busybox or coreutls version of /bin/true the work-a-round for sym links looks ok for bzImage but still looking into the chainload issue. regards Back to top |
|||||
whoah, I had a (brief, not to be repeated, don't worry) stroke of genius, and, get this... I checked my bookmarks, grub directory, and there it was, the bookmark!:
Note: this is the real fix, this code is now tested and debugged and working Bug#568084: grub-common: Use of LABEL for 'root=' :: Code :: Package: grub-common
Version: 1.98~20100115-1 Severity: wishlist Tags: patch Patch for /etc/grub.d/10_linux, so you can use LABEL beside UUID and devices. Activation in /etc/default/grub with: ## MUST BE COMMENTED OUT!!! fails if uncommented! # GRUB_DISABLE_LINUX_UUID=true GRUB_ENABLE_LINUX_LABEL=true Thanks christian -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages grub-common depends on: ii base-files 5.0.0 Debian base system miscellaneous f ii dpkg 1.15.5.6 Debian package management system ii gettext-base 0.17-8 GNU Internationalization utilities ii install-info 4.13a.dfsg.1-5 Manage installed documentation in ii libc6 2.10.2-2 GNU C Library: Shared libraries ii libfreetype6 2.3.11-1 FreeType 2 font engine, shared lib ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages grub-common recommends: pn os-prober <none> (no description available) Versions of packages grub-common suggests: pn grub-emu <none> (no description available) pn multiboot-doc <none> (no description available) -- no debconf information --- 10_linux 2010-07-12 13:10:04.000000000 +0200 +++ 10_linux_+label 2010-08-18 09:17:33.816200799 +0200 @@ -49,6 +49,12 @@ LINUX_ROOT_DEVICE=${GRUB_DEVICE} else LINUX_ROOT_DEVICE=UUID=${GRUB_DEVICE_UUID} + GRUB_DEVICE_LABEL="$(blkid -l -t UUID=${GRUB_DEVICE_UUID} -s LABEL -o value)" + . /etc/default/grub + if [ "x${GRUB_ENABLE_LINUX_LABEL}" = "xtrue" ] \ + && test -e "/dev/disk/by-label/${GRUB_DEVICE_LABEL}" ; then + LINUX_ROOT_DEVICE=LABEL=${GRUB_DEVICE_LABEL} + fi fi ## note this: - it moved after the setting of LINUX_ROOT_DEVICE=UUID=...., the previous was not correct. - it sources /etc/default/grub for reading the Value of my Variable GRUB_ENABLE_LINUX_LABEL, because that is no Variable in /usr/sbin/update-grub (maybe it will be?). Also 20_linux_xen can be patched with this. Activation in /etc/default/grub with: #GRUB_DISABLE_LINUX_UUID=true (not disable the LINUX_UUID!) GRUB_ENABLE_LINUX_LABEL=true and to get rid of the search --no-floppy --fs-uuid --set <uuid string> do this. Open /usr/lib/grub/grub-mkconfig_lib find: (about line 130) :: Code :: if fs_uuid="`${grub_probe} --device ${device} --target=fs_uuid 2> /dev/null`" ; then
echo "search --no-floppy --fs-uuid --set ${fs_uuid}" fi change to :: Code :: if label="`${grub_probe} --device ${device} --target=fs_label 2> /dev/null`" ; then
echo "search --no-floppy --label --set=root ${label}" elif fs_uuid="`${grub_probe} --device ${device} --target=fs_uuid 2> /dev/null`" ; then echo "search --no-floppy --fs-uuid --set=root ${fs_uuid}" fi Also note that you have to comment # GRUB_DISABLE_LINUX_UUID=true for this to work. this gives this result: :: Code :: menuentry 'Debian GNU/Linux, with Linux 2.6.32-trunk-686' --class debian --class gnu-linux --class gnu --class os {
insmod part_msdos insmod ext2 set root='(hd0,msdos2)' search --no-floppy --label --set=root main-root-1 echo 'Loading Linux 2.6.32-trunk-686 ...' linux /boot/vmlinuz-2.6.32-trunk-686 root=LABEL=main-root-1 ro ramdisk_size=100000 lang=us apm=power-off nomce vga=0x317 acpi_enforce_resources=lax quiet echo 'Loading initial ramdisk ...' initrd /boot/initrd.img-2.6.32-trunk-686 } So to get a simple change like a label added, we have to edit not one, not two, but three separate files, and that's not even creating the chainloader things. Pathetic if you ask me, and this is TOTALLY impossible for normal users to achieve, nobody could ever intuitively get to this point. Back to top |
|||||
I found another how-to from ubuntu for labels, why this isn't default in grub is absolutely beyond me, and makes me have little hope for grub2 ever being really usable, but here goes:
GRUB2 booting with labels (no UUID) :: Code :: 1. changed /etc/defaults/grub
uncommented this line and used quotes around true: Code: GRUB_DISABLE_LINUX_UUID="true" :: Code :: 2. changed /etc/grub.d/10_linux as follows:
Code: auto_label="`e2label ${GRUB_DEVICE_BOOT} 2>/dev/null`" linux_root_device_thisversion="LABEL=${auto_label}" cat << EOF linux ${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro ${args} EOF :: Code :: 3. changed /usr/lib/grub/grub-mkconfig_lib as follows. I know this code could be improved by including it in a proper conditional, but I didn't know how to do that. So it just executes always.
Code: # If there's a filesystem UUID that GRUB is capable of identifying, use it; # otherwise set root as per value in device.map. echo "set root='`${grub_probe} --device ${device} --target=drive`'" #if fs_label="`${grub_probe} --device ${device} --target=fs_uuid 2> /dev/null`" ; then #echo "search --no-floppy --fs-uuid --set ${fs_uuid}" #fi auto_label="`e2label ${device} 2>/dev/null`" echo "search --no-floppy --label ${auto_label} --set root" Note, he was close here, this is the conditional: :: Code :: if label="`${grub_probe} --device ${device} --target=fs_label 2> /dev/null`" ; then
echo "search --no-floppy --label --set ${label}" elif fs_uuid="`${grub_probe} --device ${device} --target=fs_uuid 2> /dev/null`" ; then echo "search --no-floppy --fs-uuid --set ${fs_uuid}" fi :: Code :: Those changes generate perfect (as far as I'm concerned) stanzas in grub.cfg. And my test machine boots as expected.
Code: menuentry "Linux Mint 9, 2.6.32-21-generic (/dev/sda1) -- recovery mode" --class linuxmint --class gnu-linux --class gnu --class os { recordfail insmod ext2 set root='(hd0,1)' search --no-floppy --label my_label --set root echo 'Loading Linux 2.6.32-21-generic ...' linux /boot/vmlinuz-2.6.32-21-generic root=LABEL=my_label ro single echo 'Loading initial ramdisk ...' initrd /boot/initrd.img-2.6.32-21-generic } Back to top |
|||||
All times are GMT - 8 Hours
|