1 |
Etaoin Shrdlu <shrdlu@×××××××××××××.org> posted |
2 |
200612202249.56315.shrdlu@×××××××××××××.org, excerpted below, on Wed, 20 |
3 |
Dec 2006 22:49:56 +0100: |
4 |
|
5 |
Duncan wrote... |
6 |
|
7 |
>> I decided it was better to spend my time learning [GRUB] than trying to |
8 |
>> trace down and figure out all the ins and outs of the LILO thing to my |
9 |
>> satisfaction, so that's exactly what I did, and indeed, I AM rather |
10 |
>> happier with GRUB, now that I actually took the time to learn how to |
11 |
>> work with it. |
12 |
> |
13 |
> I was once a LILO-only user (mostly because GRUB was not popular when I |
14 |
> first started using linux, so I simply stayed with LILO), but I must |
15 |
> admit that I'm slowly migrating to GRUB. The great feature is (among |
16 |
> other things) the ability to fully edit the command line before booting, |
17 |
> which gives you more control than LILO over the boot process. |
18 |
|
19 |
Exactly. That's the big bonus of GRUB and the reason more distributions |
20 |
are defaulting to it. |
21 |
|
22 |
Contrastingly, one of the weaknesses of GRUB for quite awhile was that it |
23 |
didn't have a failsafe method to do an unattented/remote boot. That is, |
24 |
with LILO, one could remotely install a new kernel on their colocated |
25 |
server and set it as a once-only boot-to that would default to a known |
26 |
good kernel on subsequent boots, if the first boot failed. Combine that |
27 |
with a hardware watchdog card to reboot if it didn't get its timer reset |
28 |
periodically, and a new kernel that failed to boot didn't require onsite |
29 |
intervention. GRUB had nothing at the time like that, and would require |
30 |
onsite intervention, so LILO remained the preferred choice for remotely |
31 |
administered systems. I'm not into that end of things so I'm poorly |
32 |
informed on GRUB's current capacities in the area, but I understand that's |
33 |
no longer the case, that it can do single-shot then return to a standard |
34 |
default boot, just as can LILO, now. Thus, there's now little reason |
35 |
other than older sysadmin familiarity with it (and the odd corner case |
36 |
hardware issue with one or the other) to keep LILO over GRUB. |
37 |
|
38 |
>> FWIW, now I'm looking at LinuxBIOS |
39 |
> |
40 |
> This sounds really interesting and promising. I wonder how they can do |
41 |
> "3 seconds from power-on to Linux console". Even if the LinuxBIOS loads |
42 |
> straightly a kernel as the payload, the kernel still takes more than 3 |
43 |
> seconds to initialize...this alone would be a good enough reason to do |
44 |
> the switch! I hope you eventually succeed in the task. |
45 |
|
46 |
Well, one BIOS-specific but entirely practical reason I'm looking into |
47 |
LinuxBIOS ATM is that the current proprietary BIOS on my main system has |
48 |
some frustrating issues... Namely, despite ranking the boot order to put |
49 |
the hard drive first, and turning off scan of the floppy (and DVD, tho |
50 |
fortunately it's a bit faster), the BIOS still INSISTS on activating and |
51 |
scanning both for media before activating the hard drive boot. The only |
52 |
way to avoid the issue appears to be to deactivate the offending hardware |
53 |
entirely in the BIOS, thereby not allowing it to be used post-boot, |
54 |
either. Older BIOS versions didn't have this issue but had other issues, |
55 |
including lacking the ability to limit memory timings. As long time list |
56 |
regulars will recall, I had a terrible time with (generic, yes, I |
57 |
know) memory that simply wasn't stable at its rated speeds, and only |
58 |
worked well once I upgraded the BIOS and got the ability to limit memory |
59 |
clock speeds. |
60 |
|
61 |
Thus, a large fraction of my reboot time is frustratingly going to this |
62 |
totally unnecessary floppy and DVD-drive scan, and the rest of the |
63 |
hardware, kernel, and general system init process, don't seem so long in |
64 |
comparison, particularly when they are doing obviously useful things as I |
65 |
can see from dmesg and the like. If there was only a way to disable the |
66 |
stupid removable media scans properly... |
67 |
|
68 |
Of course, I'm not a BIOS programmer by a LONG shot, so just having the |
69 |
BIOS sources to tinker with wouldn't help me much, but having an open |
70 |
choice is certainly appealing. While at this stage there may be such |
71 |
frustrating issues with LinuxBIOS as well, if it were to get to even a |
72 |
decent fraction of the current Linux acceptance level, there'd be enough |
73 |
momentum behind it to have a good chance of dealing with this sort of |
74 |
issue on the majority of supported hardware. |
75 |
|
76 |
As for the 3-second claim, what they are doing is taking a drastically |
77 |
slimmed down kernel, customized for the particular hardware such that it's |
78 |
not necessary to do much of the standard kernel init and hardware scan |
79 |
process. Combine that with the fact that they avoid the current situation |
80 |
where the BIOS scans and inits much of the hardware, only to have the |
81 |
kernel redo much of the same stuff, and the effect cutting out that |
82 |
duplicated scanning has on the boot time, and a 3-second kernel init time |
83 |
isn't so far fetched. |
84 |
|
85 |
If I understand the way they do it, one of the tricks they use is to take |
86 |
hardware configuration information from the running system and from the |
87 |
config files at build time, and actually build not only a slimmed down |
88 |
kernel that doesn't scan for hardware that's known not to be there, but |
89 |
they actually pre-init part of the kernel at build-time, so it doesn't |
90 |
have to do that scanning at all, it's simply loaded straight from |
91 |
FLASH-ROM already partially initialized and ready to go. |
92 |
|
93 |
Something else they mention on the site... they had originally predicted |
94 |
BIOS ROM sizes to increase faster than they have, and expected 8-32 Mbit |
95 |
(so 1-4 MByte) BIOS image sizes by now. With that, they could have fit an |
96 |
entire compressed main kernel image complete with initramfs in the BIOS |
97 |
image. Instead, 4-8 Mbit (half to 1 MB) BIOS capacities are now the norm, |
98 |
and a boot directly to full-size kernel remains impractical. Thus, they |
99 |
use multi-stage approach, with a second in-BIOS stage consisting of either |
100 |
a larger bootloader that reads off of disk or network, or an extremely |
101 |
stripped down kernel (other second stages such as the OpenFirmware BIOS |
102 |
that Macs use are also available), then making use of the still fairly |
103 |
new Linux kernel kexec feature to allow the stripped down kernel to load |
104 |
the full kernel off of disk and kexec into it. |
105 |
|
106 |
My big question at this time, one I didn't find an answer to in my |
107 |
initial round of preliminary research, is what happens to all the existing |
108 |
proprietary BIOS functions such as memory configuration, and BIOS level |
109 |
enabling/disabling of various on-board hardware. I /did/ see that there's |
110 |
a provision for cutting out the various firmware mini-drivers (such as the |
111 |
common VideoBIOS, NetBIOS, and RAID firmwares, subpackaged into |
112 |
proprietary BIOSs) and including the binary blob images in LinuxBIOS as |
113 |
well (yes, the binary blobs are galling, but it's a further step in the |
114 |
right direction from a full proprietary BIOS), so that's addressed, but |
115 |
the functionality such as memory config normally provided by the BIOS |
116 |
itself (AFAIK)? I'm not sure I'm ready to forego the ability to |
117 |
BIOS-disable the various on-board hardware, and BIOS-configure stuff such |
118 |
as memory parameters. From my limited look around, I /think/ a fair |
119 |
amount of that is configurable via text based config files at |
120 |
BIOS-build-time, which is reasonable, but ONLY if one has the hardware to |
121 |
supply a known-working backup BIOS option should one screw up their config |
122 |
while experimenting. (Some mobos include such a backup BIOS as a feature, |
123 |
making bricking a machine due to botched flash upgrade a threat for |
124 |
others to worry about. My present one does not.) |
125 |
|
126 |
The LinuxBIOS site /does/ point to sources for all the necessary BIOS |
127 |
switcher hardware and extra BIOS chips, but the one link I clicked on was |
128 |
either stale or required Flash (as in the browser plugin not the memory |
129 |
type) or the like to load, and I didn't investigate that aspect further, |
130 |
so I've yet no idea what the cost would be. Still, the site implies it's |
131 |
rather more reasonable than I had thought based on the limited outdated |
132 |
information I'd run across earlier, but really, that's to be expected |
133 |
given the rise in popularity and scale and dropping of cost of flash |
134 |
memory technology over the last half-decade or so. The implied cost on |
135 |
the site is less than $100 (US) now, which is significantly less than the |
136 |
$500 or more I had thought, based on old information, which at least makes |
137 |
it reasonably economically accessible to those with a non-professional |
138 |
interest in it, unlike the $500 price-point, and it sounded like a $20-50 |
139 |
investment may do it. |
140 |
|
141 |
Like I said tho, I've got significantly more research to do before I'm |
142 |
actually downloading and running BIOS-builders. It's definitely a |
143 |
mid-term interest, not something I'll be doing before new year's day. |
144 |
|
145 |
-- |
146 |
Duncan - List replies preferred. No HTML msgs. |
147 |
"Every nonfree program has a lord, a master -- |
148 |
and if you use the program, he is your master." Richard Stallman |
149 |
|
150 |
-- |
151 |
gentoo-amd64@g.o mailing list |