On 06/29/2012 05:04 PM, Mike Gilbert wrote:
> On Fri, Jun 29, 2012 at 4:56 PM, Richard Yao <ryao@gentoo.org> wrote:
>> On 06/29/2012 03:04 PM, Mike Gilbert wrote:
>>> On Fri, Jun 29, 2012 at 3:00 PM, Rich Freeman <rich0@gentoo.org> wrote:
>>>> On Fri, Jun 29, 2012 at 2:51 PM, Richard Yao <ryao@gentoo.org> wrote:
>>>>> GRUB2 does away with the conventional stage files. It also wants a
>>>>> special BIOS Boot Partition in order to function. That is where it
>>>>> stores the equivalent of the stage2 bootcode. That is similar to
>>>>> FreeBSD's bootloader.
>>>>
>>>> Now, that should make for a fun migration! Fortunately I do have a
>>>> separate boot already, and I guess I can be daring and overwrite it in
>>>> place and trust in grub2 to still find the kernel elsewhere.
>>>>
>>>> Those without a separate boot and without any free space are likely to
>>>> find this to be painful. Resizing partitions isn't exactly
>>>> risk-free...
>>>>
>>>> Rich
>>>>
>>>
>>> I think Richard is incorrect here; grub2 can live on any filesystem,
>>> so long as some combination of modules can access it.
>>>
>>
>> Do you know what function the BIOS Boot Partion serves? It is necessary
>> when using GRUB2's ZFS support. I was under the impression that it
>> stored boot code.
>>
>
> Based on a Google search I think "BIOS Boot Partition" is a GPT thing.
> Not relevent if you have an MBR partition table.
>
This is correct. I had forgotten that I switched to GPT on my systems
because ZFS partitions drives using GPT by default. Allowing people to
specify the partitioning without requiring them to do it manually is on
my to do list.
However, those who wish to use GPT on their systems will need a BIOS
Boot Partition to store the boot code. That will not apply to older
systems that are switching to GRUB2 unless they also change their
partition tables.
06-30-2012, 05:55 AM
Duncan
grub:2 keywords
Richard Yao posted on Fri, 29 Jun 2012 17:10:31 -0400 as excerpted:
> On 06/29/2012 05:04 PM, Mike Gilbert wrote:
>> On Fri, Jun 29, 2012 at 4:56 PM, Richard Yao <ryao@gentoo.org> wrote:
>>> On 06/29/2012 03:04 PM, Mike Gilbert wrote:
>>>> On Fri, Jun 29, 2012 at 3:00 PM, Rich Freeman <rich0@gentoo.org>
>>>> wrote:
>>>>> On Fri, Jun 29, 2012 at 2:51 PM, Richard Yao <ryao@gentoo.org>
>>>>> wrote:
>>>>>> GRUB2 does away with the conventional stage files. It also wants a
>>>>>> special BIOS Boot Partition in order to function. That is where it
>>>>>> stores the equivalent of the stage2 bootcode.
>>>>> Now, that should make for a fun migration! Fortunately I do have a
>>>>> separate boot already, and I guess I can be daring and overwrite it
>>>>> in place and trust in grub2 to still find the kernel elsewhere.
>>>>>
>>>>> Those without a separate boot and without any free space are likely
>>>>> to find this to be painful. Resizing partitions isn't exactly
>>>>> risk-free...
>>>> I think Richard is incorrect here; grub2 can live on any filesystem,
>>>> so long as some combination of modules can access it.
>>> Do you know what function the BIOS Boot Partion serves? It is
>>> necessary when using GRUB2's ZFS support. I was under the impression
>>> that it stored boot code.
>> Based on a Google search I think "BIOS Boot Partition" is a GPT thing.
>> Not relevent if you have an MBR partition table.
> This is correct. I had forgotten that I switched to GPT
Some brief detail to de-fuzz things slightly...
1) Existing MBR installations function much like grub1 in terms of where
the core, which replaces stage-1.5, goes. Like grub1, one of two
requirements must be met:
1a) Preferable: Some slack-space between the MBR and the first
partition. If this exists, grub2's core gets placed here, with the MBR
using an absolute address to it, much like grub1 did with its stage-1.5s
except that grub2's core is assembled from individual modules at install
time and is thus able to handle anything it has modules for (as long as
there's slack-space enough for the stack of necessary modules), including
mdraid, lvm2, etc.
1b) Fallback: If no slack-space exists between the MBR and the first
partition or if it's not enough, grub2 can install its core, much as
grub1 could install its stage-1.5s, into /boot. The disadvantage in both
cases is that again it's accessed via absolute-address from the mbr, and
if the filesystem moves it around, as journaling and COW-based
filesystems sometimes do, the data can move out from under that absolute
address, breaking the boot before even grub's rescue shell is available.
Thus, this is STRONGLY DISCOURAGED, but it's an option for those on old
systems, and it generally works as long as you're using an older /boot
filesystem like fat or ext2 that's not going to move the data around.
(1c: As with grub1 it's also possible to install grub to a partition
instead of to the entire disk. However, this is much more strongly
discouraged with grub2 than it was with grub1, I believe for much the
same reasons as with 1b.)
2) BIOS-based GPT, with a dedicated BIOS partition (typically ~128 KB or
so in size is fine), is definitely preferable to legacy MBR for grub2.
This is because grub2 makes use of the (bare-partition, no-filesystem)
dedicated BIOS partition to place its core in, something grub1 doesn't
do. With no filesystem and a special partition type dedicated by GPT for
this purpose, this is the strongest guarantee yet that the core will
remain undisturbed at the absolute address grub placed it at, and thus at
least the core rescue shell should always be available, even if something
happens to /boot (which is entirely separate from the reserved BIOS
partition.
If a user has planned well when they setup their GPT partitioning, this
reserved BIOS partition should be plenty large enough for all required
modules, even for stacked devices such as exotic filesystem on lvm on
mdraid.
3) For EFI-based GPT, there's another entirely separate special reserved
partition for the EFI system. According to the EFI spec, this must be
formatted FAT32, and should be 256 MB or so. I don't have an EFI system
so have skipped much of the grub2 documentation on this so far and thus
don't know a whole lot about it.
Again, if a user has planned well when setting up their GPT, they may
actually have both an EFI partition and a BIOS partition (as I do here),
tho only one will likely be in use. But having both in the gpt layout
does allow migrating the disk from a legacy BIOS system to a newer EFI
system when the time comes, without re-gdisking (fdisking for gpt).
Meanwhile, for those who didn't know yet, it's worth noting that with GPT
there's no primary/logical partition division, they're all the same, and
there's room for upto 128 partition entries in the standard GPT, tho a
larger one is possible if needed. Additionally, there's two copies of
the partition table and they're checksummed, making them MUCH more
reliable than the old MBR scheme. AND, gpt allows direct partition
names, much like filesystem labels, udev maps them (tho for some reason
it doesn't seem to map those on mdraid devices last I checked), and mount
can mount by partition name using udev in much the same way as it mounts
by UUID or filesystem label.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
06-30-2012, 03:18 PM
Maxim Kammerer
grub:2 keywords
On Sat, Jun 30, 2012 at 8:55 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> 3) For EFI-based GPT, there's another entirely separate special reserved
> partition for the EFI system.
An EFI partition can reside on a disk with an MBR (legacy)
partitioning scheme, GPT scheme, El Torito CD-ROM boot entry, etc. For
MBR, 0xEF partition ID is used, and the same platform ID is used in El
Torito; GPT uses a corresponding GUID.
>*According to the EFI spec, this must be
> formatted FAT32,
No, the UEFI specification mandates that FAT12/16/32 EFI partitions
must be supported, but allows the firmware to support other
filesystems, with or without the 0xEF / GUID marker above.
On Fri, 29 Jun 2012 15:15:23 -0400
Rich Freeman <rich0@gentoo.org> wrote:
> On Fri, Jun 29, 2012 at 3:01 PM, Mike Gilbert <floppym@gentoo.org>
> wrote:
> > 3. grub2-install calls grub2-bios-setup which installs boot.img into
> > the MBR and embeds core.img into the sectors immediately after the
> > MBR.
>
> Ok, that isn't all that unlike grub1 - that is what stage1.5 is. It
> just sounds like these aren't static files that are copied out of
> /boot/grub, but rather they're built on-demand from other files there.
> Grub1 figures out which static stage1.5 you need based on where /boot
> is. They probably went to a more dynamic model so that they can
> support stuff like LVM+MD+LUKS+etc without having every permutation of
> static code. I'm not sure how smart the bootloader code ends up being
> - it wouldn't surprise me if at time of install the installer does all
> the work and just loads a simple bootloader on the diagnostic cylinder
> with just enough smarts to find /boot if it hasn't changed.
And if in this complex transition something goes wrong, we could opt
for the solution Ubuntu provided years ago, which was to add to the
grub1 boot loader configuration an entry which would call the grub2
boot loader, so that grub2's correct function could be ascertained
before the definitive switch to grub2 and removal of the grub1 code.
jer
07-02-2012, 07:02 PM
Mike Gilbert
grub:2 keywords
On Mon, Jul 2, 2012 at 2:57 PM, Jeroen Roovers <jer@gentoo.org> wrote:
> On Fri, 29 Jun 2012 15:15:23 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>
>> On Fri, Jun 29, 2012 at 3:01 PM, Mike Gilbert <floppym@gentoo.org>
>> wrote:
>> > 3. grub2-install calls grub2-bios-setup which installs boot.img into
>> > the MBR and embeds core.img into the sectors immediately after the
>> > MBR.
>>
>> Ok, that isn't all that unlike grub1 - that is what stage1.5 is. It
>> just sounds like these aren't static files that are copied out of
>> /boot/grub, but rather they're built on-demand from other files there.
>> Grub1 figures out which static stage1.5 you need based on where /boot
>> is. They probably went to a more dynamic model so that they can
>> support stuff like LVM+MD+LUKS+etc without having every permutation of
>> static code. I'm not sure how smart the bootloader code ends up being
>> - it wouldn't surprise me if at time of install the installer does all
>> the work and just loads a simple bootloader on the diagnostic cylinder
>> with just enough smarts to find /boot if it hasn't changed.
>
> And if in this complex transition something goes wrong, we could opt
> for the solution Ubuntu provided years ago, which was to add to the
> grub1 boot loader configuration an entry which would call the grub2
> boot loader, so that grub2's correct function could be ascertained
> before the definitive switch to grub2 and removal of the grub1 code.
>
That is exactly what Doug (cardoe) proposed, and he is working on the
docs for that.
07-03-2012, 02:20 PM
Jeroen Roovers
grub:2 keywords
On Mon, 2 Jul 2012 15:02:28 -0400
Mike Gilbert <floppym@gentoo.org> wrote:
> That is exactly what Doug (cardoe) proposed, and he is working on the
> docs for that.
>
Ah yes, it's been a long-winded thread.
jer
07-05-2012, 04:26 AM
Doug Goldstein
grub:2 keywords
On Tue, Jul 3, 2012 at 9:20 AM, Jeroen Roovers <jer@gentoo.org> wrote:
> On Mon, 2 Jul 2012 15:02:28 -0400
> Mike Gilbert <floppym@gentoo.org> wrote:
>
>> That is exactly what Doug (cardoe) proposed, and he is working on the
>> docs for that.
>>
>
> Ah yes, it's been a long-winded thread.
>
>
> jer
>
I got a little busier this past weekend than I had intended (loving
that leap second bug) but here's the first draft:
It will be integrated into the official Gentoo doc set once I get a
nod from the docs guys.
--
Doug Goldstein
07-05-2012, 07:29 AM
Hinnerk van Bruinehsen
grub:2 keywords
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05.07.2012 06:26, Doug Goldstein wrote:
> On Tue, Jul 3, 2012 at 9:20 AM, Jeroen Roovers <jer@gentoo.org>
> wrote:
>> On Mon, 2 Jul 2012 15:02:28 -0400 Mike Gilbert
>> <floppym@gentoo.org> wrote:
>>
>>> That is exactly what Doug (cardoe) proposed, and he is working
>>> on the docs for that.
>>>
>>
>> Ah yes, it's been a long-winded thread.
>>
>>
>> jer
>>
>
> I got a little busier this past weekend than I had intended
> (loving that leap second bug) but here's the first draft:
>
> http://dev.gentoo.org/~cardoe/docs/grub2-migration.xml
>
> It will be integrated into the official Gentoo doc set once I get
> a nod from the docs guys.
>
Hi,
according to my "/etc/grub.d/10_linux" grub2 (or better the
grub2-mkconfig script) searches for the following kernel names:
/vmlinuz-*, /boot/vmlinuz-* and /boot/kernel-* for x86 and x86_64 and
the same plus /vmlinux-* and /boot/vmlinux-* for other arches.
The accepted names for initrd/initramfs are: initrd.img-${version},
initrd-${version}.img, initrd-${version}.gz,initrd-${version},
initramfs-${version}.img, initrd.img-${alt_version},
initrd-${alt_version}.img, initrd-${alt_version},
initramfs-${alt_version}.img, initramfs-genkernel-${version},
initramfs-genkernel-${alt_version},
initramfs-genkernel-${GENKERNEL_ARCH}-${version} and
initramfs-genkernel-${GENKERNEL_ARCH}-${alt_version}.
I (as a user) would propose to reflect this . I would also give
information about /etc/defaults/grub since that is the config file
that you need to enable persistent, customized kernel options (will be
automatically appended when you run grub2-mkconfig) and grub specific
options like the timeout or the graphic settings.
Thank you for your effort. I really look forward for grub2 becoming
the "default" (whatever that is in gentoo ) option.
WKR
Hinnerk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
grub:2 keywords
) option.
