** Description changed: [Impact] * Currently one needs grub-$platform-bin and grub-$platform-signed packages installed together. As first one provides modules, and the later one provides signed .efi images. The two are built from different source packages, and there is a delay of manual reviews before matching signed grub appears. - * The proposal is to rename modules in -bin to be shipped in the + * The proposal is to rename modules in -bin to be shipped in the $platfrom-unsigned directly. - * And make -signed package ship both modules and signed binaries + * And make -signed-bin package ship modules - * And add dependency from the -bin onto > -signed one, such that grub - uses whichever modules match the signed images. + * And add dependency from the -bin onto > -signed-bin one - * This allows allows in the future for grub2-signed to pull appropriate + * This allows allows in the future for grub2-signed to pull appropriate grub modules for a given distro. For example, using 2.04 modules & signed images from focal on bionic to gain support for TPM verifies and other EFI platform specific developments without affecting userspace grub tooling. + [Caveats] + + * If one chooses to remove or not install grub-efi-*-signed package, + then modules keep receiving updates, but no SRUs of grub-efi-amd64/grub- + efi-arm64 getting published meaning nothing is upgraded that has a + maintainer script to trigger grub-install. This is closer inline with + grub-pc which also stopped calling grub-install in the release series. + But I feel iffy about this. + + but i'm not sure if it is ok to add circular dependency from grub- + efi-*-bin back onto grub-efi-amd64/grub-efi-amd64/signed/grub-pc. + + almost as if the top level packages should simply have a file trigger on + modules directory to trigger upgrade logic to execute grub-install. + + also feel iffy about the fact that -signed ships efi apps; -signed-bin + ships modules; and -signed-dbg ships debug ones. collapsing them all + into one will break the multiarch-foreign constraint on the unsigned + -bin packages. + + I guess question remains if i should add file-triggers in the grub-pc & + grub-efi-arm64|amd64-signed packages. + [Test Case] * Upgrade to new grub-efi-amd64-bin and grub-efi-amd64-signed packages - * Observe that system boots, one can use grub-mkimage / grub-mkrescue + * Observe that system boots, one can use grub-mkimage / grub-mkrescue without issues. [Where problems could occur] * The binaries shipped by -signed packages are innert, they are bootloader binaries only. The only compatibility that has to be maintained is within the userspace tooling - specifically maintainer scripts, and file names and locations. [Other Info] * See all the bug reports that grub can't be installed or upgraded when people use -proposed.
** Description changed: [Impact] * Currently one needs grub-$platform-bin and grub-$platform-signed packages installed together. As first one provides modules, and the later one provides signed .efi images. The two are built from different source packages, and there is a delay of manual reviews before matching signed grub appears. * The proposal is to rename modules in -bin to be shipped in the $platfrom-unsigned directly. * And make -signed-bin package ship modules * And add dependency from the -bin onto > -signed-bin one * This allows allows in the future for grub2-signed to pull appropriate grub modules for a given distro. For example, using 2.04 modules & signed images from focal on bionic to gain support for TPM verifies and other EFI platform specific developments without affecting userspace grub tooling. [Caveats] * If one chooses to remove or not install grub-efi-*-signed package, then modules keep receiving updates, but no SRUs of grub-efi-amd64/grub- efi-arm64 getting published meaning nothing is upgraded that has a maintainer script to trigger grub-install. This is closer inline with grub-pc which also stopped calling grub-install in the release series. But I feel iffy about this. but i'm not sure if it is ok to add circular dependency from grub- efi-*-bin back onto grub-efi-amd64/grub-efi-amd64/signed/grub-pc. almost as if the top level packages should simply have a file trigger on modules directory to trigger upgrade logic to execute grub-install. also feel iffy about the fact that -signed ships efi apps; -signed-bin ships modules; and -signed-dbg ships debug ones. collapsing them all into one will break the multiarch-foreign constraint on the unsigned -bin packages. I guess question remains if i should add file-triggers in the grub-pc & grub-efi-arm64|amd64-signed packages. + The advantage of file-trigger would be that grub-efi-*-signed packages + no longer need to ship any maitaniner scripts, and can be multiarch + foreign providing modules & efi apps (and dbg modules separate). + [Test Case] * Upgrade to new grub-efi-amd64-bin and grub-efi-amd64-signed packages * Observe that system boots, one can use grub-mkimage / grub-mkrescue without issues. [Where problems could occur] * The binaries shipped by -signed packages are innert, they are bootloader binaries only. The only compatibility that has to be maintained is within the userspace tooling - specifically maintainer scripts, and file names and locations. [Other Info] * See all the bug reports that grub can't be installed or upgraded when people use -proposed. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1915536 Title: one grub To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1915536/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
