Slackware, GPT, UUIDs and Lilo

June 7th, 2013 by bostjan

Just recently I was “forced” to look into GPT partition tables support on Slackware linux because some drives installed were over 2TB of size. This is not going to be a long post, just a quick summary of findings.

– Slackware64 14.0 (64-bit, doh:)
– Lilo version 23.2 (stock version distributed with slackware)
– custom kernel version 3.9.4

What IS supported:
– parted: use instead of fdisk
– /etc/fstab: works normally, UUIDs too
– RAID (linux software raid): work with GPT
– LVM2: works with GPT

What IS NOT supported:
– fdisk: forget about this one, manual pages say GPT support is missing
– lilo can not work with UUID identifiers. Well it works OK when you execute it, but the system does not boot afterwards.

That’s it. I told you this is going to be short:)

Tags: , , , , ,

11 Responses to “Slackware, GPT, UUIDs and Lilo”

  1. giorgio says:

    why don’t you let us know with a good tutorial how you did the trick? please! thank you ๐Ÿ™‚

  2. bostjan says:

    @Giorgio: How about you create the tutorial and then I add a link to it below this article? ๐Ÿ™‚

    Despite the fact that your suggestion is a sane proposal, I really do not have time (nor interest, for that matter) for this. But I do support the initiative and potential endeavour on your part.

  3. giorgio says:

    sorry, I just wanted to know it ’cause I did it a simple tutorial to install slackware64 -current on sdd with gpt, btrfs having lilo as bootloader. that’all. but I just don’t know if I did all right. anyway, here it is:
    boot from slackware64-currentdvd
    # root
    # gdisk /dev/sda # example for partitioning
    1 2048 6143 2.0 MiB EF02 BIOS boot partition
    2 6144 1030143 200.0 MiB 8300 # this is /boot
    3 1030144 187557518 88.9 GiB 8300 # /
    # mkfs.ext4 /dev/sda2
    # mkfs.btrfs /dev/sda3
    # mount /dev/sda3 /mnt
    # mkdir -p /mnt/boot
    # mount /dev/sda2 /mnt/boot
    # setup
    go ahead, don’t create partition, don’t install lilo, exit setup and
    # chroot /mnt
    # cd /usr/share/mkinitrd/
    # ./
    # cd /mnt/boot
    # nano /etc/lilo.conf #this is mine for example
    boot = dev/sda
    bitmap = /boot/slack.bmp
    bmp-colors = 255,0,255,0,255,0
    bmp-table = 60,6,1,16
    bmp-timer = 65,27,0,255
    append=” rootdelay=40 quiet vt.default_utf8=0 rootfstype=btrfs”
    timeout = 50
    vga = normal

    image = /boot/vmlinuz-generic-your kernel
    append = “root=/dev/sda3”
    initrd = /boot/initrd.gz
    label = slackware
    read-only #save&exit nano
    # nano /etc/fstab
    /dev/sda2 /boot ext4 defaults,noatime,discard 0 0
    /dev/sda3 / btrfs defaults,ssd,discard,noatime,compress=lzo 0 1
    #/dev/cdrom /mnt/cdrom auto noauto,owner,ro,comment=x-gvfs-show 0 0
    #/dev/fd0 /mnt/floppy auto noauto,owner 0 0
    devpts /dev/pts devpts gid=5,mode=620 0 0
    proc /proc proc defaults 0 0
    tmpfs /dev/shm tmpfs defaults 0 0
    save&exit nano
    # exit
    # reboot
    boot from dvd again to see if it’s all workin’ this way

    huge.s root=/dev/sda3 rdinit= ro

    if it’all right with boot then login root and give lilo

    # lilo -v -b /dev/sda -r /
    # reboot
    the end! ๐Ÿ™‚

    I know it’s tricky but I told you, I just wanted to know how you did to be sure. thank you! ah, btrfs is experimental ,in fact after two months stopped working in my system. I had kernel 3.8.8

  4. bostjan says:

    Just to make sure, my config files, on this particular system which nudged me to write this blog post, look like this:

    —–[ /etc/fstab ]———————————————
    # /dev/md1
    UUID=413ede34-4638-4c54-80a1-8de5343d8cfd swap swap defaults 0 0

    # /dev/md2
    UUID=f85e16fb-76e3-4284-ab10-c0680ecc6b15 / ext4 defaults,noatime,nodiratime

    # /dev/md3
    UUID=4d847c6f-696c-4449-85ea-d985f1b3affb /var ext4 defaults,noatime,nodiratime

    —–[ /etc/lilo.conf ]———————————————
    message = /boot/boot_message.txt
    timeout = 20

    # This works ok
    boot = /dev/md120
    root = /dev/md120

    # This hangs the system
    #boot = /dev/disk/by-uuid/f85e16fb-76e3-4284-ab10-c0680ecc6b15
    #root = “UUID=f85e16fb-76e3-4284-ab10-c0680ecc6b15″

    # This writes correct MBR to both raid drives
    raid-extra-boot = mbr

    append = ” vt.default_utf8=0″
    vga = normal
    #password = “lilo”

    image = /boot/a2o-kernel64-3.9.4-8e0b
    label = 3.9.4-3

    image = /boot/a2o-kernel64-3.9.4-dde4
    label = 3.9.4-2

    image = /boot/vmlinuz
    label = dist

    As said above in the original post, /etc/fstab, RAID and LVM also work with GPT and UUIDs. But as you can se, I use fairly recent kernel. I did not try with older kernels, fortunately I do not have to ๐Ÿ™‚

  5. Ruarรญ ร˜degaard says:

    This might be of interest

    It doesn’t specifically addressing UUIDs but that should work with Grub 2 or Extlinux.

  6. Slacker says:

    Have been using uuids for about 1 year with lilo. Until this month I plugged in my clone usb drive (backup) and booted the main drive. Ended up with a mix of drive letters in mtab. Lilo DOES not USE the uuids (they are different on each drive. Further study showed that the /dev/disk/by-partuuid list and the mtab were identical. Looks like the name was being used and not uuid. Note: there were the proper number of partitions but from different drives. So much for lilo
    for modern systems.

  7. myname says:

    This post sucks. To top it off it shows up as one of the top entries in a google search regarding lilo and UUIDs. Things like “oh I did this in Linux and I’m so 1337!” should be reserved for twitter. Please add the appropriate tags on your web page to ask Google not to index you.

  8. bostjan says:

    This message above really made my day ๐Ÿ™‚

    @myname which is obviously not yourname:
    This post is a summary of hours of trial and error and compiling/recompiling/installing/rebooting of the systems, all in order to make it clear what does and what does not work. On server systems I use LILO extensively. I was therefore genuinely interested in subject, but the work itself felt frustrating at best. I did it once, and in order to never do it again (me or anyone else), I put the results online for everyone to see and NOT waste their time with trivial yet tedious work. Feel free to enjoy the free knowledge that is offered.

    As it seems you are quite frustrated with the content:
    How about doing your own proper research and trial-and-error exploration on the subject, and then creating a better post on your blog?
    If you do that and pingback with it’s URI, I will gladly publish it (URI, not your post) in the comments. I really like argumented feedback, it would not be the first time someone pointed out obvious flaws in my posts, with arguments and references to better work or prior art.

    As this is the first comment of such kind, I feel obliged to do/say three things:

    1. I have to publish your comment, for everyone to see what kind of comments I am talking about in this list;
    2. I have to apologise to all other, very polite and technically-well-versed visitors who seek information on subjects covered on this blog, for the harsh words that I am about to utter now; and
    3. How about you STFU when you have nothing adequate to contribute to the topic? How about you stop wasting my and other reader’s time with such non-comments? You are an obvious troll, and I hope you burn in hell and die!

    Also, this is the last comment+response of such nature that I will ever publish here. Similar comments in the future (if any, until now I’ve only had positive experience + spam:) will simply be deleted.

  9. Duncan Roe says:

    I did some experiments on this which hopefully shed some light:
    (using Slackware 14.2)
    – I normally build self-contained kernels which do not require an initrd
    – using LABEL= in lilo.conf caused a panic as discussed above
    – using LABEL= worked fine with a new initrd.gz created by “mkinitrd -c” and containing no modules at all
    – using LABEL= worked fine on an older kernel with the above initrd.gz. Some complaints about “no modules” flashed by

    The above were 64-bit kernels. Booting a 32-bit kernel revealed:
    – using LABEL= with a 32-bit kernel failed with the 64-bit initrd.gz above. The panic message said

    no working init found

    So it seems that the LABEL= or UUID= functionality is relying on init (in the initrd) to mount the root partition

  10. Duncan Roe says:

    I found out more:
    The kernel doesn’t understand LABEL or UUID, so init has to implement those.
    But the kernel *does* understand PartUUID (partition UUID, as returned by blkid).
    This comment block from init/do_mounts.c explains it nicely
    * Convert a name into device number. We accept the following variants:
    * 1) device number in hexadecimal represents itself
    * no leading 0x, for example b302.
    * 2) /dev/nfs represents Root_NFS (0xff)
    * 3) /dev/ represents the device number of disk
    * 4) /dev/ represents the device number
    * of partition – device number of disk plus the partition number
    * 5) /dev/p – same as the above, that form is
    * used when disk name of partitioned disk ends on a digit.
    * 6) PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF representing the
    * unique id of a partition if the partition table provides it.
    * The UUID may be either an EFI/GPT UUID, or refer to an MSDOS
    * partition using the format SSSSSSSS-PP, where SSSSSSSS is a zero-
    * filled hex representation of the 32-bit “NT disk signature”, and PP
    * is a zero-filled hex representation of the 1-based partition number.
    * 7) PARTUUID=/PARTNROFF= to select a partition in relation to
    * a partition with a known unique id.
    * 8) : major and minor number of the device separated by
    * a colon.
    * If name doesn’t have fall into the categories above, we return (0,0).
    * block_class is used to check if something is a disk name. If the disk
    * name contains slashes, the device name has them replaced with
    * bangs.

    LILO doesn’t know about PartUUID yet, so you have to use append, but I am now booting without an initrd using

    append=”apm=off root=PARTUUID=0aaac04b-04″

  11. bostjan says:

    Thank you for sharing your insights, Duncan. BTW were you using stock Slack 14.2 kernel or something newer?

Leave a Reply