Re: Proposal to enhance boot path selections
Andrew Randrianasulu <[email protected]> Sun, 11 May 2025 18:12:58 +0300
| Newsgroups | gmane.os.netbsd.devel.kernel,gmane.os.netbsd.ports.i386,gmane.os.netbsd.ports.x86-64 |
|---|---|
| Message-ID | <CA+rFky6C87UWybtik7gPxLB2np99N6=4nf2Qw0Gvc8ZZPcq6Lg@mail.gmail.com> |
--0000000000004e3d550634dda303 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =D0=B2=D1=81, 11 =D0=BC=D0=B0=D1=8F 2025 =D0=B3., 18:03 Paul Goyette <paul@= whooppee.com>: > You're asking for a lot, and I am not prepared to spend the time it > would require. I have already updated x86/boot(8) and added a Xr > for mk.conf(5), and if someone wants to write a wiki page I will > happily review/edit it. wiz@ has already created a wiki page (see > https://wiki.netbsd.org/kernel_dir/) that may address some of your > concerns. > >From this page it looks like kern + modules dir will lost modules arch/version information previously plainly visible in path? > I've also done my best here in this thread (and elsewhere) to make it > as clear as I can that this relates to KERNEL_DIR, and that is only > pertains to i386 and amd64. The option is entirely optional, but the > bootloader needs to cope with both "set" and "unset" environments, to > avoid a proliferation of boot images. > > Most of the impact of KERNEL_DIR is already committed; this newest > proposal is minor and has minimal impact. > > > > On Sun, 11 May 2025, Taylor R Campbell wrote: > > >> Date: Sun, 11 May 2025 06:39:42 -0700 (PDT) > >> From: Paul Goyette <[email protected]> > >> > >> On Sun, 11 May 2025, Greg Troxel wrote: > >> > >>> Thus I suspect I am missing something. > >> > >> Yup, I think you're missing the fact that all of this relates to the > >> ratther new-ish KERNEL_DIR option, support for which was only recently > >> completed (by myself). KERNEL_DIR is described briefly in options(4), > >> and it is noted in both CHANGES and UPDATING. > >> > >> In short, KERNEL_DIR provides a mechanism to keep a kernel and its > >> associated modules together, addressing one of the most common > >> complaints about modules. > >> > >> Sorry for not making this more clear. > > > > I think it is important to > > > > (a) make this clear and obvious and intuitive, _and_ > > (b) make sure we have tested any plausible transition paths that might > > happen. > > > > To that end, this present proposal aside (I haven't digested it, no > > comments about it), I would strongly suggest that you make a wiki page > > describing everything about the KERNEL_DIR changes (not just the terse > > summary in CHANGES, or the notes in UPDATING which are only for an > > audience of current users to maintain MKUPDATE=3Dyes builds), including > > a systematic table of: > > > > 1. What has changed or will change in the standard bootloader? > > 2. What has changed or will change in a custom bootloader with any new > > build options? > > 3. What has changed or will change in an unmodified GENERIC kernel? > > 4. What has changed or will change in a custom kernel with any new > > build options? > > 5. What does/will sysinst do? > > 6. How are transitions/upgrades expected to happen? What will happen > > when a stock netbsd-10 installation is updated to a stock netbsd-11 > > installation? > > 7. How have all of these scenarios been tested? > > > > We really need to make sure this doesn't become another /var/db/pkg > > renaming debacle that leaves everyone's machines in confusing > > inconsistent states requiring manual intervention. > > > > This type of change -- substantially altering the semantics of how the > > bootloader finds the kernel -- has an extremely high risk, not just of > > putting machines into confusing states, but of rendering them > > unbootable when you update the bootloader. And, if we were doing it > > again, I would ask that any changes be proposed to tech-kern and > > port-*, with all this relevant information, _before_ committing > > anything that affects default builds. > > > > (It's likely that there already are good answers to all of these > > questions, and you've already figured all this out -- it's just not > > clear to me from the CHANGES and UPDATING notes and the scattering of > > commit messages I've seen fly by, so I'm just asking for a clear > > picture to be presented in an obvious place to see how this will > > affect users.) > > > > !DSPAM:6820b69e284681540015745! > > > > > > +---------------------+--------------------------+----------------------+ > | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses: | > | (Retired) | 1B11 1849 721C 56C8 F63A | [email protected] | > | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | [email protected] | > | & Network Engineer | | [email protected] | > +---------------------+--------------------------+----------------------+ > --0000000000004e3d550634dda303 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><br><br><div class=3D"gmail_quote gmail_quote_contai= ner"><div dir=3D"ltr" class=3D"gmail_attr">=D0=B2=D1=81, 11 =D0=BC=D0=B0=D1= =8F 2025 =D0=B3., 18:03 Paul Goyette <<a href=3D"mailto:[email protected]= m">[email protected]</a>>:<br></div><blockquote class=3D"gmail_quote" st= yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You&#= 39;re asking for a lot, and I am not prepared to spend the time it<br> would require.=C2=A0 I have already updated x86/boot(8) and added a Xr<br> for mk.conf(5), and if someone wants to write a wiki page I will<br> happily review/edit it.=C2=A0 wiz@ has already created a wiki page (see<br> <a href=3D"https://wiki.netbsd.org/kernel_dir/" rel=3D"noreferrer noreferre= r" target=3D"_blank">https://wiki.netbsd.org/kernel_dir/</a>) that may addr= ess some of your<br> concerns.<br></blockquote></div></div><div dir=3D"auto"><br></div><div dir= =3D"auto">From this page it looks like kern + modules dir will lost modules= arch/version information previously plainly visible in path?</div><div dir= =3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div= ><div dir=3D"auto"><div class=3D"gmail_quote gmail_quote_container"><blockq= uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex"> <br> I've also done my best here in this thread (and elsewhere) to make it<b= r> as clear as I can that this relates to KERNEL_DIR, and that is only<br> pertains to i386 and amd64.=C2=A0 The option is entirely optional, but the<= br> bootloader needs to cope with both "set" and "unset" en= vironments, to<br> avoid a proliferation of boot images.<br> <br> Most of the impact of KERNEL_DIR is already committed; this newest<br> proposal is minor and has minimal impact.<br> <br> <br> <br> On Sun, 11 May 2025, Taylor R Campbell wrote:<br> <br> >> Date: Sun, 11 May 2025 06:39:42 -0700 (PDT)<br> >> From: Paul Goyette <<a href=3D"mailto:[email protected]" target= =3D"_blank" rel=3D"noreferrer">[email protected]</a>><br> >><br> >> On Sun, 11 May 2025, Greg Troxel wrote:<br> >><br> >>> Thus I suspect I am missing something.<br> >><br> >> Yup, I think you're missing the fact that all of this relates = to the<br> >> ratther new-ish KERNEL_DIR option, support for which was only rece= ntly<br> >> completed (by myself).=C2=A0 KERNEL_DIR is described briefly in op= tions(4),<br> >> and it is noted in both CHANGES and UPDATING.<br> >><br> >> In short, KERNEL_DIR provides a mechanism to keep a kernel and its= <br> >> associated modules together, addressing one of the most common<br> >> complaints about modules.<br> >><br> >> Sorry for not making this more clear.<br> ><br> > I think it is important to<br> ><br> > (a) make this clear and obvious and intuitive, _and_<br> > (b) make sure we have tested any plausible transition paths that might= <br> > happen.<br> ><br> > To that end, this present proposal aside (I haven't digested it, n= o<br> > comments about it), I would strongly suggest that you make a wiki page= <br> > describing everything about the KERNEL_DIR changes (not just the terse= <br> > summary in CHANGES, or the notes in UPDATING which are only for an<br> > audience of current users to maintain MKUPDATE=3Dyes builds), includin= g<br> > a systematic table of:<br> ><br> > 1. What has changed or will change in the standard bootloader?<br> > 2. What has changed or will change in a custom bootloader with any new= <br> >=C2=A0 =C2=A0build options?<br> > 3. What has changed or will change in an unmodified GENERIC kernel?<br= > > 4. What has changed or will change in a custom kernel with any new<br> >=C2=A0 =C2=A0build options?<br> > 5. What does/will sysinst do?<br> > 6. How are transitions/upgrades expected to happen?=C2=A0 What will ha= ppen<br> >=C2=A0 =C2=A0when a stock netbsd-10 installation is updated to a stock = netbsd-11<br> >=C2=A0 =C2=A0installation?<br> > 7. How have all of these scenarios been tested?<br> ><br> > We really need to make sure this doesn't become another /var/db/pk= g<br> > renaming debacle that leaves everyone's machines in confusing<br> > inconsistent states requiring manual intervention.<br> ><br> > This type of change -- substantially altering the semantics of how the= <br> > bootloader finds the kernel -- has an extremely high risk, not just of= <br> > putting machines into confusing states, but of rendering them<br> > unbootable when you update the bootloader.=C2=A0 And, if we were doing= it<br> > again, I would ask that any changes be proposed to tech-kern and<br> > port-*, with all this relevant information, _before_ committing<br> > anything that affects default builds.<br> ><br> > (It's likely that there already are good answers to all of these<b= r> > questions, and you've already figured all this out -- it's jus= t not<br> > clear to me from the CHANGES and UPDATING notes and the scattering of<= br> > commit messages I've seen fly by, so I'm just asking for a cle= ar<br> > picture to be presented in an obvious place to see how this will<br> > affect users.)<br> ><br> > !DSPAM:6820b69e284681540015745!<br> ><br> ><br> <br> +---------------------+--------------------------+----------------------+<b= r> | Paul Goyette (.sig) | PGP Key fingerprint:=C2=A0 =C2=A0 =C2=A0| E-mail ad= dresses:=C2=A0 =C2=A0 |<br> | (Retired)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 1B11 1849 721C 56C8 F= 63A | <a href=3D"mailto:[email protected]" target=3D"_blank" rel=3D"norefer= rer">[email protected]</a>=C2=A0 =C2=A0 |<br> | Software Developer=C2=A0 | 6E2E 05FD 15CE 9F2D 5102 | <a href=3D"mailto:p= [email protected]" target=3D"_blank" rel=3D"noreferrer">[email protected]= g</a>=C2=A0 |<br> | & Network Engineer=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | <a href=3D"mailto:pgoyet= [email protected]" target=3D"_blank" rel=3D"noreferrer">[email protected]</= a> |<br> +---------------------+--------------------------+----------------------+<b= r> </blockquote></div></div></div> --0000000000004e3d550634dda303--