On Wed, Jun 07, 2023 at 03:39:24PM +0200, Daniel Kiper wrote: > On Tue, Jun 06, 2023 at 11:02:31AM -0700, Kees Cook wrote: > > On Tue, Jun 6, 2023 at 10:27 AM Julian Andres Klode > > <julian.kl...@canonical.com> wrote: > > > > > > On Tue, Jun 06, 2023 at 07:09:26PM +0200, Daniel Kiper wrote: > > > > On Tue, Jun 06, 2023 at 06:15:27PM +0200, Julian Andres Klode wrote: > > > > > On Tue, Jun 06, 2023 at 06:10:21PM +0200, Julian Andres Klode wrote: > > > > [...] > > > > This patch is in upstream as commit c39f27cd6 (osdep/linux: Fix md array > > > > device enumeration). > > > > Oh good. I really thought it had landed already, so thanks for > > checking. I got worried this morning when I saw the email to > > grub-devel. :P "Wasn't that fixed already?" :) But thank you for > > making sure it hadn't gotten lost! Is there a way to close the tracker > > item for it? > > I think you should be able to do that.
Ah-ha, yes, I've closed it now. :) https://salsa.debian.org/grub-team/grub/-/merge_requests/23 > > > > [...] > > > > I realized right now that MD_MAX_DISKS defined in commit c39f27cd6 > > > > (osdep/linux: Fix md array device enumeration) is not in sync with > > > > commit 2a5e3c1f2 (disk/diskfilter: Don't make a RAID array with more > > > > than 1024 disks). I think we should sync both numbers down to 1024... > > > > > > +1 > > > > Yeah, seems reasonable, though as I hinted in the original patch, this > > number appeared to have been arbitrarily chosen by mdadm at the time. > > OK, we will bump it to 4096 as well. Yeah, I think _technically_ it can be higher than 1024, though ... I struggle to imagine this for a boot device. ;) -- Kees Cook _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
