From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.62) (envelope-from ) id 1GxKJw-0005KR-TU for garchives@archives.gentoo.org; Thu, 21 Dec 2006 09:34:37 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.8) with SMTP id kBL9VZn2022759; Thu, 21 Dec 2006 09:31:35 GMT Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by robin.gentoo.org (8.13.8/8.13.8) with ESMTP id kBL9VYbZ010523 for ; Thu, 21 Dec 2006 09:31:34 GMT Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GxKGr-0000vm-1L for gentoo-amd64@lists.gentoo.org; Thu, 21 Dec 2006 10:31:25 +0100 Received: from ip68-231-13-122.ph.ph.cox.net ([68.231.13.122]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Dec 2006 10:31:25 +0100 Received: from 1i5t5.duncan by ip68-231-13-122.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Dec 2006 10:31:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: Emerging package as both 64 and 32 bit Date: Thu, 21 Dec 2006 09:31:11 +0000 (UTC) Message-ID: References: <200612181510.08865.shrdlu@unlimitedmail.org> <200612202249.56315.shrdlu@unlimitedmail.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-13-122.ph.ph.cox.net User-Agent: pan 0.120 (Plate of Shrimp) Sender: news X-Archives-Salt: c0bc53e7-0118-4727-a9b7-9b7734e06f48 X-Archives-Hash: ef597b5132feaf1aa33d3496708c062f Etaoin Shrdlu posted 200612202249.56315.shrdlu@unlimitedmail.org, excerpted below, on Wed, 20 Dec 2006 22:49:56 +0100: Duncan wrote... >> I decided it was better to spend my time learning [GRUB] than trying to >> trace down and figure out all the ins and outs of the LILO thing to my >> satisfaction, so that's exactly what I did, and indeed, I AM rather >> happier with GRUB, now that I actually took the time to learn how to >> work with it. > > I was once a LILO-only user (mostly because GRUB was not popular when I > first started using linux, so I simply stayed with LILO), but I must > admit that I'm slowly migrating to GRUB. The great feature is (among > other things) the ability to fully edit the command line before booting, > which gives you more control than LILO over the boot process. Exactly. That's the big bonus of GRUB and the reason more distributions are defaulting to it. Contrastingly, one of the weaknesses of GRUB for quite awhile was that it didn't have a failsafe method to do an unattented/remote boot. That is, with LILO, one could remotely install a new kernel on their colocated server and set it as a once-only boot-to that would default to a known good kernel on subsequent boots, if the first boot failed. Combine that with a hardware watchdog card to reboot if it didn't get its timer reset periodically, and a new kernel that failed to boot didn't require onsite intervention. GRUB had nothing at the time like that, and would require onsite intervention, so LILO remained the preferred choice for remotely administered systems. I'm not into that end of things so I'm poorly informed on GRUB's current capacities in the area, but I understand that's no longer the case, that it can do single-shot then return to a standard default boot, just as can LILO, now. Thus, there's now little reason other than older sysadmin familiarity with it (and the odd corner case hardware issue with one or the other) to keep LILO over GRUB. >> FWIW, now I'm looking at LinuxBIOS > > This sounds really interesting and promising. I wonder how they can do > "3 seconds from power-on to Linux console". Even if the LinuxBIOS loads > straightly a kernel as the payload, the kernel still takes more than 3 > seconds to initialize...this alone would be a good enough reason to do > the switch! I hope you eventually succeed in the task. Well, one BIOS-specific but entirely practical reason I'm looking into LinuxBIOS ATM is that the current proprietary BIOS on my main system has some frustrating issues... Namely, despite ranking the boot order to put the hard drive first, and turning off scan of the floppy (and DVD, tho fortunately it's a bit faster), the BIOS still INSISTS on activating and scanning both for media before activating the hard drive boot. The only way to avoid the issue appears to be to deactivate the offending hardware entirely in the BIOS, thereby not allowing it to be used post-boot, either. Older BIOS versions didn't have this issue but had other issues, including lacking the ability to limit memory timings. As long time list regulars will recall, I had a terrible time with (generic, yes, I know) memory that simply wasn't stable at its rated speeds, and only worked well once I upgraded the BIOS and got the ability to limit memory clock speeds. Thus, a large fraction of my reboot time is frustratingly going to this totally unnecessary floppy and DVD-drive scan, and the rest of the hardware, kernel, and general system init process, don't seem so long in comparison, particularly when they are doing obviously useful things as I can see from dmesg and the like. If there was only a way to disable the stupid removable media scans properly... Of course, I'm not a BIOS programmer by a LONG shot, so just having the BIOS sources to tinker with wouldn't help me much, but having an open choice is certainly appealing. While at this stage there may be such frustrating issues with LinuxBIOS as well, if it were to get to even a decent fraction of the current Linux acceptance level, there'd be enough momentum behind it to have a good chance of dealing with this sort of issue on the majority of supported hardware. As for the 3-second claim, what they are doing is taking a drastically slimmed down kernel, customized for the particular hardware such that it's not necessary to do much of the standard kernel init and hardware scan process. Combine that with the fact that they avoid the current situation where the BIOS scans and inits much of the hardware, only to have the kernel redo much of the same stuff, and the effect cutting out that duplicated scanning has on the boot time, and a 3-second kernel init time isn't so far fetched. If I understand the way they do it, one of the tricks they use is to take hardware configuration information from the running system and from the config files at build time, and actually build not only a slimmed down kernel that doesn't scan for hardware that's known not to be there, but they actually pre-init part of the kernel at build-time, so it doesn't have to do that scanning at all, it's simply loaded straight from FLASH-ROM already partially initialized and ready to go. Something else they mention on the site... they had originally predicted BIOS ROM sizes to increase faster than they have, and expected 8-32 Mbit (so 1-4 MByte) BIOS image sizes by now. With that, they could have fit an entire compressed main kernel image complete with initramfs in the BIOS image. Instead, 4-8 Mbit (half to 1 MB) BIOS capacities are now the norm, and a boot directly to full-size kernel remains impractical. Thus, they use multi-stage approach, with a second in-BIOS stage consisting of either a larger bootloader that reads off of disk or network, or an extremely stripped down kernel (other second stages such as the OpenFirmware BIOS that Macs use are also available), then making use of the still fairly new Linux kernel kexec feature to allow the stripped down kernel to load the full kernel off of disk and kexec into it. My big question at this time, one I didn't find an answer to in my initial round of preliminary research, is what happens to all the existing proprietary BIOS functions such as memory configuration, and BIOS level enabling/disabling of various on-board hardware. I /did/ see that there's a provision for cutting out the various firmware mini-drivers (such as the common VideoBIOS, NetBIOS, and RAID firmwares, subpackaged into proprietary BIOSs) and including the binary blob images in LinuxBIOS as well (yes, the binary blobs are galling, but it's a further step in the right direction from a full proprietary BIOS), so that's addressed, but the functionality such as memory config normally provided by the BIOS itself (AFAIK)? I'm not sure I'm ready to forego the ability to BIOS-disable the various on-board hardware, and BIOS-configure stuff such as memory parameters. From my limited look around, I /think/ a fair amount of that is configurable via text based config files at BIOS-build-time, which is reasonable, but ONLY if one has the hardware to supply a known-working backup BIOS option should one screw up their config while experimenting. (Some mobos include such a backup BIOS as a feature, making bricking a machine due to botched flash upgrade a threat for others to worry about. My present one does not.) The LinuxBIOS site /does/ point to sources for all the necessary BIOS switcher hardware and extra BIOS chips, but the one link I clicked on was either stale or required Flash (as in the browser plugin not the memory type) or the like to load, and I didn't investigate that aspect further, so I've yet no idea what the cost would be. Still, the site implies it's rather more reasonable than I had thought based on the limited outdated information I'd run across earlier, but really, that's to be expected given the rise in popularity and scale and dropping of cost of flash memory technology over the last half-decade or so. The implied cost on the site is less than $100 (US) now, which is significantly less than the $500 or more I had thought, based on old information, which at least makes it reasonably economically accessible to those with a non-professional interest in it, unlike the $500 price-point, and it sounded like a $20-50 investment may do it. Like I said tho, I've got significantly more research to do before I'm actually downloading and running BIOS-builders. It's definitely a mid-term interest, not something I'll be doing before new year's day. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-amd64@gentoo.org mailing list