> On Oct 24, 2014, at 21:45, Bruce Dubbs <[email protected]> wrote: > > Ken Moffat wrote: >> On Fri, Oct 24, 2014 at 06:08:56PM -0500, Bruce Dubbs wrote: >>> Dan McGhee wrote: >>>> I started this thread so that I wouldn’t hijack my own over on -dev. >>>> >>> >>> “...set up a new system based on UEFI and GPT. Our new system will dual >>> boot: it will work with both UEFI and BIOS firmware. “ The disk created >>> was 10GB. >>>> >>>> I am not able to “copy and paste” the partition table after the >>> exercise from running <parted -l>. So I will attempt to recreate the table: >>> >>>> Number Start End Size Code Name >>>> 1 2048 411647 200.MiB EF00 EFI System >>>> 2 34 2047 1007.0 KiB EF02 BIOS boot partition >>>> 3 411648 821247 200.0 MiB 8300 Linux /boot filesystem >>>> 4 821248 20971486 200.0 MiB 8300 Linux /root filesystem >>>> >>>> I hope that table comes through holding the formatting. >>> >>> Not quite. I reformatted a bit by removing tabs/spaces. >>> >>> However, I think the format of the disk above is poor. The partitions are >>> out of order. 1 and 2 are reversed. Also, the BIOS boot partition is not >>> aligned on a 1MiB boundary. On a modern disk, is the loss of 1007.0 KiB >>> really important? That's less than a floppy disk. >>> >>> When you copied, the size of partition 4 is way off. Should be around 10G >>> by my calculation. >>> >>> No swap partition? Personally, I think a /home partition is always useful. >>> Change the system, but not user data. But that's really a different >>> discussion. >>>
This reduces to a problem when quoting a technical document in a venue such as this without being able to provide a link to or copy of that document. In choosing what to include here I omitted some things, which have, obviously, become important to the discussion. This exercise used the Arch Linux ISO liveCD in VirtualBox to install Arch Linux. The partitioning was done in preparation for that. So, most probably, the ARCH pacstrap utility takes care of the things you mentioned. There is a discussion on using gdisk, but here are the parted commands that wrote the partition table and made the partition: >> parted /dev/sda >> (parted) unit s >> (parted) mktable gpt >> (parted) mkpart primary 2048 411647 >> (parted) set 1 boot on >> (parted) name 1 “EFI System Partition” >> (parted) mkpart primary 34 2047 >> (parted) name 2 “BIOS Boot Partition” >> (parted) set 2 bios_grub on >> (parted) mkpart primary ext2 411648 821247 >> (parted) name 3 “Linux /boot filesystem” >> (parted) mkpart primary ext4 821248 20971486 >> (parted) name 4 “Linux /root filesystem” >> (parted) quit The article then goes on to say, “…GPT partitioning here, but MSDOS partitioning can be used instead if the disk is smaller than 2TiB. In that scenario, omit the BIOS boot partition and use *fdisk* to change the partition type of the EFI System Partition to 0xEF.” The exercise is to show the difference between BIOS and UEFI booting. >> >> Just a comment on the bios boot partition's alignment: I forget >> exactly how I set this up, and it is too late to look through my >> notes tonight, but gdisk on this machine shows: >> >> Disk /dev/sda: 976773168 sectors, 465.8 GiB >> Logical sector size: 512 bytes >> Disk identifier (GUID): D7E3F344-D44D-1E7E-40B5-479D3F1E4309 >> Partition table holds up to 128 entries >> First usable sector is 34, last usable sector is 976773134 >> Partitions will be aligned on 8-sector boundaries >> Total free space is 16072685 sectors (7.7 GiB) >> >> Number Start (sector) End (sector) Size Code Name >> 1 34 204833 100.0 MiB EF02 BIOS boot partition >> 2 204834 2301985 1024.0 MiB 0700 Linux/Windows data >> etc >> >> So to me, sector 34 for the bios boot partition looks correct >> (that's the one where grub lives, isn't it ?) > > Yes it is but 100M is *way* too big. Note that for disks with 4K sectors > with 512 byte sector emulation, sector 34 above does not align with the > physical sector. It's not really that big a deal because it's rarely written > and only read at boot time. > > See for instance > http://askubuntu.com/questions/201164/proper-alignment-of-partitions-on-an-advanced-format-hdd-using-parted > > <http://askubuntu.com/questions/201164/proper-alignment-of-partitions-on-an-advanced-format-hdd-using-parted> > > If it's done the same on all drives, then you don't need to worry about the > disk's physical format. > > I've found on a virtual system like qemu, if I create a new GPT with gdisk, > the first sector is created at sector 2048 by default, which is a good > standard to use everywhere. parted doesn't do it right by default and the > syntax is crazy. The reason for Sector 34 on a GPT disk is that a GPT disk can hold 128 partitions. Each partition record is 128 bytes long. With the information stored in each partition record, a GPT disk needs 16,384 bytes=32 sectors. Therefore, the first available sector is 34. Make things “pristine,” as alluded to in the ubuntu document, you could start the first partition at sector 40. I’ve discovered also that gdisk by default is aligned to "2048-sector boundaries,” and I agree that’s a good convention. Some people might call that “wasted space,” but it’s available to use for whatever reason. The 100M thing is probably true. I *think* it’s convention rather than standard. It needs be only large enough to hold a grub, in this case, image. > >> sda2 is /boot, the other partitions are whatever suits me. > > Right. > >> As it happens, I now use 15GB for each potential '/', (I like to >> keep old systems semi-usable, and to have multiple development >> systems, but *anybody* intending to use LFS long-term ought to have >> at least two potential '/' partitions). > > Right again. > >> To me, an example with only a single 10GB system for '/' is fine for >> a vm, but not a good thing to show as an example if people are going >> to be following it on real disks (repartitioning a real disk, even >> with good backups, is always a pain, and restoring the data is >> usually a slow job). > > True. I enjoy discussions like this. They help me cement what I already know, cause be to bolster what’s weak and provide areas for new knowledge. For the purposes of responding to the comment i received about my draft hint, the point is to be able to recognize, and created as necessary, what’s needed to boot LFS using grub in EFI mode on UEFI firmware. That’s a specific subset of what we have been discussing. Dan
-- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
