On Mon, 4 May 2009 12:35:12 +0200 Toni Mueller <openbsd-m...@oeko.net> wrote:
> Hi, > > On Sun, 03.05.2009 at 11:00:02 -0700, J.C. Roberts > <list-...@designtools.org> wrote: > > I never said the boot.conf was not useful. I said the i386\amd64 > > hack > > I don't see how 'set image ...' is a hack, nor how it would be > specific to i386 and amd64. > If you read the boot.conf(8) man page, you'd already know it's a hack to get around the limitations of the x86 BIOS. > > The new installer (destined for 4.6) in snapshots *already* picks > > the right kernel (GENERIC or GENERIC.MP) for the system, and > > installs it as /bsd. > > This makes it harder to move a set of already-installed disks to a > different machine, a facility which I value for fast recovery. > nope. > > On all archs, when you wish to boot to a different on-disk kernel > > you cab do it either by copying/moving kernel file to /bsd, and/or > > specifying the kernel file at boot time `boot /mybsd.custom.hack` > > I dislike moving kernels around, but editing boot.conf is ok. > You need to inspect your own bias and hence, opinion. There is no solid technical reason for one being OK and the other being disliked. The only place where moving kernels around can be problematic is on systems where there is a limitation of "bootable" disk space (i.e. often the first 512MB of the disk). Again, this is caused by a bad design of the x86 PC BIOS. > > When you treat i386\amd64 differently with the boot.conf kernel > > designation feature, you are not only making things less portable, > > but worse, you're showing a bias towards what many consider to be a > > flawed system design. > > Hmmm... Can you please point me to some reading about the upcoming > "non-flawed system design"? > I think a more accurate way to phrase it is "less-flawed" ;-) Doing some reading and testing with OpenFirmware (macppc, sparc, alpha, ...) will show you some better ways to handle things. If you understand the hardware itself, know how to program in Forth, and the system has NVRAM, you can actually write scripts to patch the OpenFirmware BIOS on the fly as it loads from FLASH/ROM. > > Now, let's say you are using the /etc/boot.conf hack to boot to > > bsd.mp, and you go to update your stable system running an MP > > kernel. You read the FAQ and follow the directions for installing a > > new kernel and rebooting before building the whole system. > > > > When you do `make install` in your ../compile/GENERIC.MP/ directory, > > the newly built kernel gets installed as /bsd > > > > You supposedly reboot to your new kernel... and guess what? --Due to > > your boot.conf hack you're still running your *old* /bsd.mp kernel > > rather than your newly built /bsd kernel. > > This problem imho *only* arises as a consequence due to installing the > new kernel in the wrong place. Would it have been installed > in /bsd.mp, nothing would have gone wrong. You could even opt to > overwrite /bsd.mp in that case, too, to make sure that you are > backwards-compatible. > > Nope. It is better for everything to be consistent. When a new kernel is built and installed, it should be written to "/bsd" rather than some custom name. Having a second stage boot loader like boot.conf that on *only* some archs will change the decision of which kernel to load leads to confusion and mistakes. Just because you might like the non-portable utility offered by the "set image" feature of boot.conf does not make it a good idea. -- J.C. Roberts
