Bug #3369
open
installer fails to use entire disk: legacy BIOS, qemu, virtio_blk
0%
Description
Install fails to use entire disk and sets size to 8063MB.
For example, create a qemu image of 20GB and install. The resulting system disk is ~8GB in size, underutilizing the full 20GB. This bug manifests when:
1. performing qemu guest install
2. guest configured to use virtio_blk for qemu img that is installation target
3. qemu img is new (all zeros) and has not yet been partitioned
4. dfly installer legacy BIOS is selected
Workaround: repeat the select-disk after formatting for first time
1. select: Install DragonFly BSD
2. select: Legacy BIOS
3. select: vbd0
4. select: Use Entire Disk
5. select: RETURN TO SELECT DISK (instead of selecting file system) to repeat steps 1...4
Reduction: use fdisk to summarize the disk; the result must be as follows; specifically there must be no line beginning with /dev/vbd0 supplying disk geometry:
fdisk -s vbd0 fdisk: invalid fdisk partition table found fdisk: read_s0: Undefined error: 0
Anti-Reduction: bug will not manifest if fdisk shows any /dev/vbd0 disk geometry as follows:
fdisk -s vbd0 ... /dev/vbd1: 41610 cyl 16 hd 63 sec Part Start Size Type Flags ...
Files
Updated by mikdusan 11 months ago
- File fdisk-cyls.patch fdisk-cyls.patch added
Did some investigation. FreeBSD's fdisk does a better job determining disk geometry in this case.
To that end, I've attached a patch that calculates cylinders from `DIOCGPART` without using d_ncylinders field. The understanding is d_* fields are supplied by the firmware, or in this case, qemu host which is responsible for capping the values to ~8GB storage in some ultra BIOS backwards compatible fashion for MBR partitions. When all the values are correct, calculating `cyls` should be redundant and match exactly d_ncylinders. But in the case of qemu, our calculation corrects things so that cyls * heads * sectors == media_size.
The other part of the patch is to allow fdisk -s to always emit the geometry line before possibly failing due to missing partition info and crucially, allows the dfly installer to parse the geometry during survey_storage().
Updated by mikdusan 11 months ago
mikdusan wrote in #note-1:
FreeBSD's
fdiskdoes a better job determining disk geometry in this case.
Comparing outputs for dfly vs. freebsd, both with new 20GB virtio_blk disk vbd1:
- on dfly 6.4:
# fdisk vbd1 2>&1 | grep ^cyl cylinders=16383 heads=16 sectors/track=63 (1008 blks/cyl) cylinders=16383 heads=16 sectors/track=63 (1008 blks/cyl)
- on freebsd 14.0:
# fdisk vtbd1 2>&1 | grep ^cyl cylinders=41610 heads=16 sectors/track=63 (1008 blks/cyl) cylinders=41610 heads=16 sectors/track=63 (1008 blks/cyl)
See that freebsd calculated cylinders and the total media space is correct: 20GB 4160*16*63 * 512 .
This shell session shows the disk geometry as determined by fdisk both before and after the first format on vbd1:
# fdisk vbd1 2>&1 | grep ^cyl cylinders=16383 heads=16 sectors/track=63 (1008 blks/cyl) cylinders=16383 heads=16 sectors/track=63 (1008 blks/cyl) # fdisk -I vbd1 ******* Working on device /dev/vbd1 ******* fdisk: invalid fdisk partition table found Warning: ending cylinder wraps, using all 1's # fdisk vbd1 2>&1 | grep ^cyl cylinders=2600 heads=256 sectors/track=63 (16128 blks/cyl) cylinders=2600 heads=256 sectors/track=63 (16128 blks/cyl)
See after format operation fdisk -I ... that the reported geometry is effectively correct: 20GB 2600*256*63 * 512 and this is what allows the 2nd iteration of installer step to work correctly.