:: Re: [DNG] Bad UEFI: was Systemd at …
Etusivu
Poista viesti
Vastaa
Lähettäjä: Rainer Weikusat
Päiväys:  
Vastaanottaja: dng\@lists.dyne.org
Aihe: Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
KatolaZ <katolaz@???> writes:
> On Thu, Feb 04, 2016 at 10:02:51PM +0000, Simon Hobson wrote:
>> Arnt Karlsen <arnt@???> wrote:
>>
>> > ..me, I do not see any point in keeping it mounted at all.
>> > Whenever such a need arises, it should be mounted read-only.
>> > If a need to write to /sys/firmware/efi/efivars should happen,
>> > the machine should first be taken off-line, backed-up etc out
>> > of production and into a maintenance mode, where mounting
>> > /sys/firmware/efi/efivars read-write, _may_ be warranted.
>>
>>
>> Yes, in an ideal world where everyone is a "full time admin". But in
>> the real world, more systems are used by "average users" who just
>> expect "stuff to work". So IMO, you either build stuff that works (or
>> at least is up-front about what's wrong), or you leave these people
>> stuck with "stuff that's broken" and regardless of how right you are,
>> the pi**ed off user will be moaning about how "rubbish and
>> complicated this Linux is - best go back to Windows".
>>
>
> I don't get why any of those occasional "sysadmin-wannabe" users you
> have described above would ever need to mess around with their UEFI by
> hand. If you need to do that, you should first *know* what you are
> doing.


It's not really that simple: This really an interesting multi-level
fuck-up.

    - the systemd people shouldn't just mount the efivarfs r/w
          because that's convenient for them and tell people to get lost
          if they think otherwise


    - someone who runs rm -rf on a group of mounted filesystems
          should understand that whatever was affected by that didn't
          chose to unlink itself


    - the people who implemented the firmware shouldn't have
          implemented that such that it ceases to work if userspace
          software performs perfectly legitimate operations such as
          deleting unprotected variables


    [- the issue shouldn't be generalized until the answer becomes
       42 ]