instead of root=/dev/sda2 you could use in the case you have got gpt this:
echo root=PARTUUID=$(blkid -p -s PART_ENTRY_UUID -o value /dev/root)
Thats usually not needed for only 1 internal hd, but would not hurt of course. A partuuid is the id of the partition and NOT the id of the filesystem, this is not supported without initrd. It is possible to boot with initrd as well, but i think you wanted to boot with max speed.
Hey, thanks! This worked really well. It seems that Ubuntu no longer mounts a /dev/root, but figured out the block-ID of /dev/sda2 with the command blkid -po udev /dev/sda2.
Originally Posted by Kano
You dont need to embed that, it can be read from the filesystem. You only have to be sure that your hd can be mounted without extra drivers - thats default for ubuntu kernels when you dont use raid. But in the case you want to boot with initrd, thats a piece of cake as well.
As you see you have to write the path to the initrd relatively to the efi partition, you can add a \ in front, but that is optional. You have to use \ and not / because that's the UEFI syntax. So whats your problem now? Btw you can use the root=UUID=... statement you usually get by
echo root=UUID=$(blkid -p -s UUID -o value /dev/root)
if you want when you use an initrd as well, thats the uuid of the filesystem - this would even work when you use mbr partitions - the efi fat partition must be a PRIMARY one in that case!
I tried this route, too, just for comparison. Indeed, the boot process takes about one second longer. Why does placing initrd in the EFI partition slow things down?
This has me wondering what precisely we are all referring to when talking about how long it takes to render.
Idk about the others, but I'm talking about how I can first see the background being rendered (from the bottom of the screen towards the top) and how the box around the screen is being rendered the same afterwards, together with the menu options. Th whole process takes about two seconds. If that's not slow, Idk what is.
Why does placing initrd in the EFI partition slow things down?
The initrd is already a mini linux which has udev and lots of drivers like all ethernet, filesystems and other modules. udev has to parse the filesystems for the UUIDs in order that you can boot from it - that usually takes time. PARTUUID is btw. not possible with udev/initrd on debian, no idea if you get the /dev/disk/by-partuuid symlinks with ubuntu. as udev is closely related to systemd it seems to work with fedora. (PART)UUID is always a good idea to use when you have got more than 1 hd. It is a bit suboptimal that you have to update the files manually, basically you could write a /etc/kernel/postinst.d hook similar to zz-update-grub, which copies the latest kernel/initrd at that place. I hope that now efi stub does not break again, that happend a few times, last with some kernel 3.5 rc. What worked up to kernel 3.4 was that rdev could be used to set a root device on the linux image so that you can boot without an root option, thats not possible anymore - a am not really happy about that, but nobody else seems to care.
Incorrect, when you use an initrd with udev that does NOT create those links it does not work. Without it works, you can use Debian wheezy to verify. If your udev creates those links it does no matter.
Well some things to add. Basically you would not need the .efi suffix when you use efibootmgr, you only need it when you use the efi shell. I hope that many Asus users will try adding a 2nd boot entry as latest uefi updates broke this. It is impossible to add more than 1 entry with the same -l option because only the latest one survives a reboot. Asus responded that Linux was not an offically supported system. If you happen to be an Asus user with that error just change the filename for the -l option a little bit - as it is fat you can swap upper/lowercase on any char - at least 1 char must be different. The extra options at the end or the label do not matter for this stupid uefi bug. Most likely it was done because Win is always detected and when you reinstall Win you would get double entries with this UEFI in the menu - others can do more, there you require a new efi shell or just linux Btw. this is very important: if you want to delete boot options, then remove ONLY those which are not created by the UEFI setup itself. This can kill some systems, a bit critical for laptops as you have to flash the chip again. Desktop board can be fixed more easyly by swapping the chip - some new Asus boards (series 7) happen to have even a new usb recovery flash way that works even without cpu - good idea because the system would not even POST in a worst case anyway...
Btw. this is very important: if you want to delete boot options, then remove ONLY those which are not created by the UEFI setup itself. This can kill some systems, a bit critical for laptops as you have to flash the chip again.
Heh...I actually made this mistake a few months ago. Accidentally deleted NVRAM variable Boot0004 (Intel Management Engine) from my Thinkpad T520. Fortunately I have Thinkpad X1 with the same UEFI, so I used the EFI shell to dump Boot0004 from the X1 to a file on a USB drive, and then loaded the variable from the file back into the NVRAM on the T520. Worked perfectly.
Oh yeah. Really, that should be the default display mode
I've been playing around with this stuff for some time now. I certainly don't claim to know everything (yet), but it's been fun. If you're curious, here are a couple more posts where I chronicle my experiences.