|
doesn't systemd mount the EFI variables as read-write by default, so it's possible to literally brick your hardware by accidentally deleting the directory they're mounted under? edit: apparently somebody already brought this up. "well, in this one case that doesn't happen very often, systemd will need to write to them so they're mounted read-write by default at all times for everybody. if this ruins your computer then you should buy another less lovely one anyway and git gud." Doc Block fucked around with this message at 09:53 on Jun 2, 2017 |
#
¿
Jun 2, 2017 09:50
|
|
|
|
| # ¿ May 15, 2024 01:54 |
|
|
Tankakern posted:again, i think this is already fixed by making important efivarfs entries immutable. but i'm just a lowly whitenoise poster, no noone notices what i write anyway! yeah, but the systemd dude just sticking his fingers in his ears saying "nah nah nah not my problem not listening nah nah nah" instead of just changing the default efivarfs mount to read-only (which it should be anyway IMHO) was pretty  and unhelpful.
|
|
#
¿
Jun 2, 2017 20:58
|
|
|
Tankakern posted:
it should be mounted read-only by default, then for the few times something needs to be changed it should be remounted as read-write, then remounted back to read-only when done. that's in addition to having some EFI vars being made immutable by the kernel. whole lotta autists ITT
|
|
#
¿
Jun 3, 2017 17:39
|
|
|
"Hmm, yes, EFI vars should always be writeable because maybe systemd needs to change the boot volume every once in a blue moon." edit: and yes, I know some are made immutable by the kernel, but even the EFI vars that won't brick the system if changed shouldn't be writeable without going through some hoops first to prevent accidents. Doc Block fucked around with this message at 19:36 on Jun 3, 2017 |
|
#
¿
Jun 3, 2017 19:32
|
|
|
Shinku ABOOKEN posted:why is there an expectation that a system will still be bootable after rimming the whole disk??? the issue isn't that you could erase the disk, since you can always just reinstall the OS. the issue was that efivarfs maps EFI variables to the filesystem, and by deleting it you'd be deleting EFI system configuration data, and on systems with lovely UEFI implementations (LOL Samsung) you could make the computer itself unbootable (so that it wouldn't POST). the kernel was fixed to disallow changing certain EFI data that could lead to the computer itself being rendered unbootable, but systemd still mounts efivarfs as read-write by default. while you can't brick the computer anymore, you can still mess with other EFI stuff by accident. all so that stuff like changing the boot volume can be done without having to remount efivarfs.
|
|
#
¿
Jun 4, 2017 00:26
|
|
|
qhat posted:Rofl. Someone calling someone a stupid oval office isn't a meltdown retard. u mad bro? gendered insult + disability insult, sounds like a meltdown to me Doc Block fucked around with this message at 02:52 on Jun 4, 2017 |
|
#
¿
Jun 4, 2017 02:49
|
|
|
Helianthus Annuus posted:could have easily avoided the prob by saying "im a bsd admin wait, are you telling me that freebieSD doesn't have systemd? brb
|
|
#
¿
Jun 29, 2017 22:54
|
|
" somewhere in this post
|
and now for the lennart poettering post about how it's working as expected and is actually a fault in the [kernel|user|stars].
|
|
#
¿
Jul 2, 2017 07:22
|
|
|
carry on then posted:this is art lmao that in poettering's mind having differing behaviors for "invalid username" and "valid, but nonexistant" is is just  , and that one of those behaviors should be "well gently caress it, just run as root" is just
|
|
#
¿
Jul 2, 2017 22:37
|
|
|
for a clown to use
|
|
#
¿
Jul 4, 2017 05:57
|
|
|
genesis does what systemdon't
|
|
#
¿
Jul 12, 2017 01:09
|
|
|
yeah, as in "you're a dope for using it."
|
|
#
¿
Jul 12, 2017 01:16
|
|
|
lookit this fukken dope
|
|
#
¿
Jul 12, 2017 02:48
|
|
|
|
| # ¿ May 15, 2024 01:54 |
|
|
Tankakern posted:dont get why people continue slamming poettering for closing that """0day""" bug, the behaviour seems completely reasonable "hey, this persion [accidentally | intentionally] put in an invalid username. should we not run that task and raise an error? nope, let's just run it as root!" isn't reasonable behavior.
|
|
#
¿
Jul 12, 2017 16:14
|
|