Re: [gentoo-dev] Re: grub:2 keywords
On Sat, Jun 30, 2012 at 8:55 AM, Duncan 1i5t5.dun...@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. and should be 256 MB or so. No such requirement. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
[gentoo-dev] Re: 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 r...@gentoo.org wrote: On 06/29/2012 03:04 PM, Mike Gilbert wrote: On Fri, Jun 29, 2012 at 3:00 PM, Rich Freeman ri...@gentoo.org wrote: On Fri, Jun 29, 2012 at 2:51 PM, Richard Yao r...@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
Re: [gentoo-dev] Re: grub:2 keywords
On Tuesday 26 June 2012 00:04:35 Duncan wrote: Mike Gilbert posted on Mon, 25 Jun 2012 23:13:09 -0400 as excerpted: Profiles do not set a default bootloader so I have no idea what you are talking about. I could have sworn there was a virtual/bootloader or some such, that was a part of @system and that thus would have likely had a default in the profiles packages file, but either there was but it's long gone, or I'm mis-remembering entirely. long gone when we threw out old style virtuals -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: grub:2 keywords
Mike Frysinger posted on Fri, 29 Jun 2012 01:12:38 -0400 as excerpted: On Tuesday 26 June 2012 00:04:35 Duncan wrote: I could have sworn there was a virtual/bootloader or some such, that was a part of @system and that thus would have likely had a default in the profiles packages file, but either there was but it's long gone, or I'm mis-remembering entirely. long gone when we threw out old style virtuals -mike Thanks. I'm /not/ going senile and remembering things that were never there, then! Relief! =:^) -- 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
[gentoo-dev] Re: grub:2 keywords
Mike Gilbert posted on Mon, 25 Jun 2012 12:56:25 -0400 as excerpted: On Mon, Jun 25, 2012 at 11:19 AM, Doug Goldstein car...@gentoo.org wrote: Since Grub Legacy and Grub 2 are slotted, Portage won't remove the older version. Even if it removes the older one, everything necessary is installed into /boot and the MBR already. Portage will remove the older slot the next time the user runs emerge --depclean unless sys-boot/grub:0 is added to the world file. I'm looking for a good way to communicate this to the user. How about this: For ~arch, we do an ewarn in pkg_postinst if grub:0 is installed. For stable, we do a news item. Here's a bit of a different idea: Changing the bootloader is really a profile level change. If appropriate grub2-defaulted new profiles are created, and the old ones set to specify grub:0 as their default bootloader and then deprecated, this will automatically both provide the appropriate upgrade preparation required hint, and allow users to upgrade on their own schedule during the usual profile deprecation period. Additionally, if there are continued issues with gcc building the old grub, etc (as was complicating the gcc-4.6 upgrade), the old profile can be set to mask new gcc, as well, thus providing additional encouragement to upgrade for the new gcc, and allowing people to deal with that upgrade at the same time, with their profile switch. As such, supporting the old profiles during the deprecation period shouldn't be too bad, since slots, version-ranges, etc, can be nailed down as necessary, and people will automatically be prepared to deal with a bit of churn as they do their profile upgrade. Thinking back, that probably would have been the best way to handle the baselayout-2/openrc upgrade as well, but that's rather behind us, now. -- 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
Re: [gentoo-dev] Re: grub:2 keywords
On Mon, Jun 25, 2012 at 10:43 PM, Duncan 1i5t5.dun...@cox.net wrote: Mike Gilbert posted on Mon, 25 Jun 2012 12:56:25 -0400 as excerpted: On Mon, Jun 25, 2012 at 11:19 AM, Doug Goldstein car...@gentoo.org wrote: Since Grub Legacy and Grub 2 are slotted, Portage won't remove the older version. Even if it removes the older one, everything necessary is installed into /boot and the MBR already. Portage will remove the older slot the next time the user runs emerge --depclean unless sys-boot/grub:0 is added to the world file. I'm looking for a good way to communicate this to the user. How about this: For ~arch, we do an ewarn in pkg_postinst if grub:0 is installed. For stable, we do a news item. Here's a bit of a different idea: Changing the bootloader is really a profile level change. If appropriate grub2-defaulted new profiles are created, and the old ones set to specify grub:0 as their default bootloader and then deprecated, this will automatically both provide the appropriate upgrade preparation required hint, and allow users to upgrade on their own schedule during the usual profile deprecation period. Profiles do not set a default bootloader so I have no idea what you are talking about. Installing grub:2 does not replace grub:0 until the user actually runs grub2-install, so you can already upgrade on your own schedule.
Re: [gentoo-dev] Re: grub:2 keywords
On Tue, 26 Jun 2012 02:43:47 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Mike Gilbert posted on Mon, 25 Jun 2012 12:56:25 -0400 as excerpted: On Mon, Jun 25, 2012 at 11:19 AM, Doug Goldstein car...@gentoo.org wrote: Since Grub Legacy and Grub 2 are slotted, Portage won't remove the older version. Even if it removes the older one, everything necessary is installed into /boot and the MBR already. Portage will remove the older slot the next time the user runs emerge --depclean unless sys-boot/grub:0 is added to the world file. I'm looking for a good way to communicate this to the user. How about this: For ~arch, we do an ewarn in pkg_postinst if grub:0 is installed. For stable, we do a news item. Here's a bit of a different idea: Changing the bootloader is really a profile level change. If appropriate grub2-defaulted new profiles are created, and the old ones set to specify grub:0 as their default bootloader and then deprecated, this will automatically both provide the appropriate upgrade preparation required hint, and allow users to upgrade on their own schedule during the usual profile deprecation period. No-no-no. I don't want profiles suddenly installing grub on my system. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: grub:2 keywords
Mike Gilbert posted on Mon, 25 Jun 2012 23:13:09 -0400 as excerpted: Profiles do not set a default bootloader so I have no idea what you are talking about. I could have sworn there was a virtual/bootloader or some such, that was a part of @system and that thus would have likely had a default in the profiles packages file, but either there was but it's long gone, or I'm mis-remembering entirely. So, ummm... interesting idea, but never mind! -- 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
