Recent Features
| |||||||||||||
LPC: Booting and systemdLPC: Booting and systemdPosted Sep 15, 2011 2:17 UTC (Thu) by busterb (subscriber, #560)Parent article: LPC: Booting and systemd
A primary bootstrap kernel is exactly how kboot works: http://kboot.sourceforge.net/
The PS3 bootloader petitboot used kboot to implement a graphical boot selector.
(Log in to post comments)
LPC: Booting and systemd Posted Sep 15, 2011 6:55 UTC (Thu) by pabs (subscriber, #43278) [Link]
Another similar project is qi-bootmenu for devices like the OpenMoko FreeRunner (gta02), which consists of the Qi bootloader, Linux and an initramfs to provide a GUI for choosing which OS to boot.
LPC: Booting and systemd Posted Sep 15, 2011 12:25 UTC (Thu) by alankila (subscriber, #47141) [Link]
Maybe we should just go back to LILO. Why boot an intermediate kernel with some added complexity if you can just boot the real one, instead.
LPC: Booting and systemd Posted Sep 15, 2011 13:20 UTC (Thu) by dan_a (subscriber, #5325) [Link]
> Maybe we should just go back to LILO. Why boot an intermediate kernel with some added complexity if you can just boot the real one, instead.
I quite enjoy doing kernel upgrades with GRUB. If you've never seen a system with a blank screen except for "LI" then you've not been using Linux very long!
LPC: Booting and systemd Posted Sep 15, 2011 15:02 UTC (Thu) by epa (subscriber, #39769) [Link]
Even GRUB isn't as friendly as it could be; I have often longed for a simple file browser with 'cd' and 'ls' commands to find the kernel and initrd to boot. Part of what makes it awkward is LVM, which isn't very discoverable (there's no command to 'list available LVM devices and ask me which ones to mount', least of all from the GRUB command line), so it will be great when LVM goes away.
A simple command interpreter built into the kernel would also be a great help, e.g. when it can't find the root filesystem or /sbin/init.
LPC: Booting and systemd Posted Sep 15, 2011 15:12 UTC (Thu) by rfunk (subscriber, #4054) [Link]
GRUB does have a limited command line allowing some level of file browsing, as I recall.
LPC: Booting and systemd Posted Sep 16, 2011 14:38 UTC (Fri) by Cato (subscriber, #7643) [Link]
GRUB2 does support LVM, but I prefer to always use a non-LVM /boot partition. In fact, if everyone used boring filesystems such as ext3 for /boot, there would be no need for exotic filesystems in GRUB at all. Since /boot is small, slow changing and rarely needs resizing, I can't see the point of anything beyond ext3.
LPC: Booting and systemd Posted Sep 19, 2011 9:33 UTC (Mon) by epa (subscriber, #39769) [Link]
The difficulty is in having a separate /boot at all. You must allocate a fixed amount of space which is either too little or too much. With a 500 gigabyte disk it doesn't matter but on a netbook with a four gigabyte SSD it is painful to lose 10% of it to /boot.
Earlier Fedora releases gave about a hundred megs to /boot but then cannot be upgraded to the latest Fedora version, since the upgrade process needs to put a disk image in there too. (There is a way to download the disk image over the network but for me it always hangs.)
LPC: Booting and systemd Posted Sep 20, 2011 9:56 UTC (Tue) by Cato (subscriber, #7643) [Link]
If your only disk is a 4GB SSD on a notebook, don't use a separate /boot - just use ext3. You probably won't need LVM either.
LPC: Booting and systemd Posted Sep 20, 2011 16:06 UTC (Tue) by mathstuf (subscriber, #69389) [Link]
When I had my 4GB SSD netbook, I did something like a 70MB ext2 /boot, 2GB /, 512MB of swap, and the rest for /home. If everything were /, I would have to format anyways for an upgrade (not enough space for the RPMs to upgrade with[1]). I also remember doing lvresize and other fun things to go from a 2GB /home to a 2GB / instead. Haven't used LVM since.
[1]I actually did do a yum upgrade (from F10 to F11 IIRC) on the machine. The RPMs fit, but not with the upgrade going. I ended up having to SIGSTOP yum, delete cached RPMs that had finished installing for disk space, and the SIGCONT yum again. Not something I plan on doing again. Especially during class.
LPC: Booting and systemd Posted Sep 15, 2011 18:06 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
I much prefer fixing and troubleshooting lilo boot problems compared to grub boot problems
yes, it's easier to trigger lilo problems, but when grub doesn't just 'do the right thing', figuring out how to fix it seems to be much harder.
LPC: Booting and systemd Posted Sep 16, 2011 17:19 UTC (Fri) by jmorris42 (subscriber, #2203) [Link]
> If you've never seen a system with a blank screen except for
> "LI" then you've not been using Linux very long!
Well what is old is now new again. GRUB2 requires running an installer after any change, such as installing a newly built kernel. Forget that step and kaboom! Well you get the old config with no mention of the newly installed kernel if you weren't so unwise as to get rid of the current running kernel before rebooting but we still went backward with GRUB2.
LPC: Booting and systemd Posted Sep 16, 2011 17:34 UTC (Fri) by jrn (subscriber, #64214) [Link]
> GRUB2 requires running an installer after any change, such as installing a newly built kernel. Forget that step and kaboom!
Forget that step and you have to type the name of the kernel by hand, you mean, right?
LPC: Booting and systemd Posted Sep 22, 2011 22:29 UTC (Thu) by Wol (guest, #4433) [Link]
Does Grub2 do USB?
Many mobos do not do proper USB->PS2 emulation (some don't do it at all) so if all you have is a usb keyboard, you're stuffed. You can't tell grub which option you want so you get the choice of default, default or default. Tough luck if your upgrade broke but you made that the default in order to test it ...
For example, my mobo is broken some of the time - kernel upgrades are a pain because I never know whether my keyboard is going to work with grub or not :-(
Cheers,
LPC: Booting and systemd Posted Sep 17, 2011 0:20 UTC (Sat) by giraffedata (subscriber, #1954) [Link] Maybe we should just go back to LILO. Why boot an intermediate kernel with some added complexity if you can just boot the real one, instead. Because you'd like to have a choice at boot time of kernels and kernel parameters. Hence the intermediate program, be it LILO, GRUB, or Linux. If you really don't want that boot-time choice, then you should step back beyond LILO to the system that simply loads the first N blocks from the disk and branches to it. That can be your Linux boot image, with built-in parameters. Even LILO is dependent on Linux filesystem design more than is desirable. It assumes a file is simply the content of a sequence of blocks, and that that sequence is static. A modern filesystem should not be bound to that.
LPC: Booting and systemd Posted Sep 18, 2011 17:14 UTC (Sun) by raven667 (subscriber, #5198) [Link]
I suppose EFI systems don't have a way to pass parameters to the kernel, otherwise on newer systems there would seem to be less need for a separate bootloader at all. Presuming that EFI can't pass parameters (or an initrd) that seems like a missed opportunity for the Linux community to get native booting into the standard. Sometimes it seems like linux kernel developers don't participate in the right vendor clubs to influence the design of hardware and standards and end up needing to conform after the fact.
I'm just kind of talking out of my rear end here so maybe it's not like that at all but that's the sense that I get sometimes.
I wonder if grub EFI is an EFI loadable module or a more traditional x86 bootloader, something like that could have just been specified in the standard such that EFI could natively boot Win*, Linux, *BSD, etc. on common filesystems without any further installs or intermediaries. That would probably require compromise on the design which is always hard to get.
LPC: Booting and systemd Posted Sep 18, 2011 18:26 UTC (Sun) by giraffedata (subscriber, #1954) [Link] But there's a reason for all the layers involved in bringing up a system. Each one has a different tradeoff of simplicity and stability versus flexibility, each one has a separate dependence on other components of the system, and so on.One could squeeze the GRUB and EFI layers into one, but look what you'd lose: Today, if I want to start determining kernel parameters in a new way, I can just update GRUB on my boot disk. If I mess it up so the system won't boot, that's OK - I can just tell EFI to boot from my backup boot disk (maybe a rescue CD) and fix it. But if all that parameter stuff was in EFI, I would have to flash a new EFI onto the motherboard, which isn't as easy. And if I screw it up, I might have a brick. We can argue forever on how many layers are optimal, and what should go in each one (I'm hearing more and more opinions that GRUB2 has features that would better reside at the Linux kernel layer), but it's clear that having lots of bootstrap layers can be useful.
LPC: Booting and systemd Posted Sep 18, 2011 20:06 UTC (Sun) by raven667 (subscriber, #5198) [Link]
That seems like a perfectly reasonable trade-off. As a practical matter, how often does the kernel interface have incompatible changes such that forces the need for a new bootloader. EFI and GRUB can already just load an arbitrary boot sector if you want a layered approach but from what little experience I have with EFI (just started working with it last week) it seems nearly capable enough.
Interestingly enough, elsewhere in LWN was a report of progress in making a linux kernel image that is directly bootable from EFI.
LPC: Booting and systemd Posted Sep 18, 2011 18:40 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
Right now the kernel isn't an EFI executable, so an additional bootloader is required in order to relocate it, set up the boot parameters structure, load an initrd if necessary and then jump to the kernel's entry point. There's ongoing work to make it possible to execute the kernel directly from EFI, with the command line arguments being provided directly. That's fine for the trivial case, but we'll still require a bootloader of some description if only to provide the user with their boot choices. While the EFI spec does support providing multiple boot choices that the user can select between, there's no specification for what the UI should look like. That's less than ideal.
LPC: Booting and systemd Posted Sep 18, 2011 20:11 UTC (Sun) by raven667 (subscriber, #5198) [Link]
That's something that goes back to my original point of encouraging more participation in vendor committees and whatnot by not just concerned vendors who use and fund linux but also independent groups like the Linux Foundation. EFI already seems pretty capable so getting the rest of the small number of additional features in the spec that would be needed to fully replace something like GRUB might be do-able if you can talk to the right people.
LPC: Booting and systemd Posted Sep 18, 2011 20:15 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
The spec isn't intended to provide UI, since that's something that's intended to integrate with the platform vendor's design. You could imagine some vendors being happy with a text-based menu with various boot options, but it doesn't seem plausible that, say, Sony would go for that over some sort of graphical UI.
In any case, EFI doesn't require that the firmware be able to read arbitrary filesystems. If you want to boot a kernel off LVM or btrfs or even ext2, you need a bootloader sitting in the EFI system partition.
LPC: Booting and systemd Posted Sep 18, 2011 20:36 UTC (Sun) by raven667 (subscriber, #5198) [Link]
At the risk of backseat designing, it seems that all that is really necessary is the ability to provide a list of labels and not specify how they are displayed. One would think that by default it would just load whatever is set to be the default with minimal prompting unless a key is hit. This is similar to how GRUB is usually set up and how I think Mac's work right now.
While it may be do-able to load modules for common filesystem types, as GRUB already does, so you can load kernels off them it seems more productive to be able to EFI boot the kernel directly and have the current and previous kernel images live on the EFI system partition. Basically make the EFI system partition replace the /boot directory.
LPC: Booting and systemd Posted Sep 18, 2011 21:39 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
There's no problem in configuring EFI to boot a kernel. The problem is in the UI that the firmware will expose to let you choose which kernel to boot or which boot arguments to pass. That's entirely non-standard, requires different keypresses on different hardware, looks different depending on a variety of circumstances and may not actually exist in any UI.
LPC: Booting and systemd Posted Sep 19, 2011 3:44 UTC (Mon) by raven667 (subscriber, #5198) [Link]
As long as it has the information and _can_ load a kernel with options and _can_ present a UI I don't think the actual UI needs to be standard. I would expect it to be branded by the hardware vendor for example. As long as there is a standard place to put kernel images and a standard way to add/remove labeled boot entries and if you can manually boot custom options using the EFI shell then I think that would solve the problem. I don't think the actual UI needs to be standardized beyond that.
LPC: Booting and systemd Posted Sep 15, 2011 15:06 UTC (Thu) by faramir (subscriber, #2327) [Link]
There is also kexec-loader
http://www.solemnwarning.net/kexec-loader/
which will fit on a floppy and can more or less read GRUB1 config files.
|
|||||||||||||