Re: [PATCH v8 10/18] cryptodisk: Add macro GRUB_TYPE_BITS() to replace some literals
On Tue, Dec 08, 2020 at 04:45:41PM -0600, Glenn Washburn wrote: > The new macro GRUB_TYPE_BITS(type) returns the number of bits allocated for > type. > > Signed-off-by: Glenn Washburn Reviewed-by: Daniel Kiper Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v8 09/18] luks2: Add string "index" to user strings using a json index.
On Tue, Dec 08, 2020 at 04:45:40PM -0600, Glenn Washburn wrote: > This allows error messages to be more easily distinguishable between indexes > and slot keys. The former include the string "index" in the error/debug > string, and the later are surrounded in quotes. > > Signed-off-by: Glenn Washburn Reviewed-by: Daniel Kiper Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v8 08/18] luks2: Rename json index variables to names that they are obviously json indexes
On Tue, Dec 08, 2020 at 04:45:39PM -0600, Glenn Washburn wrote: > Signed-off-by: Glenn Washburn Reviewed-by: Daniel Kiper Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v8 07/18] luks2: Use more intuitive object name instead of json index in user messages
On Tue, Dec 08, 2020 at 04:45:38PM -0600, Glenn Washburn wrote: > Use the object name in the json array rather than the 0 based index in the > json array for keyslots, segments, and digests. This is less confusing for > the end user. For example, say you have a LUKS2 device with a key in slot 1 > and slot 4. When using the password for slot 4 to unlock the device, the > messages using the index of the keyslot will mention keyslot 1 (its a > zero-based index). Furthermore, with this change the keyslot number will > align with the number used to reference the keyslot when using the > --key-slot argument to cryptsetup. > > Signed-off-by: Glenn Washburn Reviewed-by: Daniel Kiper Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v8 06/18] luks2: Add idx member to struct grub_luks2_keyslot/segment/digest
On Tue, Dec 08, 2020 at 04:45:37PM -0600, Glenn Washburn wrote: > This allows code using these structs to know the named key associated with > these json data structures. In the future we can use these to provide better > error messages to the user. > > Get rid of idx local variable in luks2_get_keyslot() which was overloaded to > be used for both keyslot and segment slot keys. > > Signed-off-by: Glenn Washburn Reviewed-by: Daniel Kiper Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v8 01/18] disk: Rename grub_disk_get_size to grub_disk_native_sectors
On Tue, Dec 08, 2020 at 04:45:32PM -0600, Glenn Washburn wrote: > The function grub_disk_get_size is confusingly named because it actually > returns a sector count where the sectors are sized in the grub native sector > size. Rename to something more appropriate. > > Signed-off-by: Glenn Washburn > Suggested-by: Daniel Kiper > Reviewed-by: Daniel Kiper > Reviewed-by: Patrick Steinhardt The proper order is: Suggested-by: Daniel Kiper Signed-off-by: Glenn Washburn Reviewed-by: Patrick Steinhardt Reviewed-by: Daniel Kiper First I suggested the patch, you wrote it, Patrick reviewed the patch and finally I did it. I will fix it before committing. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Mips-arc tests ever work?
On Wed, 9 Dec 2020 10:46:45 +0100 "Vladimir 'phcoder' Serbinenko" wrote: > I have added -M indy in my own branch but never released it So I understand correctly, you have a -M indy in your branch of Qemu? If so, is that what we should be using to get the mips-arc target? Or what do you recommend for getting the mips-arc tests working with Qemu? > сб, 5 дек. 2020 г., 13:34 Glenn Washburn > : > > > Hi, > > > > I'm looking into getting grub qemu testing working for the "mis-arc" > > target. Is anyone running these tests successfully? In grub-shell > > that target passed the -M indy arguments to qemu. > > qemu-system-mips64 is saying that that is an invalid machine type. > > The available machine types are magnum, malta, mips, mipssim, none, > > and pica61. The indy machine type appears to not be available > > since at least qemu 2.5, perhaps it was dropped some time ago? > > According to wikipedia the SGI Indy originally used R4k processors. > > So would machine type mips be the one to use since its description > > says "mips r4k platform"? But then why wouldn't it already use > > that machine type like the target "mips-qemu_mips"? > > > > So can anyone familiar with this tell me an appropriate machine > > type of the above listed to use instead of indy? Perhaps Vladimir > > who committed that code can chime in? > > > > Thanks, > > Glenn > > > > ___ > > Grub-devel mailing list > > Grub-devel@gnu.org > > https://lists.gnu.org/mailman/listinfo/grub-devel > > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[ANNOUNCEMENT] Together We Sink or Swim: Plugging the BootHole
Hi, I would like to invite you to the "Together We Sink or Swim: Plugging the BootHole" presentation which will be done under Ubuntu Masters umbrella, this Thursday, 10th of December, at 18:00 UTC. More information you can find here: https://www.brighttalk.com/webcast/6793/453235 Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCHv2] grub-install: Add backup and restore
Hi, On Wed, 9 Dec 2020 at 05:15, Michael Chang wrote: > > On Tue, Dec 08, 2020 at 05:58:40AM +, Dimitri John Ledkov wrote: > > On Tue, 8 Dec 2020, 03:17 Michael Chang, wrote: > > > > > On Mon, Dec 07, 2020 at 12:37:28PM +, Dimitri John Ledkov wrote: > > > > Refactor clean_grub_dir to create a backup of all the files, instead > > > > of just irrevocably removing them as the first action. If available, > > > > register on_exit handle to restore the backup if any errors occur, or > > > > remove the backup if everything was successful. If on_exit is not > > > > available, the backup remains on disk for manual recovery. > > > > > > > > This allows safer upgrades of MBR & modules, such that > > > > modules/images/fonts/translations are consistent with MBR in case of > > > > errors. For example accidental grub-install /dev/non-existent-disk > > > > currently clobbers and upgrades modules in /boot/grub, despite not > > > > actually updating any MBR. This increases peak disk-usage slightly, by > > > > requiring temporarily twice the disk space to complete grub-install. > > > > > > I'd love to have the described problem fixed too, as it helps a lot in > > > the update path to survive grub-install error which can be contributed > > > by many different reasons, even though grub has to stay with old version > > > but still much better than unbootable system. > > > > > > But here I have a concern, as to what will happen if the error comes > > > after image installation ? For example, the efibootmgr may fail to > > > register boot entry after copying the images to efi partition. It looks > > > to me that the restoring backup would be triggerd incorrectly for the > > > new image to load restored old backups. > > > > > > Would you please help to clarify that ? > > > > > > > > > On Ubuntu we install secureboot signed prebuilt EFI images only which > > prohibit module loading. Hence usually it is irrelevant if the EFI grub > > modules are old or new. > > > > And we do not call efibootmgr at all, as it does excessive writes to > > efivars. Instead we don't even try to update efivars if there is no need. > > It was submitted to this mailing list but I am not sure on the acceptance > > status https://lists.gnu.org/archive/html/grub-devel/2019-03/msg00123.html > > > > Above two things make EFI updates less fatal, as it is harder for a > > prebuilt signed grub, which does not use modules, to fail booting. Unlike > > i386-pc case. > > My concern is exactly that these are not upstreamed yet so accepting the > patch would be premature. Either it has to be adapted to satisfy the > expected behavior of existing codebase or wait until those dependent > patches gets merged. > this patch does not depend on efivars patch behaviour, and is useful with either efibootmgr or efivars codepath. If either way to update EFI vars fails, rollback is performed. > Besides, other architecture like openfirmware would update nvram in a > similar fashion to uefi but cannot be covered by the aforementioned > efivars enhacement patch. > If nvram update of openfirmware fails, modules which are copied over first must too be rolled backed. In case of failures there is no way to know for sure which state to take, but it is safer to revert. > > > > And to answer your immediate question - the new EFI image will be used for > > boot without rolling back. > > > > Also, I am not sure how everyone installs signed grubs. Thus adding support > > for ESP backup and restore might be futile upstream. As far as I can tell > > it is safe to call grub-install on Ubuntu, whereas it might not be on other > > distros. As Ubuntu preserves / reinstalls signed grub EFI images, instead > > of generating a new random one and putting it on ESP thus causing failure > > to boot with secureboot due to effectively replacing signed grub with an > > unsigned one. And for resilient boot we have support for maintaining and > > synchronising multiple ESP for Linux raid. > > Installing signed grub can happen in parallel with any unsigned one > installed by grub-install as long as they didn't overlap in the position > on EFI System partition. For that matters the efibootmgr is used to > manage them. > > The signed grub is so far not controlled by grub-install, so should be > disregared at this moment. The entire backup/recovery should be done > only for those made aware by grub-install. > This patch so far only manages things that are done grub-install, precisely as you desire. > > > > I kind of wish we'd prebuilt more core images at package build time and > > simply copy them around. Not just the ones that have signing. Instead of > > invoking mkimage on every installed system. > > > > Nonetheless, it should be possible to hook up more files and directories to > > perform backup, cleanup and restore on. Is there is a desire. The function > > calls simply need to be added in the appropriate places. > > IMHO the hook should be unregistered right after the state is considered >
Re: Mips-arc tests ever work?
I have added -M indy in my own branch but never released it сб, 5 дек. 2020 г., 13:34 Glenn Washburn : > Hi, > > I'm looking into getting grub qemu testing working for the "mis-arc" > target. Is anyone running these tests successfully? In grub-shell that > target passed the -M indy arguments to qemu. qemu-system-mips64 is > saying that that is an invalid machine type. The available machine > types are magnum, malta, mips, mipssim, none, and pica61. The indy > machine type appears to not be available since at least qemu 2.5, > perhaps it was dropped some time ago? According to wikipedia the SGI > Indy originally used R4k processors. So would machine type mips be the > one to use since its description says "mips r4k platform"? But then > why wouldn't it already use that machine type like the target > "mips-qemu_mips"? > > So can anyone familiar with this tell me an appropriate machine type of > the above listed to use instead of indy? Perhaps Vladimir who > committed that code can chime in? > > Thanks, > Glenn > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
