Saturday, June 27, 2015

Concerning the Importance of /boot/loader for Grub2 configuration onto FreeBSD

A rhetorical question: How could it be a superbly difficult thing, to maintain a bootloader on a conventional BIOS/MBR-format hard disk drive?

I have an older laptop, which I'm applying as a network gateway appliance on a small, local area network. The laptop has three primary operating systems installed on its internal hard disk drive: The Microsoft Windows 7 operating system; Debian 8 (Jessie); a FreeBSD 10.1-STABLE source tree, updated and compiled on 18 June of this year. As of earlier this month -- contingent around what was the first time I've installed FreeBSD "Bare metal" to a laptop -- the FreeBSD operating system is now that laptop's primary operating system. This evening, I've finally figured out something of a kludge for loading FreeBSD via its boot loader -- having learned something more, it seems, about why the /boot/loader.conf file was not being loaded, previously. Though it is rather an awful kludge, but it's likewise a functionally working kludge, for the time being.

To update the boot loader for the FreeBSD installation on the laptop -- I've named it sol, figuratively --- I've now had to boot from a copy of the System Rescue CD, then mounting the partition of laptop's Debian installation, then performing a chroot to the mount point, then running grub-install and, for good measure, update-grub from there. Contrary to some earlier advice I've read, this evening I've learned that -- apparently -- I need to reference the FreeBSD installation's actual /boot/loader from within the Grub configuration file, itself.  It seems that without that, the /boot/loader.conf was being skipped, entirely.

As far as how to reference /boot/loader from within the Grub configuration file, and the FreeBSD kernel likewise, apparently that's the next tricky part -- in so much of guessing it out. Though I am certainly not certain of whether I've really guessed out all of how make a complete working Grub2 configuration for the FreeBSD installation, so far, but the following Grub2 configuration seems to suffice for it, for now:

menuentry "FreeBSD" --class freebsd --class bsd --class os {
  insmod ufs2
  insmod bsd
  search --no-floppy --set=root --file /boot/loader

  kfreebsd_loadenv /boot/device.hints
  kfreebsd /boot/loader
  #  kfreebsd /boot/kernel/kernel # ?

}

With System Rescue CD booted, the Debian installation's root partition mounted, and the shell running in chroot at its mount point, I've manually modified the chroot's /boot/grub/grub.cfg and then ran grub-install manually, virtually from Debian . I followed that with grub-update, for good measure. On rebooting, I was able to boot to the ordinary FreeBSD boot loader -- as I'd seen something similar to when first installing FreeBSD to that PC. In that much, it seemed to be a relatively straightforward configuration, finally, however that was not without a momentary message from Grub2, such that seemed to suggest as though I should load the kernel first?

Whatever was the cause of that momentary message, it disappeared quickly as the bootstrapping process was then handed over to FreeBSD. The FreeBSD boot loader menu was displayed, there presenting the opportunity to boot into multi-user mode or single-user mode, immediately. I booted into multi-user mode. After the operating system environment was fully initialized, I then logged in to the host. I was then able to verify that, finally, /boot/loader.conf had been loaded. There's a particular load-time sysctl configuration property in the host's /boot/loader.conf which serves to verify that /boot/loader.conf has been loaded.
net.inet.tcp.hostcache.cachelimit="0"

When /boot/loader.conf has not been loaded, the value of the sysctl parameter, net.inet.tcp.hostcache.cachelimit, is non-zero.

At last, hoewver, that value is being set to the value specified in /boot/loader.conf. Hopefully, the host will be performing more effectively as a LAN gateway now. Perhaps the reference to the FreeBSD installation's /boot/loader in the Grub 2 configuration may be a necessary feature of the Grub2 configuration, as in order for /boot/loader.conf to be processed during FreeBSD boostrapping?  Short or reviewing the source code of the Grub kfreebsd module, itself, I'll presume that that assumption might be accurate. Presently, it seems to me that the configuration "Works as intended," at least insofar as FreeBSD being boostrapped to the PC, and /boot/loader.conf being processed at boot time.

There was some advice I had read from a forum article, previously, which had omitted the configuration directive referencing /boot/loader for the Grub2 kfreebsd module to load FreeBSD. Concerning how the host was booting to FreeBSD without the /boot/loader directive in place, I was perplexed that /boot/loader.conf was then being ignored entirely.

Presently, I hope that I may ever be able to figure out how to configure Grub2 from FreeBSD, such that I should not have to boot to System Rescue CD in order to modify the Grub2 bootlloader configuration and it work as intended -- moreover, such that in the FreeBSD Grub2 installation, that the Grub2 configurator might locate every root operating system partition on that laptop's hard disk drive, and to permit that any of those single partitions may be booted to, with all of the configuration being developed in the FreeBSD installation. Perhaps I might be able to make reference to the Debian 8 Grub2 distribution, in the process of figuring that out -- if not, alternately, if there is a Grub2 distsribution for the Debian GNU/kFreeBSD operating system, horrid thing that it may sound like as a brand name.

The Grub2 distribution in Debian is stocked with a great, helpful number of Grub configuration scripts. Of course, the configuration scripts in the Debian 8 Grub2 distribution might not all be instantly applicable on a FreeBSD host -- there being any number of substantial differences between the GNU Linux and FreeBSD operating system kernels, such as with regards to filesystem interfaces and concepts of filesytem geometry..

Insofar as that FreeBSD is built with its own bootloader/installer, but in a plain sense, when I'd been trying to use FreeBSD boot0cfg as a bootloader on the sol  host, I'd been unable to boot to the host's partition number 7 -- it being a logical partition, effectively contained within an MS-DOS LBA partition. However, with Grub2 installed and managed albeit under another operating system on the sol host, but -- to a result -- I can now boot the PC to the FreeBSD bootloader. Candidly, it's an awkward kludge, as to how that's being managed on the host. Presently, it seems to function well enough for the simple LAN gateway host to function in all of how it is configured to function as a LAN gateway host.

At a future time, perhaps the LAN gateway PC an be replaced with a smaller BeagleBone Black single board computer. That, in itself, might require a substantial architecture so far as networked filesystems and PXE services, however, moreover with some odd kludging around about -- or rather, with some further review of the software source code of the U-Boot bootloader, as may be applied in any FreeBSD images build with Crochet, for BeagleBone, Chromebook, or other "cupboard size" computing platforms.

Presently, the LAN gateway role is kept by an old Toshiba laptop implementing an amd64 archicture. So to speak: #IWFM #YMMV

Ed. Note: In a theme of, "Correlation does not imply causality", hypothetically it may be possible that my present Grub2 configuration might not, itself, cause /boot/loader.conf to be evaluated by the FreeBSD boot loader, if the latter effect may be a side-effect of some other nondeterministic result of the configuration, as indicated. It may be possible to develop a further, exact understanding of the matter, with review of the Grub2 source code -- focusing, at least partly, about the kfreebsd Grub2 configuraiton command -- and the source code of the FreeBSD boot0 and later FreeBSD bootloader elements.

Presently, the author hopes to design a SysML sequence diagram indicating simply the state transitions of a "normal" boot0 bootstrap process, "In itself," though at the time of this Ed. Note, the author is furthermore trying to read up about Mozilla Gecko --  concerning the Document Object Model (DOM) implementation in the latter, the Gecko HTML rendering facilities, and the possibility of automating Gecko, securely, via a a CORBA process for ad hoc HTML rendering with or without an HTTP application layer protocol.


Partial Bibliography
Posted by at
Labels: , , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)