| |||||||||||||
Congratulations!Congratulations!Posted Jun 29, 2012 12:11 UTC (Fri) by hawk (subscriber, #3195)In reply to: Congratulations! by alankila Parent article: GRUB 2.00 released
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.
(Log in to post comments)
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.
|
|||||||||||||