[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: partition layouts - separate /boot

From: Hollis Blanchard
Subject: Re: partition layouts - separate /boot
Date: Tue, 5 Apr 2005 10:47:41 -0500

On Apr 4, 2005, at 11:55 PM, Vernon Mauery wrote:

Hollis Blanchard wrote:
I've been thinking about how to install grub2 on an Open Firmware
system. Here's one possibility:
    /boot -- Linux-native filesystem (e.g. ext3)
        holds kernels, initrd, etc
    /boot/grub -- firmware-native filesystem (on Mac HFS+, on others
FAT, etc)
        holds grub executable, grub.cfg, modules

The grub ELF file must live on a firmware-native filesystem. When run,
it can find out what partition it was booted from, so that is a natural place to load grub.cfg from as well (and why not modules while we're at it?). Thus this is the value of the "prefix" GRUB environment variable.

Putting a restraint that says /boot/grub must be a separate partition doesn't sound like a good idea. It just clutters the partition table with another small partition.

If all it gains us is that we know where we booted from, we still need to know where /boot is. I don't see what this gains us -- the root command or prefix variable is still required. It sounds to me that if you want to have a firmware native partition type, having all of /boot be that type would be preferred.

I know there is at least one version of IBM Open Firmware which has a 4GB limit on disk reads. Creating a separate partition is the only way I know of to keep a filesystem from locating blocks above that 4GB limit.

You're correct: if we have /boot and /boot/grub partitions, we still need to know where /boot is. That's the heart of my question.

Haven't my arguments about trying to use FAT for /boot convinced you that using a firmware-native filesystem may not always be a good idea? To summarize, firmware-native filesystems:
- may not be well-tested (HFS)
- may not support expected features like symlinks or file permissions (FAT)
- may be less reliable, e.g. no journalling (FAT)
- may not support fsck, and wouldn't you like to fix filesystem corruption on /boot?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]