On 2017-07-21 14:00, Andreas Reichel wrote: > On Thu, Jul 20, 2017 at 08:05:31PM +0200, Jan Kiszka wrote: >> On 2017-07-12 14:38, [ext] Reichel Andreas wrote: >>> Update and rework documentation for better user support. >>> >> >>> +# umount /mnt >>> +# mount /dev/sdX3 /mnt && cd /mnt >>> +# echo -n "KERNEL2" | iconv -f ascii -t UTF-16LE > EFILABEL >>> +# bg_setenv -f -r 2 --kernelfile "C:KERNEL2:vmlinuz-linux" >>> --kernelparams="root=/dev/sdX5 noinitrd" >>> +# umount /mnt >> >> It's probably better to pull the setup of the second environment after >> booting into the first one. Having both created initially makes no sense >> in practice. >> > > If efibootguard is compiled for dual-FAT config, then it expects two > config partitions. This is the default. It tries to boot with one, but > then it warns about one being corrupted. To prevent this warning, both > are initialized, which is a clean starting point. Efibootguard has no > way of seeing if this is just the very first initial setup or if it is > executed after a hard disk failure were one partition is gone. It also > does not know if the only config existing is correct, so just cloning > the only thing that is there is based on an unneeded assumption.
OK, I see. That makes me wonder about the following error scenario: After running fine, maybe rebooting a couple of times, the latest partition suddenly becomes corrupt. Can/should the previous version then act as backup? Can we detect this case of "late downgrade"? Should we, after successfully updating and booting a new version also update the second partition to the same content, just leaving its partition revision old? I'm concern of a silent fall-back to an old, potentially vulnerable version of the system otherwise. > >>> +The following command create an entry for `bootx64.efi`: >>> + >>> +``` >>> +bcfg boot add 0 fs0:\efi\boot\bootx64.efi "efi boot guard" >> >> In fact, that should never be needed for any non-broken BIOS. At most, >> you would have to remove any existing settings and let the BIOS fall >> back to that. I would not highlight the exceptional case here. >> > > Not true. Maybe you have two harddisks and want to boot from fs0 instead > from fs1. Or you want to boot fs0: before network boot... I would say it > is not about the firmware being broken or not... it is about the NVRAM > settings the user may have. That's what I meant with "existing settings" - of course, if you don't have a new system, you may have to remove existing settings. And, true, if you have a system with multiple bootable media attached, you may need to set this particular one. But the latter is an exception. The idea is to make this section for the common case as simple as possible - if that is possible, of course. Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "EFI Boot Guard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/78c47d4b-fb42-11f2-68c3-b0f04d7ef94f%40siemens.com. For more options, visit https://groups.google.com/d/optout.
