Fedora tested in c't: grub missing feature

Thomas Bendler ml at bendler-net.de
Fri Feb 6 19:06:39 UTC 2009


On Thu, Feb 5, 2009 at 9:02 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:

> 2009/2/5 Thomas Bendler <ml at bendler-net.de>:
> > ??? You are not able to figure out what a root partition is and what a
> boot
> > partition is? The only thing you need is the root partition, the rest
> will
> > be in /etc/fstab. And to find out what a root partition is, is not really
> > complicated, all distributions will have a common set of directories in
> /,
> > if not, they are not detected, but for most of the distributions this
> will
> > work
> I know a lot of things.. that the software in my computer does not
> know. I'm smarter than my computer. You are smarter than your
> computer.   What I know about the state of my filesystem is in fact
> partly conceptualized in my human experience and not recoverable from
> a blank slate reading of the contents of the filesystem.


I know that there is a difference between a human view and a computer based
view on a problem ...

We are talking about teaching anaconda to know what I know in a
> consistent and fast algorithmic way. if it takes more time for
> anaconda to do it, by bruteforce disk searching of the filesystem
> layout, than it takes for someone to edit the grub config by
> hand...what the hell is the point. There's no win there.


... but you don't have to do a brute force thing. You only have to look at
the partition, check the filesystem type (guess that comercial UNIX flavors
don't use ext2/3/4, reiserfs, ...), check the directory layout for /boot,
/etc, /bin, /sbin, /lib, /var, ... and you are pretty sure it's something
Linux related. The next thing you need is /etc/fstab, /etc/lsb-release,
/etc/redhat-release, ... and some way to find out what kernel in /boot/ is
used for Grub or Lilo. That's it, not brute force, not an uncountable amount
of files. Simple checking of some assumptions and if they are true, add the
system to GRUB menu. The reason to do this is simply because it make life
easier. And yes, it is possible to do it manually, I can also manually
install the MBR. But the majority of users is not able to do this and will
never be able to do this. So why not adding this support to the installation
routine as other distributions also do. I don't talk about a hundred percent
solution, this is only a quick way to do this and to add at least most of
the distributions. The way to go is from my point of view the META data
approach in GRUB, but this will take some time until this is really usable.

If we are going to find an implementation that works then we need to
> think about it like a computer. We need to be dumb as dirt
> (technically sand as we still have silicon based hardware), we need to
> require explicit instructions...instead of making intuitive fuzzy
> leaps of logic that involve heuristic parsing that relies on apriori
> situational knowledge.


I know, I'm not only a system administrator, partly I'm also a programmer.
But I think it could be done without much effort (as I described above).


> I hand you a harddrive, I tell you it has 15 partitions sitting on the
> disk, one of them is an ntfs partition and its the only partition
> flagged as bootable.  List the set of explicit instructions that
> detail how you would tell me find which of those partitions represent
> a distinct linux operating system and how to generate a working grub
> entry for each one of them.


Ok, short action list:

- Get partitions using parted, fdisk, whatever.
- Check for partition type (ext2/3/4, reiserfs, ...)
- Mount partitions that could be root file systems
- Check the directory layout for /boot, /etc, /bin, /sbin, /lib, /var, ...
(what should be on root is in FHS)
- Check /etc/fstab, /etc/lsb-release, /etc/redhat-release, ...
- Check lilo.conf or menu.lst
- Add the found resources to own GRUB menu.lst

This part could also be packaged by a separate RPM to be able to let it run
when the system is already installed but on another partition the kernel is
changed (i.e. by an upgrade). It could also be called by firstboot instead
of anaconda to make it more general usable. But, bottom line is, this is not
complicated nor rocket since, it's only a question of doing it.

Regards, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090206/65c60702/attachment.htm>


More information about the fedora-devel-list mailing list