spoiler

made you look

  • 0 Posts
  • 24 Comments
Joined 2 years ago
cake
Cake day: July 27th, 2024

help-circle



  • A lot of this is also a post-hoc justification, UNIX didn’t get shared libraries until some point in the 80s (Can’t find an exact year), so before that your options were to either statically compile the needed functionality into your program or keep it as an entirely separate program and call out to that.

    It’s a perfect mix, in a time where enterprise storage was measured in single digit megabytes, and the only efficient way to created shared functionality was via separate programs, and you’ve got an OS that happens to have “easily pass data between programs” as a core paradigm.

    And now people invoke it to attack an init program for also monitoring the programs it starts and not just spawning them.









  • And the reason you’ll want to do this is that it exposes FS mounts in the service dependency tree, so e.g. you can delay starting PostgreSQL until after you’ve mounted the network share that it’s using as a backing store, while letting unrelated tasks start concurrently.

    If all you want to do is pass some special mount flags (e.g. x-systemd.automount) then fstab is the way, after all it’s still systemd that’s parsing and managing it.






  • I’d double check, if you haven’t picked an option specifically it might just default to the fallback (i.e. BOOTX64) It’ll be under the boot device order section.

    (Not my picture, stole it from Reddit)

    Here it’s listing all the possible boot options this mobo can find, but there’s a generic “UEFI OS” option which I’d bet is the fallback. And once a choice is made it’s kept unless something resets it, so if it just happened to be set to the fallback once it’ll stick with that until a change is forced.


  • When installing windows while there is a Linux install, windows will see the EFI partition already there and just decides to share it, and doesn’t create its own.

    That’s what it’s supposed to do, it’s a plain FAT32 partition, the bootloaders are just files you put in there.

    Part of the issue is that while a well-made motherboard will look for all bootloaders on the partition and present them as options in the firmware UI, bad ones will only look for a specific file (\EFI\BOOT\BOOTX64.EFI) and use that. For an OS to have a chance of booting on those boards it has to overwrite that file, blowing away whatever other bootloader was there before.

    It’s annoying, since Windows is mostly well behaved here (It puts the main copy of the bootloader at \EFI\Microsoft\Boot\bootmgfw.efi and Linux bootloaders can see that and offer it, the reverse isn’t true) and can co-exist with Linux well (Well…), but manufacturers cutting corners causes more problems for everybody.