Discussion:
[systemd-devel] UEFI + SystemD EpicneSS
a***@tango.lu
2018-08-08 09:07:07 UTC
Permalink
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 !
Ryan Gonzalez
2018-08-08 13:23:29 UTC
Permalink
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...
Post by a***@tango.lu
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
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
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Ryan (ラむアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/
Lennart Poettering
2018-08-08 14:35:29 UTC
Permalink
On Mi, 08.08.18 08:23, Ryan Gonzalez (***@gmail.com) wrote:

Please don't feed the trolls. The original poster clearly was just out
to complain and insult, and we shouldn't engage with that. In future,
when someone posts with contents like this please just ignore it, and
move on.

Never wrestle with a pig. You get dirty, and besides, the pig likes
it.

Lennart
--
Lennart Poettering, Red Hat
Loading...