Recent Features
| |||||||||||||
Congratulations!Congratulations!Posted Jun 29, 2012 11:24 UTC (Fri) by alankila (subscriber, #47141)In reply to: Congratulations! by proski Parent article: GRUB 2.00 released
Imho its ability to read filesystems is also sort of its downfall. It would have more sense to just leave some 100 MB unpartitioned space at start of every disk with grub installed and use some unspecified but grub-known format for files written there. Perhaps the filesystem could be designed to be good enough to be mounted as /boot, but I wouldn't care if it isn't...
LILO's great problem was that if you touched your kernel or initramfs files in any way, you got unbootable system, because the location of files changed and not enough effort was spent protecting these files such as marking them immutable to avoid accidentally constructing nonbootable system.
GRUB 1/2 requires generating the config file for the installed kernel suite, and also adds the twist that the filesystem needs to be readable to the boot loader (which used to be a problem for XFS and BTRFS, though not anymore). That both XFS and BTRFS work now is great, but I imagine it's always going to be playing catch-up, so I question the sense this design makes.
(Log in to post comments)
Congratulations! Posted Jun 29, 2012 12:11 UTC (Fri) by hawk (subscriber, #3195) [Link]
Why should it invent its own filesystem?
As grub already supports a bunch of commonly used filesystems it's easy enough to do essentially what you suggest would be done if there was a special "grubfs"; just create a small /boot filesystem that is of a type that grub does support and use whatever filesystem(s) you want for everything else.
Congratulations! Posted Jun 29, 2012 13:17 UTC (Fri) by alankila (subscriber, #47141) [Link]
I simply said that the filesystem is unspecified. Whether it's a real one or not doesn't matter to me. The reason why I would like to make it special and hide it from the OS is to reduce the complexity of the program and improve its reliability especially when facing future changes.
An approximation of this design is separate /boot, but IMHO the fundamentally bad idea which opened the whole can of worms is that grub reads ANY mountable filesystem, even if the filesystem was as simple as VFAT. But I understand defending this version of the argument is very difficult, and anyway all the effort has already been expended in getting every filesystem's every version work as well as possible. We might just as well roll with it, but in my opinion there is a lesson here, which says "We should not expect boatloaders to be as good as our operating systems when dealing with filesystems and hardware". Or something along the lines.
After all, people seriously thought about using a Linux kernel just to load another Linux kernel. I'm sure there's a yo dawg joke here somewhere.
Congratulations! Posted Jun 29, 2012 13:23 UTC (Fri) by joey (subscriber, #328) [Link]
Grub's filesystem support is entirely read-only. This makes it much simpler than actual linux filesystem implementations. We use grub2 in os-prober to probe the contents of all available filesystems, while avoiding modifying them; something the kernel's filesystem code often cannot do.
Congratulations! Posted Jun 29, 2012 13:28 UTC (Fri) by alankila (subscriber, #47141) [Link]
Yes, and it took long time until XFS and BTRFS could be used with GRUB.
Whether the code is simpler or not doesn't matter, the fact the code needs to exist is what I call into question.
Congratulations! Posted Jun 29, 2012 13:38 UTC (Fri) by hummassa (subscriber, #307) [Link]
Why would anyone use a sofisticated, journalling FS for /boot ???
/boot = ext2
Congratulations! Posted Jun 29, 2012 13:56 UTC (Fri) by alankila (subscriber, #47141) [Link]
Who has a separate /boot. One uses whatever filesystem one wants. The fact that GRUB is supposed to just work tends to make this the default setup. Then one gets dark warnings about how XFS might not work if the file was only written to journal and XFS did not get around to flushing the journal to disk. The illusion breaks.
I have RAID1 setups for most servers and there also GRUB is inconvenience, although it's still possible to make it work. In the past it used to flat-out fail trying to grok how the RAID is set up, probably because of reasons that don't directly relate to GRUB but to the os-prober. But if you now say "So why put /boot in the RAID? Just mount a partition on the disk separately", I say "But I have 2 disks in my RAID1. How can I mount /boot twice and have the files appear in both disk's copies when a new kernel is installed by my distro's package?"
If we had a separate 100 MB region set aside and understood by GRUB, it doesn't matter what RAID we have, GRUB scripts could be easily written to see that you have N disks, and to install the kernels on all the drives in such a way that it doesn't matter which one of them fails, and all of them can get a kernel up and going because everything is duplicated on all the drives.
The question here is not how to engineer around the issue using the design we have (separate /boot, ext2 filesystems, using RAID1 for /boot and say RAID5 for /), the question is that the design picked by boot loader implies that it needs to have almost the same capability as fully booted kernel. And that, IMHO, was a stupid choice.
Congratulations! Posted Jun 29, 2012 15:14 UTC (Fri) by mikemol (subscriber, #83507) [Link]
I have a separate boot. I'm certainly not the only one; there is still running hardware out there where the BIOS can only access a small fraction of the disk. This was made worse by the explosion in disk sizes over the ten years. If you don't use a separate /boot, you need to get lucky and hope that your GRUB1.x stage 1.5 (and 2?) are within the range BIOS can directly access.
As for the design picked by the bootloader: The filesystem drivers are modular. I expect that, if you wanted to, you could fairly trivially write a GRUB-specific filesystem driver. Heck, it could have a hardcoded table of files, with a hardcoded set of offsets at which to find them. Or it could look for a table of such values stored in a block of records at a known place...but now we're on our way to reinventing FAT.
I think you're confusing the full capability set of the Linux Kernel with the relatively meager capabilities required to understand filesystems.
Congratulations! Posted Jun 29, 2012 16:36 UTC (Fri) by alankila (subscriber, #47141) [Link]
What I'm frustrated at is that the thing doesn't work.
With the qualifying statement that it can be made to work, if you just spend enough time.
With the wishful thinking that it could just work properly every time regardless of filesystem and RAID if it had been done differently.
I've aired enough complaints for one thread by now.
Congratulations! Posted Jun 29, 2012 19:07 UTC (Fri) by khim (subscriber, #9252) [Link] With the wishful thinking that it could just work properly every time regardless of filesystem and RAID if it had been done differently. Except it can't. If you have dual-boot Linux/Windows system then often the only way to make the whole thing happy is to install Grub on Windows-provided NTFS partition and add it to Windows menu (search GRUB2DOS in Google for details). Now, this is obviously a PITA (why some versions of Windows kill MBR after each boot is good question) - but it works. You scheme will fall apart. And it's not obvious to me that software RAID users outnumber dual-boot systems users.
Congratulations! Posted Jul 2, 2012 13:48 UTC (Mon) by alankila (subscriber, #47141) [Link]
Let's just say that when I make a dedicated linux installation I expect to be able to use filesystem of my choice and (software) RAID solution of my choice without running into all sorts of crazy issues. I could not care less about the people who play with fire and install Linux on the same harddisk with some operating system, although I realize that it is an important use case for some people. I just think harddisks are cheap and worth the investment to avoid the need to deal with this fundamentally risky configuration where multiple operating systems are expected to cooperate one way or other.
My personal experience with GRUB has been one of long frustration because it has taken so long before it started to work properly. But hey! It wasn't a .0 release before either, so maybe I was wrong to expect it to just work. Then again, I heard a wise man say "optimism kills". I expect to run into trouble as soon as I deviate one bit from what the average person is doing.
Congratulations! Posted Jul 2, 2012 9:34 UTC (Mon) by rodgerd (guest, #58896) [Link]
Some of us like to, say, RAID our /boot drives. Which GRUB didn't handle because it had to re-implement RAID. Some of us have learned through bitter experience that LVMs have their use for boot volumes, as well. Again, GRUB has had problems with that.
Congratulations! Posted Jun 29, 2012 12:23 UTC (Fri) by slashdot (guest, #22014) [Link]
What happened to using a Linux kernel as the bootloader?
That's possible right now and would avoid duplicating all the drivers, but it seems to never have gotten popular for some reason.
Congratulations! Posted Jun 29, 2012 12:49 UTC (Fri) by cortana (subscriber, #24596) [Link]
On my system, GRUB's core image (that is, GRUB itself + enough modules to allow it to read files (configuration, additional modules, kernel, initrd) from /boot comes to 26 KiB.
If you have a hard disk using MBR, this image would be embedded in the gap between the end of the MBR and the start of the first partition. With a typical layout, the this is normally only 31 KiB. Could a minimal kernel be built to fit into such a small space?
If you're using GPT then things are easier: the conventional gap before the first sector disappears entirely, and is replaced by a dedicated partition for the boot loader (misnamed the "BIOS Boot Partition" in GRUB's case). This partition can be of any size, so you can build as complex a kernel/rescue system as you like as a "boot loader"...
Congratulations! Posted Jun 29, 2012 13:48 UTC (Fri) by joib (guest, #8541) [Link]
The "typical layout" these days is to put the start of the first partition at 1 MB (sector 2048). IIRC Windows has done that since XP, and within the last few years Linux distros have started doing the same in order to get correct alignment for 4K drives (and SSD's?).
Congratulations! Posted Jun 29, 2012 14:12 UTC (Fri) by cortana (subscriber, #24596) [Link] I think GRUB's decision to use a dedicated partition was borne of past experience--for example, some DRM software happily assumes it's OK to scribble over sectors in the gap... since partitions are not as scare a resource with GPT as their were with MBR, the balance is tipped in favour of having a dedicated partition to prevent this kind of thing happening again.
Congratulations! Posted Jun 29, 2012 19:13 UTC (Fri) by blitzkrieg3 (subscriber, #57873) [Link]
No way has windows done that since XP. There are a million articles out there that state that XP is not 4k aligned. Probably vista or some such.
Congratulations! Posted Jun 30, 2012 18:10 UTC (Sat) by elanthis (guest, #6227) [Link]
Indeed, XP installs to sector 63 by default. An article on LWN going over some of the history, and the problems XP's assumptions imposed: http://lwn.net/Articles/377895/
Congratulations! Posted Jun 29, 2012 15:24 UTC (Fri) by raven667 (subscriber, #5198) [Link]
> Imho its ability to read filesystems is also sort of its downfall. It would have more sense to just leave some 100 MB unpartitioned space at start of every disk with grub installed and use some unspecified but grub-known format for files written there. Perhaps the filesystem could be designed to be good enough to be mounted as /boot, but I wouldn't care if it isn't...
I think there is some confusion because I don't see how that is any different than how things currently work with /boot partitions for grub to read.
|
|||||||||||||