** 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. + $platfrom-unsigned directory. * And make -signed-bin package ship modules - * And add dependency from the -bin onto > -signed-bin one + * And add dependency from the -bin onto > -signed-bin (>= $grub2-signed + stem) * 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. + * In devel series, keep grub2 submitting things for signing SB_SUBMIT := + yes - 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. + * With every new upload bump the version number of the -signed-bin (>= + $grub2-signed-ver) package, to the expected one from grub2-signed. - almost as if the top level packages should simply have a file trigger on - modules directory to trigger upgrade logic to execute grub-install. + * Upload new grub2-signed, vendoring the desired signed grub2 - 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. + In stable series, disable submitting signing SB_SUBMIT := no - 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). + Upload grub2 to bump the version number of the -signed-bin (>= $grub2 + -signed-ver) dependency, to the expected one from grub2-signed. + + Upload new grub2-signed pulling whichever signed grub from whichever + series as needed. + [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
