From: Hollis Blanchard <hollisb@us.ibm.com>
To: Pavel Roskin <proski@gnu.org>
Cc: The development of GRUB 2 <grub-devel@gnu.org>,
Carlos Roberto do Nascimento Costa <crncosta@linux.vnet.ibm.com>,
Manoel <mrabran@linux.vnet.ibm.com>
Subject: Re: PPC64
Date: Thu, 23 Oct 2008 10:06:49 -0500 [thread overview]
Message-ID: <1224774409.16720.22.camel@localhost.localdomain> (raw)
In-Reply-To: <20081023012558.mlk1yefps0ws4k4c-cebfxv@webmail.spamcop.net>
On Thu, 2008-10-23 at 01:25 -0400, Pavel Roskin wrote:
> Quoting Hollis Blanchard <hollisb@us.ibm.com>:
> > On IBM POWER servers, there is no HFS partition at all. Instead, there
> > is a "raw" partition onto which you dd an ELF file. Firmware loads the
> > whole thing into memory and jumps at offset 0. Traditionally, yaboot is
> > installed there, and when it runs it does a shoddy job of trying to walk
> > the (DOS) partition table, searching for /etc/yaboot.conf.
> >
> > Once GRUB replaces yaboot/ybin we can happily wave both of these
> > anachronisms goodbye. Firmware on both systems is fully capable of
> > loading ELF files from a filesystem, and since it's on a filesystem
> > there is no need to embed anything or search anywhere: all files
> > (grub.cfg and the modules) should be placed adjacent to the executable.
>
> Actually, I would prefer all files that don't have to be on HFS or on
> the raw partition to be on the native partition, so that they can be
> easily accessed. That includes grub.cfg.
FWIW, I ran for years with an HFS partition "natively" mounted
on /boot/grub, and I never experienced any instability. Do you have
reason (other than hearsay) to mistrust the Linux HFS driver?
> > As for embedding the path in the executable itself, that's a nice idea
> > until you copy the executable to another system or move your hard disk
> > to another system where devices have different Open Firmware paths and
> > aliases. Another big pain point is building bootable CDs, since these
> > also unfortunately cannot make assumptions about the Open Firmware
> > devices available.
>
> We can use UUIDs now. That should alleviate most issues.
Agreed.
> > Just put all the files in the same directory on a real filesystem and be
> > happy. I know I am. :)
>
> I'm afraid I'm missing something.
>
> Anyway, I think it's too much to ask from users to change the existing
> partitioning or mount points. GRUB can be more compatible with both
> its i386 implementation and with yaboot by keeping modules in
> /boot/grub on ext2 or another native filesystem and placing the
> minimal core to the machine specific boot partition (whether it's HFS
> or raw or something else).
Actually I don't remember if I had to change the partitioning scheme at
all: isn't GRUB + modules small enough to fit into the typical "ybin
boot partition"?
I don't think asking the user to add an entry to /etc/fstab is an
onerous restriction. After all, they are trying to replace their
distribution's bootloader in the first place, so they almost certainly
have some familiarity with the boot process. Once distributions use
GRUB2 of course, no user intervention would be required.
My basic point is that requiring grub-install and this mystical "hidden
partition in the mist" is just silly. It's completely unnecessary on
systems with filesystem support in firmware, and it's silly to
artificially limit those systems by imposing historical x86 restrictions
onto them.
--
Hollis Blanchard
IBM Linux Technology Center
next prev parent reply other threads:[~2008-10-23 15:11 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-21 20:52 PPC64 Hollis Blanchard
2008-10-21 22:04 ` PPC64 Pavel Roskin
2008-10-21 22:40 ` PPC64 Hollis Blanchard
2008-10-23 5:25 ` PPC64 Pavel Roskin
2008-10-23 15:06 ` Hollis Blanchard [this message]
2008-10-23 16:52 ` PPC64 Pavel Roskin
2008-10-23 18:00 ` PPC64 Manoel
2008-10-23 19:08 ` PPC64 Hollis Blanchard
2008-10-24 12:10 ` PPC64 Manoel
2008-10-24 14:51 ` PPC64 Hollis Blanchard
2008-10-24 21:53 ` PPC64 Manoel
2008-10-27 17:19 ` PPC64 Pavel Roskin
2008-11-04 16:05 ` PPC64 Manoel
2008-11-04 16:12 ` PPC64 Hollis Blanchard
2008-11-04 18:18 ` PPC64 mlongcall gcc flag Manoel
2008-11-04 18:21 ` Manoel
2008-11-04 19:16 ` Robert Millan
2008-11-04 23:48 ` Pavel Roskin
2008-11-05 9:43 ` Robert Millan
2008-11-05 15:35 ` Pavel Roskin
2008-11-05 17:25 ` Hollis Blanchard
2008-11-05 19:27 ` Manoel
2008-11-06 15:12 ` Robert Millan
2008-11-06 17:42 ` Manoel
-- strict thread matches above, loose matches on Subject: below --
2008-10-27 8:04 PPC64 rubisher
2008-10-20 19:18 PPC64 Manoel
2008-10-20 19:32 ` PPC64 Hollis Blanchard
2008-10-21 16:43 ` PPC64 Manoel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1224774409.16720.22.camel@localhost.localdomain \
--to=hollisb@us.ibm.com \
--cc=crncosta@linux.vnet.ibm.com \
--cc=grub-devel@gnu.org \
--cc=mrabran@linux.vnet.ibm.com \
--cc=proski@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.