Why can't I specify my root fs with a UUID?











up vote
25
down vote

favorite
5












My system boots OK with this in my GRUB 2 config:



linux   /bzImage root=/dev/sda2 init=/usr/lib/systemd/systemd ro


But if I replace /dev/sda2 with the corresponding UUID:



linux   /bzImage root=UUID=666c2eee-193d-42db-a490-4c444342bd4e init=/usr/lib/systemd/systemd ro


then it fails during boot:



kernel panic - not syncing: VFS: unable to mount root fs on unknown-block(0,0)


The UUID appears to be correct:



# blkid
/dev/sda1: UUID="97ac3744-39de-4d6d-9a81-e3a3ea08a8bb" TYPE="ext2"
/dev/sda2: UUID="666c2eee-193d-42db-a490-4c444342bd4e" TYPE="ext4"


Why doesn't it work? Is it because I'm not using an initramfs?



This is x86_64 Gentoo Linux with kernel 3.10.7. I'm using a MBR partition table on sda and a GUID partition table on sdb.










share|improve this question
























  • unknown-block(0,0) looks like a GRUB device to me. my guess is that GRUB can't use that UUID for some reason.
    – strugee
    Oct 6 '13 at 4:29










  • @strugee, I don't think GRUB attempts to interpret the kernel command line at all. (GRUB is loading the kernel from sda1. I didn't show that part of the config.)
    – cjm
    Oct 6 '13 at 4:32










  • I'm inclined to agree. it's weird, though, that the device looks like a GRUB device instead of a UNIX device.
    – strugee
    Oct 6 '13 at 4:34










  • @Gilles, the question isn't about GRUB. That just happens to be the bootloader I'm using. It's a Linux kernel question.
    – cjm
    Oct 7 '13 at 19:31










  • This isn't a question about the kernel either - this is a question about init.
    – mikeserv
    Aug 21 '14 at 22:48















up vote
25
down vote

favorite
5












My system boots OK with this in my GRUB 2 config:



linux   /bzImage root=/dev/sda2 init=/usr/lib/systemd/systemd ro


But if I replace /dev/sda2 with the corresponding UUID:



linux   /bzImage root=UUID=666c2eee-193d-42db-a490-4c444342bd4e init=/usr/lib/systemd/systemd ro


then it fails during boot:



kernel panic - not syncing: VFS: unable to mount root fs on unknown-block(0,0)


The UUID appears to be correct:



# blkid
/dev/sda1: UUID="97ac3744-39de-4d6d-9a81-e3a3ea08a8bb" TYPE="ext2"
/dev/sda2: UUID="666c2eee-193d-42db-a490-4c444342bd4e" TYPE="ext4"


Why doesn't it work? Is it because I'm not using an initramfs?



This is x86_64 Gentoo Linux with kernel 3.10.7. I'm using a MBR partition table on sda and a GUID partition table on sdb.










share|improve this question
























  • unknown-block(0,0) looks like a GRUB device to me. my guess is that GRUB can't use that UUID for some reason.
    – strugee
    Oct 6 '13 at 4:29










  • @strugee, I don't think GRUB attempts to interpret the kernel command line at all. (GRUB is loading the kernel from sda1. I didn't show that part of the config.)
    – cjm
    Oct 6 '13 at 4:32










  • I'm inclined to agree. it's weird, though, that the device looks like a GRUB device instead of a UNIX device.
    – strugee
    Oct 6 '13 at 4:34










  • @Gilles, the question isn't about GRUB. That just happens to be the bootloader I'm using. It's a Linux kernel question.
    – cjm
    Oct 7 '13 at 19:31










  • This isn't a question about the kernel either - this is a question about init.
    – mikeserv
    Aug 21 '14 at 22:48













up vote
25
down vote

favorite
5









up vote
25
down vote

favorite
5






5





My system boots OK with this in my GRUB 2 config:



linux   /bzImage root=/dev/sda2 init=/usr/lib/systemd/systemd ro


But if I replace /dev/sda2 with the corresponding UUID:



linux   /bzImage root=UUID=666c2eee-193d-42db-a490-4c444342bd4e init=/usr/lib/systemd/systemd ro


then it fails during boot:



kernel panic - not syncing: VFS: unable to mount root fs on unknown-block(0,0)


The UUID appears to be correct:



# blkid
/dev/sda1: UUID="97ac3744-39de-4d6d-9a81-e3a3ea08a8bb" TYPE="ext2"
/dev/sda2: UUID="666c2eee-193d-42db-a490-4c444342bd4e" TYPE="ext4"


Why doesn't it work? Is it because I'm not using an initramfs?



This is x86_64 Gentoo Linux with kernel 3.10.7. I'm using a MBR partition table on sda and a GUID partition table on sdb.










share|improve this question















My system boots OK with this in my GRUB 2 config:



linux   /bzImage root=/dev/sda2 init=/usr/lib/systemd/systemd ro


But if I replace /dev/sda2 with the corresponding UUID:



linux   /bzImage root=UUID=666c2eee-193d-42db-a490-4c444342bd4e init=/usr/lib/systemd/systemd ro


then it fails during boot:



kernel panic - not syncing: VFS: unable to mount root fs on unknown-block(0,0)


The UUID appears to be correct:



# blkid
/dev/sda1: UUID="97ac3744-39de-4d6d-9a81-e3a3ea08a8bb" TYPE="ext2"
/dev/sda2: UUID="666c2eee-193d-42db-a490-4c444342bd4e" TYPE="ext4"


Why doesn't it work? Is it because I'm not using an initramfs?



This is x86_64 Gentoo Linux with kernel 3.10.7. I'm using a MBR partition table on sda and a GUID partition table on sdb.







linux boot uuid






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Oct 7 '13 at 19:30

























asked Oct 6 '13 at 3:44









cjm

20.3k57073




20.3k57073












  • unknown-block(0,0) looks like a GRUB device to me. my guess is that GRUB can't use that UUID for some reason.
    – strugee
    Oct 6 '13 at 4:29










  • @strugee, I don't think GRUB attempts to interpret the kernel command line at all. (GRUB is loading the kernel from sda1. I didn't show that part of the config.)
    – cjm
    Oct 6 '13 at 4:32










  • I'm inclined to agree. it's weird, though, that the device looks like a GRUB device instead of a UNIX device.
    – strugee
    Oct 6 '13 at 4:34










  • @Gilles, the question isn't about GRUB. That just happens to be the bootloader I'm using. It's a Linux kernel question.
    – cjm
    Oct 7 '13 at 19:31










  • This isn't a question about the kernel either - this is a question about init.
    – mikeserv
    Aug 21 '14 at 22:48


















  • unknown-block(0,0) looks like a GRUB device to me. my guess is that GRUB can't use that UUID for some reason.
    – strugee
    Oct 6 '13 at 4:29










  • @strugee, I don't think GRUB attempts to interpret the kernel command line at all. (GRUB is loading the kernel from sda1. I didn't show that part of the config.)
    – cjm
    Oct 6 '13 at 4:32










  • I'm inclined to agree. it's weird, though, that the device looks like a GRUB device instead of a UNIX device.
    – strugee
    Oct 6 '13 at 4:34










  • @Gilles, the question isn't about GRUB. That just happens to be the bootloader I'm using. It's a Linux kernel question.
    – cjm
    Oct 7 '13 at 19:31










  • This isn't a question about the kernel either - this is a question about init.
    – mikeserv
    Aug 21 '14 at 22:48
















unknown-block(0,0) looks like a GRUB device to me. my guess is that GRUB can't use that UUID for some reason.
– strugee
Oct 6 '13 at 4:29




unknown-block(0,0) looks like a GRUB device to me. my guess is that GRUB can't use that UUID for some reason.
– strugee
Oct 6 '13 at 4:29












@strugee, I don't think GRUB attempts to interpret the kernel command line at all. (GRUB is loading the kernel from sda1. I didn't show that part of the config.)
– cjm
Oct 6 '13 at 4:32




@strugee, I don't think GRUB attempts to interpret the kernel command line at all. (GRUB is loading the kernel from sda1. I didn't show that part of the config.)
– cjm
Oct 6 '13 at 4:32












I'm inclined to agree. it's weird, though, that the device looks like a GRUB device instead of a UNIX device.
– strugee
Oct 6 '13 at 4:34




I'm inclined to agree. it's weird, though, that the device looks like a GRUB device instead of a UNIX device.
– strugee
Oct 6 '13 at 4:34












@Gilles, the question isn't about GRUB. That just happens to be the bootloader I'm using. It's a Linux kernel question.
– cjm
Oct 7 '13 at 19:31




@Gilles, the question isn't about GRUB. That just happens to be the bootloader I'm using. It's a Linux kernel question.
– cjm
Oct 7 '13 at 19:31












This isn't a question about the kernel either - this is a question about init.
– mikeserv
Aug 21 '14 at 22:48




This isn't a question about the kernel either - this is a question about init.
– mikeserv
Aug 21 '14 at 22:48










3 Answers
3






active

oldest

votes

















up vote
17
down vote













Just to clarify UUIDs are the only reliable way for the kernel to identify hard drives. There are two types: UUID, which is stored in the filesystem and is not available to the kernel at boot-time, and PARTUUID, which is stored in the partition table and IS available at boot time. So you have to use



root=PARTUUID=SSSSSSSS-PP


as /dev/sd?? can change with devices plugged/unplugged.



Don't forget to capitalize the hexadecimal number SSSSSSSS-PP you get from blkid!



The more easy to use



root=LABEL=
root=UUID=


only work with an initramfs that fetches these identifiers.



So, if you use a non-empty initramfs, you can have all three! With an empty initramfs, you only have PARTUUID.






share|improve this answer























  • Mind to explain who is using the boot=-argument then? I just used this line for an Archlinuxarm installation that doesn't have initrd, and where I can't use boot=LABEL nor boot=UUID.
    – ineiti
    Aug 21 '14 at 22:48












  • You're right - I corrected the boot to root, sorry! Hope it makes more sense now.
    – ineiti
    Aug 21 '14 at 22:57










  • Yes. The kernel will interpret a root= flag - but not in the sense i think you mean. There is no such thing as without initramfs - the root= flag points to an initramfs image which the kernel will extract into its own / with cpio. initrd is extinct - and has been since the 2.6 kernel was introduced.
    – mikeserv
    Aug 21 '14 at 23:01








  • 1




    My understanding (after one day on the forums of archlinuxarm) is that there is no initrd (or initramfs, but kernel.org/doc/Documentation/kernel-parameters.txt calls it initrd) on Archlinuxarm. On Ubuntu and such I do give a pointer to initrd, but (as to my understanding) not on Archlinuxarm.
    – ineiti
    Aug 22 '14 at 6:54






  • 1




    Archlinuxarm discussion about NO initrd: archlinuxarm.org/forum/viewtopic.php?f=23&t=6652
    – ineiti
    Aug 22 '14 at 7:18


















up vote
15
down vote













The parameter you have to pass to boot from UUID is PARTUUID. So it should be root=PARTUUID=666c2eee-193d-42db-a490-4c444342bd4e.



The documentation explains why it's coming back with unknown-block(0,0):



kernel-parameters.txt:




root= [KNL] Root filesystem
See name_to_dev_t comment in init/do_mounts.c.


init/do_mounts.c:




/*
* Convert a name into device number. We accept the following variants:
*
* 1) device number in hexadecimal represents itself
* 2) /dev/nfs represents Root_NFS (0xff)
* 3) /dev/<disk_name> represents the device number of disk
* 4) /dev/<disk_name><decimal> represents the device number
* of partition - device number of disk plus the partition number
* 5) /dev/<disk_name>p<decimal> - 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=<UUID>/PARTNROFF=<int> to select a partition in relation to
* a partition with a known unique id.
*
* 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.
*/


The last bit at the end says that if it can't understand the value, it returns (0,0), hence your error.






share|improve this answer



















  • 1




    This is only partially correct. A partition UUID is completely different from the filesystem's UUID, so PARTUUID=666c2eee-193d-42db-a490-4c444342bd4e does not work. However, I was able to use PARTUUID=SSSSSSSS-02 (where SSSSSSSS is the NT disk signature shown just before the error message).
    – cjm
    Oct 6 '13 at 5:42






  • 5




    So I guess that the real answer is that the kernel does not support root=UUID, only root=PARTUUID. If you want to use a filesystem UUID, I guess you need an initramfs that can handle mounting filesystems by UUID.
    – cjm
    Oct 6 '13 at 5:48










  • @cjm my grub boots quite happily with root=UUID.
    – terdon
    Oct 6 '13 at 14:30






  • 2




    @terdon, I'll bet you have an initramfs or initrd. (It could be linked into your kernel instead of being a separate file.)
    – cjm
    Oct 6 '13 at 14:59




















up vote
1
down vote













This is a 5 year old thread. But still it is imho not fully answered. There's a little example missing. Here it is:



In this example:



/dev/sda3 = /
/dev/sda2 = swap


...using a GPT partition. With MBR (dos partition) the PARTUUID's are shorter but the procedure is the same...



get the PARTUUID's with blkid:



blkid -s PARTUUID -o value /dev/sda3 # root
77fd7830-faa2-4e99-a48b-337ad9eded28
blkid -s PARTUUID -o value /dev/sda2 # swap
5b63167a-6fd2-4e72-948c-90832372956c


/boot/grub/grub.cfg:



search --no-floppy --part-uuid --set=root 77fd7830-faa2-4e99-a48b-337ad9eded28

menuentry "GNU/Linux, KERNEL 4.12.7-lfs-8.1" {
linux /boot/vmlinuz-4.12.7-lfs-8.1 root=PARTUUID=77fd7830-faa2-4e99-a48b-337ad9eded28 net.ifnames=0 ipv6.disable=1 ro rootwait rootfstype=ext4
}


/etc/fstab/:



PARTUUID=77fd7830-faa2-4e99-a48b-337ad9eded28 / ext4 noatime,nodiratime,errors=remount-ro 0 1
PARTUUID=5b63167a-6fd2-4e72-948c-90832372956c swap swap pri=1 0 0


This is known to WORK with lfs8.1 (kernel 4.12.7) But i think it should work with most other kernels too (olders and newers...)






share|improve this answer










New contributor




Michael H.G. Schmidt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.


















    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "106"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f93767%2fwhy-cant-i-specify-my-root-fs-with-a-uuid%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    3 Answers
    3






    active

    oldest

    votes








    3 Answers
    3






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    17
    down vote













    Just to clarify UUIDs are the only reliable way for the kernel to identify hard drives. There are two types: UUID, which is stored in the filesystem and is not available to the kernel at boot-time, and PARTUUID, which is stored in the partition table and IS available at boot time. So you have to use



    root=PARTUUID=SSSSSSSS-PP


    as /dev/sd?? can change with devices plugged/unplugged.



    Don't forget to capitalize the hexadecimal number SSSSSSSS-PP you get from blkid!



    The more easy to use



    root=LABEL=
    root=UUID=


    only work with an initramfs that fetches these identifiers.



    So, if you use a non-empty initramfs, you can have all three! With an empty initramfs, you only have PARTUUID.






    share|improve this answer























    • Mind to explain who is using the boot=-argument then? I just used this line for an Archlinuxarm installation that doesn't have initrd, and where I can't use boot=LABEL nor boot=UUID.
      – ineiti
      Aug 21 '14 at 22:48












    • You're right - I corrected the boot to root, sorry! Hope it makes more sense now.
      – ineiti
      Aug 21 '14 at 22:57










    • Yes. The kernel will interpret a root= flag - but not in the sense i think you mean. There is no such thing as without initramfs - the root= flag points to an initramfs image which the kernel will extract into its own / with cpio. initrd is extinct - and has been since the 2.6 kernel was introduced.
      – mikeserv
      Aug 21 '14 at 23:01








    • 1




      My understanding (after one day on the forums of archlinuxarm) is that there is no initrd (or initramfs, but kernel.org/doc/Documentation/kernel-parameters.txt calls it initrd) on Archlinuxarm. On Ubuntu and such I do give a pointer to initrd, but (as to my understanding) not on Archlinuxarm.
      – ineiti
      Aug 22 '14 at 6:54






    • 1




      Archlinuxarm discussion about NO initrd: archlinuxarm.org/forum/viewtopic.php?f=23&t=6652
      – ineiti
      Aug 22 '14 at 7:18















    up vote
    17
    down vote













    Just to clarify UUIDs are the only reliable way for the kernel to identify hard drives. There are two types: UUID, which is stored in the filesystem and is not available to the kernel at boot-time, and PARTUUID, which is stored in the partition table and IS available at boot time. So you have to use



    root=PARTUUID=SSSSSSSS-PP


    as /dev/sd?? can change with devices plugged/unplugged.



    Don't forget to capitalize the hexadecimal number SSSSSSSS-PP you get from blkid!



    The more easy to use



    root=LABEL=
    root=UUID=


    only work with an initramfs that fetches these identifiers.



    So, if you use a non-empty initramfs, you can have all three! With an empty initramfs, you only have PARTUUID.






    share|improve this answer























    • Mind to explain who is using the boot=-argument then? I just used this line for an Archlinuxarm installation that doesn't have initrd, and where I can't use boot=LABEL nor boot=UUID.
      – ineiti
      Aug 21 '14 at 22:48












    • You're right - I corrected the boot to root, sorry! Hope it makes more sense now.
      – ineiti
      Aug 21 '14 at 22:57










    • Yes. The kernel will interpret a root= flag - but not in the sense i think you mean. There is no such thing as without initramfs - the root= flag points to an initramfs image which the kernel will extract into its own / with cpio. initrd is extinct - and has been since the 2.6 kernel was introduced.
      – mikeserv
      Aug 21 '14 at 23:01








    • 1




      My understanding (after one day on the forums of archlinuxarm) is that there is no initrd (or initramfs, but kernel.org/doc/Documentation/kernel-parameters.txt calls it initrd) on Archlinuxarm. On Ubuntu and such I do give a pointer to initrd, but (as to my understanding) not on Archlinuxarm.
      – ineiti
      Aug 22 '14 at 6:54






    • 1




      Archlinuxarm discussion about NO initrd: archlinuxarm.org/forum/viewtopic.php?f=23&t=6652
      – ineiti
      Aug 22 '14 at 7:18













    up vote
    17
    down vote










    up vote
    17
    down vote









    Just to clarify UUIDs are the only reliable way for the kernel to identify hard drives. There are two types: UUID, which is stored in the filesystem and is not available to the kernel at boot-time, and PARTUUID, which is stored in the partition table and IS available at boot time. So you have to use



    root=PARTUUID=SSSSSSSS-PP


    as /dev/sd?? can change with devices plugged/unplugged.



    Don't forget to capitalize the hexadecimal number SSSSSSSS-PP you get from blkid!



    The more easy to use



    root=LABEL=
    root=UUID=


    only work with an initramfs that fetches these identifiers.



    So, if you use a non-empty initramfs, you can have all three! With an empty initramfs, you only have PARTUUID.






    share|improve this answer














    Just to clarify UUIDs are the only reliable way for the kernel to identify hard drives. There are two types: UUID, which is stored in the filesystem and is not available to the kernel at boot-time, and PARTUUID, which is stored in the partition table and IS available at boot time. So you have to use



    root=PARTUUID=SSSSSSSS-PP


    as /dev/sd?? can change with devices plugged/unplugged.



    Don't forget to capitalize the hexadecimal number SSSSSSSS-PP you get from blkid!



    The more easy to use



    root=LABEL=
    root=UUID=


    only work with an initramfs that fetches these identifiers.



    So, if you use a non-empty initramfs, you can have all three! With an empty initramfs, you only have PARTUUID.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Aug 22 '14 at 16:29

























    answered Aug 21 '14 at 22:37









    ineiti

    18615




    18615












    • Mind to explain who is using the boot=-argument then? I just used this line for an Archlinuxarm installation that doesn't have initrd, and where I can't use boot=LABEL nor boot=UUID.
      – ineiti
      Aug 21 '14 at 22:48












    • You're right - I corrected the boot to root, sorry! Hope it makes more sense now.
      – ineiti
      Aug 21 '14 at 22:57










    • Yes. The kernel will interpret a root= flag - but not in the sense i think you mean. There is no such thing as without initramfs - the root= flag points to an initramfs image which the kernel will extract into its own / with cpio. initrd is extinct - and has been since the 2.6 kernel was introduced.
      – mikeserv
      Aug 21 '14 at 23:01








    • 1




      My understanding (after one day on the forums of archlinuxarm) is that there is no initrd (or initramfs, but kernel.org/doc/Documentation/kernel-parameters.txt calls it initrd) on Archlinuxarm. On Ubuntu and such I do give a pointer to initrd, but (as to my understanding) not on Archlinuxarm.
      – ineiti
      Aug 22 '14 at 6:54






    • 1




      Archlinuxarm discussion about NO initrd: archlinuxarm.org/forum/viewtopic.php?f=23&t=6652
      – ineiti
      Aug 22 '14 at 7:18


















    • Mind to explain who is using the boot=-argument then? I just used this line for an Archlinuxarm installation that doesn't have initrd, and where I can't use boot=LABEL nor boot=UUID.
      – ineiti
      Aug 21 '14 at 22:48












    • You're right - I corrected the boot to root, sorry! Hope it makes more sense now.
      – ineiti
      Aug 21 '14 at 22:57










    • Yes. The kernel will interpret a root= flag - but not in the sense i think you mean. There is no such thing as without initramfs - the root= flag points to an initramfs image which the kernel will extract into its own / with cpio. initrd is extinct - and has been since the 2.6 kernel was introduced.
      – mikeserv
      Aug 21 '14 at 23:01








    • 1




      My understanding (after one day on the forums of archlinuxarm) is that there is no initrd (or initramfs, but kernel.org/doc/Documentation/kernel-parameters.txt calls it initrd) on Archlinuxarm. On Ubuntu and such I do give a pointer to initrd, but (as to my understanding) not on Archlinuxarm.
      – ineiti
      Aug 22 '14 at 6:54






    • 1




      Archlinuxarm discussion about NO initrd: archlinuxarm.org/forum/viewtopic.php?f=23&t=6652
      – ineiti
      Aug 22 '14 at 7:18
















    Mind to explain who is using the boot=-argument then? I just used this line for an Archlinuxarm installation that doesn't have initrd, and where I can't use boot=LABEL nor boot=UUID.
    – ineiti
    Aug 21 '14 at 22:48






    Mind to explain who is using the boot=-argument then? I just used this line for an Archlinuxarm installation that doesn't have initrd, and where I can't use boot=LABEL nor boot=UUID.
    – ineiti
    Aug 21 '14 at 22:48














    You're right - I corrected the boot to root, sorry! Hope it makes more sense now.
    – ineiti
    Aug 21 '14 at 22:57




    You're right - I corrected the boot to root, sorry! Hope it makes more sense now.
    – ineiti
    Aug 21 '14 at 22:57












    Yes. The kernel will interpret a root= flag - but not in the sense i think you mean. There is no such thing as without initramfs - the root= flag points to an initramfs image which the kernel will extract into its own / with cpio. initrd is extinct - and has been since the 2.6 kernel was introduced.
    – mikeserv
    Aug 21 '14 at 23:01






    Yes. The kernel will interpret a root= flag - but not in the sense i think you mean. There is no such thing as without initramfs - the root= flag points to an initramfs image which the kernel will extract into its own / with cpio. initrd is extinct - and has been since the 2.6 kernel was introduced.
    – mikeserv
    Aug 21 '14 at 23:01






    1




    1




    My understanding (after one day on the forums of archlinuxarm) is that there is no initrd (or initramfs, but kernel.org/doc/Documentation/kernel-parameters.txt calls it initrd) on Archlinuxarm. On Ubuntu and such I do give a pointer to initrd, but (as to my understanding) not on Archlinuxarm.
    – ineiti
    Aug 22 '14 at 6:54




    My understanding (after one day on the forums of archlinuxarm) is that there is no initrd (or initramfs, but kernel.org/doc/Documentation/kernel-parameters.txt calls it initrd) on Archlinuxarm. On Ubuntu and such I do give a pointer to initrd, but (as to my understanding) not on Archlinuxarm.
    – ineiti
    Aug 22 '14 at 6:54




    1




    1




    Archlinuxarm discussion about NO initrd: archlinuxarm.org/forum/viewtopic.php?f=23&t=6652
    – ineiti
    Aug 22 '14 at 7:18




    Archlinuxarm discussion about NO initrd: archlinuxarm.org/forum/viewtopic.php?f=23&t=6652
    – ineiti
    Aug 22 '14 at 7:18












    up vote
    15
    down vote













    The parameter you have to pass to boot from UUID is PARTUUID. So it should be root=PARTUUID=666c2eee-193d-42db-a490-4c444342bd4e.



    The documentation explains why it's coming back with unknown-block(0,0):



    kernel-parameters.txt:




    root= [KNL] Root filesystem
    See name_to_dev_t comment in init/do_mounts.c.


    init/do_mounts.c:




    /*
    * Convert a name into device number. We accept the following variants:
    *
    * 1) device number in hexadecimal represents itself
    * 2) /dev/nfs represents Root_NFS (0xff)
    * 3) /dev/<disk_name> represents the device number of disk
    * 4) /dev/<disk_name><decimal> represents the device number
    * of partition - device number of disk plus the partition number
    * 5) /dev/<disk_name>p<decimal> - 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=<UUID>/PARTNROFF=<int> to select a partition in relation to
    * a partition with a known unique id.
    *
    * 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.
    */


    The last bit at the end says that if it can't understand the value, it returns (0,0), hence your error.






    share|improve this answer



















    • 1




      This is only partially correct. A partition UUID is completely different from the filesystem's UUID, so PARTUUID=666c2eee-193d-42db-a490-4c444342bd4e does not work. However, I was able to use PARTUUID=SSSSSSSS-02 (where SSSSSSSS is the NT disk signature shown just before the error message).
      – cjm
      Oct 6 '13 at 5:42






    • 5




      So I guess that the real answer is that the kernel does not support root=UUID, only root=PARTUUID. If you want to use a filesystem UUID, I guess you need an initramfs that can handle mounting filesystems by UUID.
      – cjm
      Oct 6 '13 at 5:48










    • @cjm my grub boots quite happily with root=UUID.
      – terdon
      Oct 6 '13 at 14:30






    • 2




      @terdon, I'll bet you have an initramfs or initrd. (It could be linked into your kernel instead of being a separate file.)
      – cjm
      Oct 6 '13 at 14:59

















    up vote
    15
    down vote













    The parameter you have to pass to boot from UUID is PARTUUID. So it should be root=PARTUUID=666c2eee-193d-42db-a490-4c444342bd4e.



    The documentation explains why it's coming back with unknown-block(0,0):



    kernel-parameters.txt:




    root= [KNL] Root filesystem
    See name_to_dev_t comment in init/do_mounts.c.


    init/do_mounts.c:




    /*
    * Convert a name into device number. We accept the following variants:
    *
    * 1) device number in hexadecimal represents itself
    * 2) /dev/nfs represents Root_NFS (0xff)
    * 3) /dev/<disk_name> represents the device number of disk
    * 4) /dev/<disk_name><decimal> represents the device number
    * of partition - device number of disk plus the partition number
    * 5) /dev/<disk_name>p<decimal> - 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=<UUID>/PARTNROFF=<int> to select a partition in relation to
    * a partition with a known unique id.
    *
    * 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.
    */


    The last bit at the end says that if it can't understand the value, it returns (0,0), hence your error.






    share|improve this answer



















    • 1




      This is only partially correct. A partition UUID is completely different from the filesystem's UUID, so PARTUUID=666c2eee-193d-42db-a490-4c444342bd4e does not work. However, I was able to use PARTUUID=SSSSSSSS-02 (where SSSSSSSS is the NT disk signature shown just before the error message).
      – cjm
      Oct 6 '13 at 5:42






    • 5




      So I guess that the real answer is that the kernel does not support root=UUID, only root=PARTUUID. If you want to use a filesystem UUID, I guess you need an initramfs that can handle mounting filesystems by UUID.
      – cjm
      Oct 6 '13 at 5:48










    • @cjm my grub boots quite happily with root=UUID.
      – terdon
      Oct 6 '13 at 14:30






    • 2




      @terdon, I'll bet you have an initramfs or initrd. (It could be linked into your kernel instead of being a separate file.)
      – cjm
      Oct 6 '13 at 14:59















    up vote
    15
    down vote










    up vote
    15
    down vote









    The parameter you have to pass to boot from UUID is PARTUUID. So it should be root=PARTUUID=666c2eee-193d-42db-a490-4c444342bd4e.



    The documentation explains why it's coming back with unknown-block(0,0):



    kernel-parameters.txt:




    root= [KNL] Root filesystem
    See name_to_dev_t comment in init/do_mounts.c.


    init/do_mounts.c:




    /*
    * Convert a name into device number. We accept the following variants:
    *
    * 1) device number in hexadecimal represents itself
    * 2) /dev/nfs represents Root_NFS (0xff)
    * 3) /dev/<disk_name> represents the device number of disk
    * 4) /dev/<disk_name><decimal> represents the device number
    * of partition - device number of disk plus the partition number
    * 5) /dev/<disk_name>p<decimal> - 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=<UUID>/PARTNROFF=<int> to select a partition in relation to
    * a partition with a known unique id.
    *
    * 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.
    */


    The last bit at the end says that if it can't understand the value, it returns (0,0), hence your error.






    share|improve this answer














    The parameter you have to pass to boot from UUID is PARTUUID. So it should be root=PARTUUID=666c2eee-193d-42db-a490-4c444342bd4e.



    The documentation explains why it's coming back with unknown-block(0,0):



    kernel-parameters.txt:




    root= [KNL] Root filesystem
    See name_to_dev_t comment in init/do_mounts.c.


    init/do_mounts.c:




    /*
    * Convert a name into device number. We accept the following variants:
    *
    * 1) device number in hexadecimal represents itself
    * 2) /dev/nfs represents Root_NFS (0xff)
    * 3) /dev/<disk_name> represents the device number of disk
    * 4) /dev/<disk_name><decimal> represents the device number
    * of partition - device number of disk plus the partition number
    * 5) /dev/<disk_name>p<decimal> - 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=<UUID>/PARTNROFF=<int> to select a partition in relation to
    * a partition with a known unique id.
    *
    * 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.
    */


    The last bit at the end says that if it can't understand the value, it returns (0,0), hence your error.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Oct 9 '16 at 11:59









    Jeff Schaller

    38.1k1053124




    38.1k1053124










    answered Oct 6 '13 at 5:21









    Patrick

    49.8k11126178




    49.8k11126178








    • 1




      This is only partially correct. A partition UUID is completely different from the filesystem's UUID, so PARTUUID=666c2eee-193d-42db-a490-4c444342bd4e does not work. However, I was able to use PARTUUID=SSSSSSSS-02 (where SSSSSSSS is the NT disk signature shown just before the error message).
      – cjm
      Oct 6 '13 at 5:42






    • 5




      So I guess that the real answer is that the kernel does not support root=UUID, only root=PARTUUID. If you want to use a filesystem UUID, I guess you need an initramfs that can handle mounting filesystems by UUID.
      – cjm
      Oct 6 '13 at 5:48










    • @cjm my grub boots quite happily with root=UUID.
      – terdon
      Oct 6 '13 at 14:30






    • 2




      @terdon, I'll bet you have an initramfs or initrd. (It could be linked into your kernel instead of being a separate file.)
      – cjm
      Oct 6 '13 at 14:59
















    • 1




      This is only partially correct. A partition UUID is completely different from the filesystem's UUID, so PARTUUID=666c2eee-193d-42db-a490-4c444342bd4e does not work. However, I was able to use PARTUUID=SSSSSSSS-02 (where SSSSSSSS is the NT disk signature shown just before the error message).
      – cjm
      Oct 6 '13 at 5:42






    • 5




      So I guess that the real answer is that the kernel does not support root=UUID, only root=PARTUUID. If you want to use a filesystem UUID, I guess you need an initramfs that can handle mounting filesystems by UUID.
      – cjm
      Oct 6 '13 at 5:48










    • @cjm my grub boots quite happily with root=UUID.
      – terdon
      Oct 6 '13 at 14:30






    • 2




      @terdon, I'll bet you have an initramfs or initrd. (It could be linked into your kernel instead of being a separate file.)
      – cjm
      Oct 6 '13 at 14:59










    1




    1




    This is only partially correct. A partition UUID is completely different from the filesystem's UUID, so PARTUUID=666c2eee-193d-42db-a490-4c444342bd4e does not work. However, I was able to use PARTUUID=SSSSSSSS-02 (where SSSSSSSS is the NT disk signature shown just before the error message).
    – cjm
    Oct 6 '13 at 5:42




    This is only partially correct. A partition UUID is completely different from the filesystem's UUID, so PARTUUID=666c2eee-193d-42db-a490-4c444342bd4e does not work. However, I was able to use PARTUUID=SSSSSSSS-02 (where SSSSSSSS is the NT disk signature shown just before the error message).
    – cjm
    Oct 6 '13 at 5:42




    5




    5




    So I guess that the real answer is that the kernel does not support root=UUID, only root=PARTUUID. If you want to use a filesystem UUID, I guess you need an initramfs that can handle mounting filesystems by UUID.
    – cjm
    Oct 6 '13 at 5:48




    So I guess that the real answer is that the kernel does not support root=UUID, only root=PARTUUID. If you want to use a filesystem UUID, I guess you need an initramfs that can handle mounting filesystems by UUID.
    – cjm
    Oct 6 '13 at 5:48












    @cjm my grub boots quite happily with root=UUID.
    – terdon
    Oct 6 '13 at 14:30




    @cjm my grub boots quite happily with root=UUID.
    – terdon
    Oct 6 '13 at 14:30




    2




    2




    @terdon, I'll bet you have an initramfs or initrd. (It could be linked into your kernel instead of being a separate file.)
    – cjm
    Oct 6 '13 at 14:59






    @terdon, I'll bet you have an initramfs or initrd. (It could be linked into your kernel instead of being a separate file.)
    – cjm
    Oct 6 '13 at 14:59












    up vote
    1
    down vote













    This is a 5 year old thread. But still it is imho not fully answered. There's a little example missing. Here it is:



    In this example:



    /dev/sda3 = /
    /dev/sda2 = swap


    ...using a GPT partition. With MBR (dos partition) the PARTUUID's are shorter but the procedure is the same...



    get the PARTUUID's with blkid:



    blkid -s PARTUUID -o value /dev/sda3 # root
    77fd7830-faa2-4e99-a48b-337ad9eded28
    blkid -s PARTUUID -o value /dev/sda2 # swap
    5b63167a-6fd2-4e72-948c-90832372956c


    /boot/grub/grub.cfg:



    search --no-floppy --part-uuid --set=root 77fd7830-faa2-4e99-a48b-337ad9eded28

    menuentry "GNU/Linux, KERNEL 4.12.7-lfs-8.1" {
    linux /boot/vmlinuz-4.12.7-lfs-8.1 root=PARTUUID=77fd7830-faa2-4e99-a48b-337ad9eded28 net.ifnames=0 ipv6.disable=1 ro rootwait rootfstype=ext4
    }


    /etc/fstab/:



    PARTUUID=77fd7830-faa2-4e99-a48b-337ad9eded28 / ext4 noatime,nodiratime,errors=remount-ro 0 1
    PARTUUID=5b63167a-6fd2-4e72-948c-90832372956c swap swap pri=1 0 0


    This is known to WORK with lfs8.1 (kernel 4.12.7) But i think it should work with most other kernels too (olders and newers...)






    share|improve this answer










    New contributor




    Michael H.G. Schmidt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.






















      up vote
      1
      down vote













      This is a 5 year old thread. But still it is imho not fully answered. There's a little example missing. Here it is:



      In this example:



      /dev/sda3 = /
      /dev/sda2 = swap


      ...using a GPT partition. With MBR (dos partition) the PARTUUID's are shorter but the procedure is the same...



      get the PARTUUID's with blkid:



      blkid -s PARTUUID -o value /dev/sda3 # root
      77fd7830-faa2-4e99-a48b-337ad9eded28
      blkid -s PARTUUID -o value /dev/sda2 # swap
      5b63167a-6fd2-4e72-948c-90832372956c


      /boot/grub/grub.cfg:



      search --no-floppy --part-uuid --set=root 77fd7830-faa2-4e99-a48b-337ad9eded28

      menuentry "GNU/Linux, KERNEL 4.12.7-lfs-8.1" {
      linux /boot/vmlinuz-4.12.7-lfs-8.1 root=PARTUUID=77fd7830-faa2-4e99-a48b-337ad9eded28 net.ifnames=0 ipv6.disable=1 ro rootwait rootfstype=ext4
      }


      /etc/fstab/:



      PARTUUID=77fd7830-faa2-4e99-a48b-337ad9eded28 / ext4 noatime,nodiratime,errors=remount-ro 0 1
      PARTUUID=5b63167a-6fd2-4e72-948c-90832372956c swap swap pri=1 0 0


      This is known to WORK with lfs8.1 (kernel 4.12.7) But i think it should work with most other kernels too (olders and newers...)






      share|improve this answer










      New contributor




      Michael H.G. Schmidt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.




















        up vote
        1
        down vote










        up vote
        1
        down vote









        This is a 5 year old thread. But still it is imho not fully answered. There's a little example missing. Here it is:



        In this example:



        /dev/sda3 = /
        /dev/sda2 = swap


        ...using a GPT partition. With MBR (dos partition) the PARTUUID's are shorter but the procedure is the same...



        get the PARTUUID's with blkid:



        blkid -s PARTUUID -o value /dev/sda3 # root
        77fd7830-faa2-4e99-a48b-337ad9eded28
        blkid -s PARTUUID -o value /dev/sda2 # swap
        5b63167a-6fd2-4e72-948c-90832372956c


        /boot/grub/grub.cfg:



        search --no-floppy --part-uuid --set=root 77fd7830-faa2-4e99-a48b-337ad9eded28

        menuentry "GNU/Linux, KERNEL 4.12.7-lfs-8.1" {
        linux /boot/vmlinuz-4.12.7-lfs-8.1 root=PARTUUID=77fd7830-faa2-4e99-a48b-337ad9eded28 net.ifnames=0 ipv6.disable=1 ro rootwait rootfstype=ext4
        }


        /etc/fstab/:



        PARTUUID=77fd7830-faa2-4e99-a48b-337ad9eded28 / ext4 noatime,nodiratime,errors=remount-ro 0 1
        PARTUUID=5b63167a-6fd2-4e72-948c-90832372956c swap swap pri=1 0 0


        This is known to WORK with lfs8.1 (kernel 4.12.7) But i think it should work with most other kernels too (olders and newers...)






        share|improve this answer










        New contributor




        Michael H.G. Schmidt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.









        This is a 5 year old thread. But still it is imho not fully answered. There's a little example missing. Here it is:



        In this example:



        /dev/sda3 = /
        /dev/sda2 = swap


        ...using a GPT partition. With MBR (dos partition) the PARTUUID's are shorter but the procedure is the same...



        get the PARTUUID's with blkid:



        blkid -s PARTUUID -o value /dev/sda3 # root
        77fd7830-faa2-4e99-a48b-337ad9eded28
        blkid -s PARTUUID -o value /dev/sda2 # swap
        5b63167a-6fd2-4e72-948c-90832372956c


        /boot/grub/grub.cfg:



        search --no-floppy --part-uuid --set=root 77fd7830-faa2-4e99-a48b-337ad9eded28

        menuentry "GNU/Linux, KERNEL 4.12.7-lfs-8.1" {
        linux /boot/vmlinuz-4.12.7-lfs-8.1 root=PARTUUID=77fd7830-faa2-4e99-a48b-337ad9eded28 net.ifnames=0 ipv6.disable=1 ro rootwait rootfstype=ext4
        }


        /etc/fstab/:



        PARTUUID=77fd7830-faa2-4e99-a48b-337ad9eded28 / ext4 noatime,nodiratime,errors=remount-ro 0 1
        PARTUUID=5b63167a-6fd2-4e72-948c-90832372956c swap swap pri=1 0 0


        This is known to WORK with lfs8.1 (kernel 4.12.7) But i think it should work with most other kernels too (olders and newers...)







        share|improve this answer










        New contributor




        Michael H.G. Schmidt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.









        share|improve this answer



        share|improve this answer








        edited yesterday





















        New contributor




        Michael H.G. Schmidt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.









        answered yesterday









        Michael H.G. Schmidt

        112




        112




        New contributor




        Michael H.G. Schmidt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.





        New contributor





        Michael H.G. Schmidt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.






        Michael H.G. Schmidt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f93767%2fwhy-cant-i-specify-my-root-fs-with-a-uuid%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Entries order in /etc/network/interfaces

            新発田市

            Grub takes very long (several minutes) to open Menu (in Multi-Boot-System)