Bug #3369
closed
installer fails to use entire disk: legacy BIOS, qemu, virtio_blk
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 12 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 12 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.
Updated by daftaupe 8 days ago
- Status changed from New to Feedback
Hello @mikdusan
I can confirm both the issue and the fact that you're patch solves the issue in the conditions you mentionned :
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
I've released a new iso/img file for those who want to give the patch a try based on latest 6.4.1 release : https://leaf.dragonflybsd.org/~daftaupe/6.4.1_patch3369/
Updated by liweitianux 7 days ago
By the way, we should check whether gpt(8) has the similar problem, and if yes, we should fix it as well.
Updated by dillon 1 day ago
- Status changed from Feedback to Resolved
- Assignee set to dillon
I have pushed a fix to the virtio driver instead of to fdisk. Pushed to both the release branch and to master. The driver now detects that qemu capped the cylinder count it reports to the kernel and recalculates the ncylinders it reports to fdisk. Please test.