Re: svn commit: r366626 - head/sbin/reboot
12.10.2020 10:33, Alexey Dokuchaev wrote: > On Sun, Oct 11, 2020 at 09:17:42PM -0600, Warner Losh wrote: >> On Sun, Oct 11, 2020, 8:13 PM Alexey Dokuchaev wrote: >>> ... >>> I still don't understand how could rm be better than graceful disabling >>> alternative configuration with nextboot_enable="NO". I most certainly >>> do *not* like when my custom config files are being removed, especially >>> silently. When I see nextboot_enable="NO" I know that the file >>> had been processed, and processed by the machine, not me (since I would >>> never add trailing space). When I don't see the file, I'd be questioning >>> myself if I've ever added it here, or maybe I put in the wrong location. >> >> Nextboot.conf is special. It will be deleted. It doesn't belong to you, it >> belongs to nextboot(8). > > OK, I see your point. > >>> Personally I find them quite useful, except when they contradict the >>> reality (like this time). In these cases, I'd fix them. >> >> For now, it's fine. Note that testing kernel sometimes *requires* additional set of loader settings like kernel parameter tuning and/or set of kernel modules loaded including NICs or GEOMs like gjournal/graid that may affect boot process. And our loader does apply such settings when processing nextboot.conf. Maybe this is the reason nextboot.conf should be removed after it fired once. I personally edit it manually every time I use this feature and I keep a copy of the file with distinct name to restore it for another run. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r366626 - head/sbin/reboot
On Sun, Oct 11, 2020 at 09:17:42PM -0600, Warner Losh wrote: > On Sun, Oct 11, 2020, 8:13 PM Alexey Dokuchaev wrote: > > ... > > I still don't understand how could rm be better than graceful disabling > > alternative configuration with nextboot_enable="NO". I most certainly > > do *not* like when my custom config files are being removed, especially > > silently. When I see nextboot_enable="NO" I know that the file > > had been processed, and processed by the machine, not me (since I would > > never add trailing space). When I don't see the file, I'd be questioning > > myself if I've ever added it here, or maybe I put in the wrong location. > > Nextboot.conf is special. It will be deleted. It doesn't belong to you, it > belongs to nextboot(8). OK, I see your point. > > Personally I find them quite useful, except when they contradict the > > reality (like this time). In these cases, I'd fix them. > > For now, it's fine. Fair enough; I guess we can now wrap this discussion up, thanks! ./danfe ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r366626 - head/sbin/reboot
On Sun, Oct 11, 2020, 8:13 PM Alexey Dokuchaev wrote: > On Sun, Oct 11, 2020 at 09:12:43AM -0600, Warner Losh wrote: > > ... > > There were cases that were discussed when the feature went in that > > required it to be removed in some failure modes for full functionality. > > I don't recall if they were in the rc thread or somewhere else. > > You mean, literally delete the file, that is, nextboot_enable="NO" can > not be enough? > Yes. Sometimes it's not reliably written in some failure scenarios. In those cases it must be deleted. > And honestly, nextboot.conf is special in so many ways. We have no > > unlink in the loader for UFS and no write for ZFS or MSDOS. In those > > What's the problem with in-place overwrite in the FAT case? > Last I checked, it wasn't implemented. It could be done, but hasn't been. > cases, the rm from rc is what you want > > I still don't understand how could rm be better than graceful disabling > alternative configuration with nextboot_enable="NO". I most certainly > do *not* like when my custom config files are being removed, especially > silently. When I see nextboot_enable="NO" I know that the file > had been processed, and processed by the machine, not me (since I would > never add trailing space). When I don't see the file, I'd be questioning > myself if I've ever added it here, or maybe I put in the wrong location. > Nextboot.conf is special. It will be deleted. It doesn't belong to you, it belongs to nextboot(8). > I'm not likely to remove it, but if UFS grows unlink in the future, > > this man page will need to change. > > Just because it's easier to implemented unlink for UFS then (over)write > for ZFS? > Both are hard in ZFS. Unlink has issues that I hadn't recalled, so that path is unlikely... > Then again, all the loser [loader?] man pages need a complete rewrite, > > or close to it. > > Personally I find them quite useful, except when they contradict the > reality (like this time). In these cases, I'd fix them. > For now, it's fine. Warner > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r366626 - head/sbin/reboot
On Sun, Oct 11, 2020 at 09:12:43AM -0600, Warner Losh wrote: > ... > There were cases that were discussed when the feature went in that > required it to be removed in some failure modes for full functionality. > I don't recall if they were in the rc thread or somewhere else. You mean, literally delete the file, that is, nextboot_enable="NO" can not be enough? > And honestly, nextboot.conf is special in so many ways. We have no > unlink in the loader for UFS and no write for ZFS or MSDOS. In those What's the problem with in-place overwrite in the FAT case? > cases, the rm from rc is what you want I still don't understand how could rm be better than graceful disabling alternative configuration with nextboot_enable="NO". I most certainly do *not* like when my custom config files are being removed, especially silently. When I see nextboot_enable="NO" I know that the file had been processed, and processed by the machine, not me (since I would never add trailing space). When I don't see the file, I'd be questioning myself if I've ever added it here, or maybe I put in the wrong location. > I'm not likely to remove it, but if UFS grows unlink in the future, > this man page will need to change. Just because it's easier to implemented unlink for UFS then (over)write for ZFS? > Then again, all the loser [loader?] man pages need a complete rewrite, > or close to it. Personally I find them quite useful, except when they contradict the reality (like this time). In these cases, I'd fix them. ./danfe ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r366626 - head/sbin/reboot
On Sun, Oct 11, 2020, 8:00 AM Kyle Evans wrote: > On Sun, Oct 11, 2020 at 8:30 AM Alexey Dokuchaev > wrote: > > > > On Sun, Oct 11, 2020 at 04:08:09PM +0300, Toomas Soome wrote: > > > > On 11. Oct 2020, at 16:01, Alexey Dokuchaev wrote: > > > >> ... > > > >> Also nextboot.conf not generic configuration file (such as > loader.conf > > > >> or loader.conf.local), but the implementation specific file, part of > > > >> special feature. > > > >> > > > >> That is, one should not assume the presence of nextboot.conf file, > make > > > >> assumptions about its content, or perform manual edits on it. > > > > > > > > Do we want it to be the second-class citizen like this? Would it > make > > > > better sense by documenting it more completely instead? > > > > > > It is not really about being second-class citizen, it really is about > if > > > and how we can implement the feature. With UFS there is a limited write > > > (write to existing, allocated disk blocks), with ZFS there is no write > to > > > file system at all. > > > > I see; that would explain why loader(8) replaces the "YES" -> > "NO", > > but I guess I'd have to read the discussion on -rc@ which lead to > r177062, > > because I don't see the reason for it to be removed (twice) if it's being > > disabled by the loader(8) earlier anyway. > > > > IMO both steps are important. You have to (at least try to) disable it > in case it doesn't get you all the way to multi-user, but then you > don't want the old contents of nextboot.conf being inadvertently used > on another boot if someone's habitually `nextboot -a`ing. > There were cases that were discussed when the geature went in that required it to be removed in some failure modes for full functionality. I don't recall if they were in the rc thread or somewhere else. And honestly, nextboot.conf is special in so many ways. We have no unlink in the loader for UFS and no write for ZFS or MSDOS. In those cases, the rm from rc is what you want (though lately we use a different mechanism for ZFS). So the docs were right before, in the big picture. The implementation detail now enshrined there is unwise. I'm not likely to remove it, but if UFS grows unlink in the future, this man page will need to change. Then again, all the loser man pages need a complete rewrite, or close to it. Warner > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r366626 - head/sbin/reboot
On Sun, Oct 11, 2020 at 8:30 AM Alexey Dokuchaev wrote: > > On Sun, Oct 11, 2020 at 04:08:09PM +0300, Toomas Soome wrote: > > > On 11. Oct 2020, at 16:01, Alexey Dokuchaev wrote: > > >> ... > > >> Also nextboot.conf not generic configuration file (such as loader.conf > > >> or loader.conf.local), but the implementation specific file, part of > > >> special feature. > > >> > > >> That is, one should not assume the presence of nextboot.conf file, make > > >> assumptions about its content, or perform manual edits on it. > > > > > > Do we want it to be the second-class citizen like this? Would it make > > > better sense by documenting it more completely instead? > > > > It is not really about being second-class citizen, it really is about if > > and how we can implement the feature. With UFS there is a limited write > > (write to existing, allocated disk blocks), with ZFS there is no write to > > file system at all. > > I see; that would explain why loader(8) replaces the "YES" -> "NO", > but I guess I'd have to read the discussion on -rc@ which lead to r177062, > because I don't see the reason for it to be removed (twice) if it's being > disabled by the loader(8) earlier anyway. > IMO both steps are important. You have to (at least try to) disable it in case it doesn't get you all the way to multi-user, but then you don't want the old contents of nextboot.conf being inadvertently used on another boot if someone's habitually `nextboot -a`ing. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r366626 - head/sbin/reboot
On Sun, Oct 11, 2020 at 04:08:09PM +0300, Toomas Soome wrote: > > On 11. Oct 2020, at 16:01, Alexey Dokuchaev wrote: > >> ... > >> Also nextboot.conf not generic configuration file (such as loader.conf > >> or loader.conf.local), but the implementation specific file, part of > >> special feature. > >> > >> That is, one should not assume the presence of nextboot.conf file, make > >> assumptions about its content, or perform manual edits on it. > > > > Do we want it to be the second-class citizen like this? Would it make > > better sense by documenting it more completely instead? > > It is not really about being second-class citizen, it really is about if > and how we can implement the feature. With UFS there is a limited write > (write to existing, allocated disk blocks), with ZFS there is no write to > file system at all. I see; that would explain why loader(8) replaces the "YES" -> "NO", but I guess I'd have to read the discussion on -rc@ which lead to r177062, because I don't see the reason for it to be removed (twice) if it's being disabled by the loader(8) earlier anyway. ./danfe ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r366626 - head/sbin/reboot
> On 11. Oct 2020, at 16:01, Alexey Dokuchaev wrote: > > On Sun, Oct 11, 2020 at 03:20:16PM +0300, Toomas Soome wrote: >> Please note, the remove is done by rc script during the boot. > > But not by the loader(8) as the page used to claim. It confused me how to > avoid the remove, and only later I've discovered with some relief that it > is in fact not being removed, but only disabled (which IMHO is a lot more > graceful and thus correct behavior). > >> Also nextboot.conf not generic configuration file (such as loader.conf >> or loader.conf.local), but the implementation specific file, part of >> special feature. >> >> That is, one should not assume the presence of nextboot.conf file, make >> assumptions about its content, or perform manual edits on it. > > Do we want it to be the second-class citizen like this? Would it make > better sense by documenting it more completely instead? > > ./danfe It is not really about being second-class citizen, it really is about if and how we can implement the feature. With UFS there is a limited write (write to existing, allocated disk blocks), with zfs there is no write to file system at all. rgds, toomas ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r366626 - head/sbin/reboot
On Sun, Oct 11, 2020 at 03:20:16PM +0300, Toomas Soome wrote: > Please note, the remove is done by rc script during the boot. But not by the loader(8) as the page used to claim. It confused me how to avoid the remove, and only later I've discovered with some relief that it is in fact not being removed, but only disabled (which IMHO is a lot more graceful and thus correct behavior). > Also nextboot.conf not generic configuration file (such as loader.conf > or loader.conf.local), but the implementation specific file, part of > special feature. > > That is, one should not assume the presence of nextboot.conf file, make > assumptions about its content, or perform manual edits on it. Do we want it to be the second-class citizen like this? Would it make better sense by documenting it more completely instead? ./danfe ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r366626 - head/sbin/reboot
Please note, the remove is done by rc script during the boot. Also nextboot.conf not generic configuration file (such as loader.conf or loader.conf.local), but the implementation specific file, part of special feature. That is, one should not assume the presence of nextboot.conf file, make assumptions about its content, or perform manual edits on it. Rgds, Toomas > On 11. Oct 2020, at 13:40, Alexey Dokuchaev wrote: > > Author: danfe (ports committer) > Date: Sun Oct 11 10:40:11 2020 > New Revision: 366626 > URL: https://svnweb.freebsd.org/changeset/base/366626 > > Log: > The nextboot(8) manual page currently says that the loader(8) would delete > the /boot/nextboot.conf file or its contents which is 1) not the most user- > friendly way of working with custom configurations, and 2) simply not true > for both Forth and Lua implementations: they would not delete it, but just > change the setting to "NO", that is, disable it. > > While at it, add one missing serial (Oxford) comma and fix some bogus line > wraps along the way. > > Approved by:bcr (manpages) > Differential Revision:https://reviews.freebsd.org/D25971 > > Modified: > head/sbin/reboot/nextboot.8 > > Modified: head/sbin/reboot/nextboot.8 > == > --- head/sbin/reboot/nextboot.8Sun Oct 11 09:05:13 2020(r366625) > +++ head/sbin/reboot/nextboot.8Sun Oct 11 10:40:11 2020(r366626) > @@ -24,7 +24,7 @@ > .\" > .\" $FreeBSD$ > .\" > -.Dd September 19, 2020 > +.Dd October 11, 2020 > .Dt NEXTBOOT 8 > .Os > .Sh NAME > @@ -41,14 +41,14 @@ > .Sh DESCRIPTION > The > .Nm > -utility allows specifying some combination of an alternate kernel, boot flags > -and kernel environment for the > -next time the machine is booted. > +utility allows specifying some combination of an alternate kernel, boot > +flags, and kernel environment for the next time the machine is booted. > Once the > .Xr loader 8 > -loads in the new kernel > -information, it is deleted so in case the new kernel hangs the machine, > -once it is rebooted, the machine will automatically revert to its previous > +loads in the new kernel information from the > +.Pa /boot/nextboot.conf > +file, it is disabled so in case the new kernel hangs the machine, once > +it is rebooted, the machine will automatically revert to its previous > configuration. > .Pp > The options are as follows: ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
