Date: Wed, 16 Jan 2013 02:34:29 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: Olivier =?iso-8859-1?Q?Cochard-Labb=E9?= <olivier@cochard.me> Cc: freebsd-sparc64@freebsd.org Subject: Re: How to retrieve the "bootpath" variable in a running FreeBSD ? Message-ID: <20130116013429.GA28437@alchemy.franken.de> In-Reply-To: <CA%2Bq%2BTcoPDCZHP5xgRymEBMe3GpBPQir%2BLrOogQ6n1Ho9%2BM4oEA@mail.gmail.com> References: <CA%2Bq%2BTcrLq2tJd0ffLGgiswBkozs4T=pPwjby55B1FbD=pBE26A@mail.gmail.com> <20130113.075038.471841385206679419.hrs@allbsd.org> <CA%2Bq%2BTcoPDCZHP5xgRymEBMe3GpBPQir%2BLrOogQ6n1Ho9%2BM4oEA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 13, 2013 at 01:27:36AM +0100, Olivier Cochard-Labbé wrote: > On Sat, Jan 12, 2013 at 11:50 PM, Hiroki Sato <hrs@freebsd.org> wrote: > > > > Try: > > > > % kenv currdev > > > > Thanks a lot's ! > > Now my eeprom is correctly updated, just a last bug to fix. > After updating the eeprom from FreeBSD I need to issue a cold-reboot > for eeprom changes being applied (poweroff+poweron or "boot" command > in OBP): A simple "reboot" from SSH console is not enough. > I don't know if it's my old Sun Blade 150 that have this problem or if > it's a normal sparc behavior. > Uhm, that's tricky. I haven't implemented that part but AFAICT, the current behavior of rebooting from the previously used bootpath rather than from what is specified via boot-device (now) is on purpose and actually I make heavy use of it. Normally, I boot my machines from disk set via boot-device, except for kernel development which I typically use netbooting for. In order to do so, I interrupt the boot process and boot via `boot net`. It's very convenient that this sticks across reboots until one power cycles the machine or explicitly boots from disk again without having to fiddle with boot-device. The behavior you are asking for can also be implemented but I can't think of a proper logic for determining what to do when boot-device and bootpath disagree and I don't want to get rid of the current one :) If you need that alternate behavior the best way forward seems to be to add a switch for it to reboot(8). Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130116013429.GA28437>