the GPT partition on i386 and adm64 as type=gpt, subtype=0 and with the
sname set to the UUID. This prevents sysinstall from bombing out. This
also makes sure the GPT partition shows up in sysinstall so as to avoid
accidental "clobberage".
PR: bin/72896
the chunk will never be added to the list in that case. Use type mbr
for GPT nested MBRs and use type part for any partition we don't know
or care about. Since the subtype is 0, this should not cause confusion.
addresses. For arch's with 64-bit longs, this is a nop, but for i386 this
allows sysinstall to properly handle disks and filesystems > 1 TB.
Changes from the original patch include:
- Use d_addr_t rather than inventing a blkcnt type based on int64_t.
- Use strtoimax() rather than strtoull() to parse d_addr_t's from config
files.
- Use intmax_t casts and %jd rather than %llu to printf d_addr_t values.
Tested on: i386
Tested by: kuriyama
Submitted by: julian
MFC after: 1 month
caller without closing the disk device and freeing allocated
memory. Not closing the disk device prevents GEOM from retasting
after spoiling.
Pointy hat: marcel
return an error value that made Write_Disk() abort. While on the
subject, improve the initialization of the error variable in read_gpt()
and update_gpt() even though nothing was broken there.
on whether the parent chunk is of type whole. This also applies to
MBR slices for non-GPT disks. Since most of the GPT handling is
conditionally compiled, do the same with the partition naming.
This fixes a braino that caused slices to be named as GPT partitions
and generally messing up an install.
Pointy hat: marcel
index referencing it. We need to know the original type and name
so that we know what to put in the table when we reconstruct it.
o Clear the table entries before we rebuild it to avoid that we
end up with stale data.
o Sequentially populate the table entries from the chunks. For the
chunks that have an index (now referencing the saved copy) we
use the saved type and name. This way we can handle unknown types
better. In all cases we update the start and end LBAs.
filling in the GPT entry. Both are already in sector numbers (LBA)
and exactly what we need for the entry. We now write a structurally
correct GPT partitioning.
part of the disk. The first appears to be a typo and instead of
dividing the media size with the sector size, we multiplied. The
second is an off-by-1 error that's the result of mixing up count
and index. The code in question is only applicable for virgin disks
and is used to create the "whole" chunk, which covers only the GPT
usable portion of the disk.
platforms except ia64 and use Int_Open_Disk() in open_ia64_disk.c
on ia64. We need to know more than GEOM can provide us so we're
forced to read from the disk. Move uuid_type() to open_ia64_disk.c
and remove all references on non-ia64.
o Pass the GEOM conftxt to Int_Open_Disk() so that only Open_Disk()
needs to know about GEOM and libdisk can more easily be used with
media not handled by GEOM.
o Create an ia64 specific definiton of struct disk on ia64, because
we don't need/have most of the fields other platforms need and
other fields not applicable on platforms other than ia64.
o Do not compile change.c on ia64. It's too PC specific.
o In Fixup_Names() in create_chunk.c, try all partition numbers
that are valid for the GPT disk. We have the total number of
partitions that can be allocated in the disk structure on ia64.
Also, use the GPT partition naming if we're creating one under
a chunk of type "whole". It's a GPT partition in that case.
o In Create_Chunk(), compile-out the PC specific code on ia64 that
checks BIOS geometry restrictions.
o In Debug_Disk() in disk.c, dump the ia64 specific fields.
o Save the partition index in the chunk on ia64 so that we can
preserve it when we write the data back to disk. This avoids that
partitions get moved around or swapped after installing FreeBSD,
which may render a disk unusable.
Cyl_Aligned(), Prev_Cyl_Aligned() and Next_Cyl_Aligned() into
tautologies on ia64. GPT removes all notion of tracks, heads and
sectors per track, so there are no alignment considerations.
