> (note that you can remount it readonly at boot, simply by adding an entry for it into /etc/fstab, that is marked "ro") He's suggesting that not mounting it as read-only by default will break a few things like grub-install, but promptly suggested editing /etc/fstab to mount it read-only by default. So... his own solution to the problem is to mount it as read-only. The hard drive analogy is ridiculous because while y…
In linux, there is the immutable file attribute which won't let root rm the file without first changing it with chattr.
The comments by Lennart Poettering, IMO, are a prime example of the schism between what is needed for reaching "the year of Linux on the desktop" and what some hackers think is best. Nobody sells a chainsaw with safeties disabled, remarking "you can always attach the chain catcher" if people report a couple of accidents, but Lennart thinks requiring almost every user to change the default install ( (note that you can…
If you mount efivarsfs read-only, efibootmgr can't make your system bootable. So at a minimum, you can't just remount the filesystem read-only; you need distribution integration so efibootmgr can still write to it.
There's no point in mounting efivarsfs read-only; you might as well not mount it at all.
Unless you're doing something super screwy, GRUB, the excuse for this backwards default, doesn't even need access to UEFI. UEFI booting looks for a file in a FAT-formatted partition of a hard disk with a specific ID -- C12A7328-F81F-11D2-BA4B-00A0C93EC93B for GPT disks and 0xEF for MBR disks. All EFI does is to look for a file BOOTX64.EFI on that partition. There's no need to muck around the UEFI settings for this, i…
Only removable disks use bootx64.efi, though some (but not all) BIOSes will look for that on fixed disks too. efibootmgr needs access to efivarsfs to configure an EFI boot entry for Linux on a fixed disk. Relying exclusively on bootx64.efi on the EFI system partition will break on some devices, and will overwrite the Windows bootloader (and conversely, Windows doing so will render Linux unbootable).
The standard is for EFI to look for that partition on all disks, even hard disks. If there are a few broken systems that do otherwise, they could use other methods, but keeping things mostly standardized seems like the best way to go. It's how Windows does it, it's how FreeBSD does it, it's how OpenBSD does it, etc. Mucking around with it doing otherwise is just asking for problems.
Only removable disks use bootx64.efi, though some (but not all) BIOSes will look for that on fixed disks too. efibootmgr needs access to efivarsfs to configure an EFI boot entry for Linux on a fixed disk. Relying exclusively on bootx64.efi on the EFI system partition will break on some devices, and will overwrite the Windows bootloader (and conversely, Windows doing so will render Linux unbootable).
The standard is for EFI to look for that partition on all disks, even hard disks. If there are a few broken systems that do otherwise, they could use other methods, but keeping things mostly standardized seems like the best way to go. It's how Windows does it, it's how FreeBSD does it, it's how OpenBSD does it, etc. Mucking around with it doing otherwise is just asking for problems.
The EFI standard specifically limits that to removable media. Windows installs itself via the EFI boot variable mechanism; Windows also installs itself to bootx64.efi, but even if you overwrite that, you can still boot Windows via its EFI boot entry. Having Linux systems install themselves only to bootx64.efi would produce a fragile installation (particularly in dual-boot configurations).
Why not just turn off recognition of "rm" in the efivarfs? That is, the response to "unlink" of a file that represents a system abstraction of firmware should be something drastic only to the unlinker. SIGSEGV or something. "Go away, don't do that."
The comments by Lennart Poettering, IMO, are a prime example of the schism between what is needed for reaching "the year of Linux on the desktop" and what some hackers think is best. Nobody sells a chainsaw with safeties disabled, remarking "you can always attach the chain catcher" if people report a couple of accidents, but Lennart thinks requiring almost every user to change the default install ( (note that you can…
I think the "Year of Linux on the desktop" thing is BS and needs to stop. It's been the year of Linux on the desktop for 15 years now. Can't GNU/Linux just be a solid server platform? Not trying to be a troll, but if someone says "the year of Linux on the desktop" one more time...
Linux is important on dekstops to thrive. I've successfully transitioned my parents to Linux. What I got? Deser maintainance, more reliability, everything just works for them.
And of course, sticking to proprietary solutions in a long run would be rather a sick idea.
I think the "Year of Linux on the desktop" thing is BS and needs to stop. It's been the year of Linux on the desktop for 15 years now. Can't GNU/Linux just be a solid server platform? Not trying to be a troll, but if someone says "the year of Linux on the desktop" one more time...
Linux is important on dekstops to thrive. I've successfully transitioned my parents to Linux. What I got? Deser maintainance, more reliability, everything just works for them. And of course, sticking to proprietary solutions in a long run would be rather a sick idea.
Linux derivatives rule the mobile space spo in essence it won really big. The desktop is not that impoortant. And so many of its paradigms are quite dated compared to the mobile experience.
I can't understand why people argue about this. Just put some safety measures on it already. Or at least change the rm option to "--brick-my-motherboard"