Announcement

Collapse
No announcement yet.

Ubuntu Switches Back To GRUB2 For SecureBoot

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Kano
    replied
    Originally posted by steveriley View Post
    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.

    Leave a comment:


  • bug77
    replied
    Originally posted by randomizer View Post
    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.

    Leave a comment:


  • steveriley
    replied
    Originally posted by Kano View Post
    That's pretty simple (lets think you use /dev/sda1 for /boot/efi - basically i would not even need -d/p in that case and /dev/sda2 for /), try this
    Code:
    sudo cp /boot/vmlinuz-$(uname -r) /boot/efi/EFI/ubuntu/linux.efi
    sudo efibootmgr -c -d /dev/sda -p 1 -l '\EFI\ubuntu\linux.efi' -L 'Ubuntu direct' -u 'quiet root=/dev/sda2'
    instead of root=/dev/sda2 you could use in the case you have got gpt this:
    Code:
    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 View Post
    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.
    Code:
    sudo cp /boot/initrd.img-$(uname -r) /boot/efi/EFI/ubuntu/initrd.img
    sudo efibootmgr -c -d /dev/sda -p 1 -l '\EFI\ubuntu\linux.efi' -L 'Ubuntu direct with initrd' -u 'quiet root=/dev/sda2 initrd=EFI\ubuntu\initrd.img'
    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
    Code:
    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?

    Leave a comment:


  • Kano
    replied
    Well you can reuse the ubuntu shim/grub for all purpose Because it allows boot of unsigned kernels. Basically they use both shim to chainload to grub. shim can be configured to allow only a signed binary (when you build it plain it is just a chainloader). Fedora wants to use signed kernels, somewhere are kernel patches to do that, maybe you find the link. With one working shim/grub combination you can boot every system - well it depends how many features ubuntu allows in the signed grub, if chainloader is possible you can start any other efi binary (signed or not) - and even win.
    Last edited by Kano; 22 September 2012, 01:17 PM.

    Leave a comment:


  • uid313
    replied
    Fedora approach

    How does Ubuntu's SecureBoot approach now differ from that of Fedora?

    Leave a comment:


  • Kano
    replied
    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.
    Code:
    sudo cp /boot/initrd.img-$(uname -r) /boot/efi/EFI/ubuntu/initrd.img
    sudo efibootmgr -c -d /dev/sda -p 1 -l '\EFI\ubuntu\linux.efi' -L 'Ubuntu direct with initrd' -u 'quiet root=/dev/sda2 initrd=EFI\ubuntu\initrd.img'
    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
    Code:
    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!

    Leave a comment:


  • unknown2
    replied
    Originally posted by Kano View Post
    That's pretty simple (lets think you use /dev/sda1 for /boot/efi - basically i would not even need -d/p in that case and /dev/sda2 for /), try this
    Code:
    sudo cp /boot/vmlinuz-$(uname -r) /boot/efi/EFI/ubuntu/linux.efi
    sudo efibootmgr -c -d /dev/sda -p 1 -l '\EFI\ubuntu\linux.efi' -L 'Ubuntu direct' -u 'quiet root=/dev/sda2'
    instead of root=/dev/sda2 you could use in the case you have got gpt this:
    Code:
    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.
    actually it is not that simple, because initrd may be required.

    my kernel is now a standalone efi bootable which can boot any linux partitions in my PC by:
    1. do not allow module, compile all function builtin
    2. embed initramfs
    3. embed video firmware blob

    Leave a comment:


  • Kano
    replied
    That's pretty simple (lets think you use /dev/sda1 for /boot/efi - basically i would not even need -d/p in that case and /dev/sda2 for /), try this
    Code:
    sudo cp /boot/vmlinuz-$(uname -r) /boot/efi/EFI/ubuntu/linux.efi
    sudo efibootmgr -c -d /dev/sda -p 1 -l '\EFI\ubuntu\linux.efi' -L 'Ubuntu direct' -u 'quiet root=/dev/sda2'
    instead of root=/dev/sda2 you could use in the case you have got gpt this:
    Code:
    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.

    Leave a comment:


  • steveriley
    replied
    Originally posted by 89c51 View Post
    You can still multiboot if your motherboard allows you to have a boot menu (probably does). You just create more entries to it.
    Yeah, both my ThinkPads have a crappy boot manager menu, which basically just lists whatever it sees in Bootnnnn NVRAM variables. Right now, my one-and-only entry, called "ubuntu," points to \EFI\ubuntu\grubx64.efi. EFI boot appears to allow me to skip the irrelevant GRUB stuff and directly boot-load the kernel. Just need to spend a couple hours learning how to stitch it all together.

    Leave a comment:


  • 89c51
    replied
    Originally posted by steveriley View Post
    So it's baked into Ubuntu kernels now? Must investigate. Since I don't multiboot, I'd love to purge GRUB completely.
    You can still multiboot if your motherboard allows you to have a boot menu (probably does). You just create more entries to it.

    Leave a comment:

Working...
X