[systemd-devel] UEFI + SystemD EpicneSS

[Ryan Gonzalez]

This is basically a GRUB issue and has absolutely nothing to do with
systemd. Sometimes GRUB can be a little finnicky with the modules it loads
by default, and IME in can be really odd on UEFI systems.

In general, if you can, you should look into using a proper UEFI
bootloader, like rEFInd (which handles all this automatically, and also
allows booting to other EFI files) or systemd-boot (ditto).

UEFI's advantage isn't necessarily that it's universal, nor the 2TB
restriction (which is actually GPT, not UEFI, that fixes that). In fact,
the current technologies are essentially unextendable. (FWIW GPT is
actually backwards compatible with MBR, so it's *sort of* an extension.)

Traditional BIOS + MBR systems boot like this-

- The BIOS reads the first sector of the hard drive and runs it as the
bootloader.
- Since no decent bootloader fits in one sector, the bootloader has to
locate the rest of its data on the main disk and load it.

Here's what can go wrong:

- Bootloaders will war over which one gets to be on the first sector. This
is why Windows would sometimes update and remove GRUB: every time it had to
change the bootloader code, it had no idea that GRUB was actually in that
sector.
- If you move the partition containing GRUB, your system will fail to boot.

With UEFI, the bootloaders are compiled to .efi files and stored on an EFI
system partition (yes, there can be more than one!). This means that
Windows just updates its own efi file, and GRUB updates its own. The UEFI
firmware manages the boot order of these files, so if a war still happens,
you can pretty easily solve it.

In addition, this makes it far easier to debug issues related to boot.

It just kind of sucks that GRUB never really caught up...

On Wed, Aug 8, 2018, 4:17 AM <axo at tango.lu> wrote:

>
> And another big FUCK you for this 2 piece of garbage technologies.
>
> I just fucked up an entire night migrating a Cenots (congrats on using
> shitd) to another server.
>
> Good old hotclone rsync method with skipping libs and boot partition but
> after the migration guess what the new server fails to start due to our
> wonderful EFI -nobody needed some aholes still made it- technology ah
> sorry uEFI because it's such an Universal fucking piece of shit.
>
> so journalctl -xb or whatever that recommended me to look at logs
> containing nothing useful whatsoever.
>
> Finally I found out that the vfat kernel modul was not loaded on the
> target system:
>
> Grub2 issues: vfat unknown filesystem
>
> So I had to do
>
> dracut --regenerate-all --force
> grub2-install --target=x86_64-efi --bootloader-id=centos
> --efi-directory=/boot/efi --recheck --verbose /dev/sda
>
> and voila it started working. Another crystal clear example of merging
> together 2 headless beasts systemd+uefi.
>
> Nobody ever asked for these shits especially not veteran uNIX admins.
> VFAT filesystem with conjunction of nix systems give me a fucking break
> ?!
>
> Who cares that the bios cannot boot over 2TB or whatever uefi was
> intended to solve, the solution is not to write something from scratch
> but extend current existing technologies in a modular way.
>
> ! RC scripts + BIOS 4 ever !
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
-- 

Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20180808/94842211/attachment.html>