Project

General

Profile

Actions

Bug #3369

open

installer fails to use entire disk: legacy BIOS, qemu, virtio_blk

Added by mikdusan 22 days ago. Updated 22 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
installer
Target version:
Start date:
05/25/2024
Due date:
% Done:

0%

Estimated time:

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

fdisk-cyls.patch (872 Bytes) fdisk-cyls.patch mikdusan, 05/25/2024 12:06 PM
Actions #1

Updated by mikdusan 22 days ago

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().

Actions #2

Updated by mikdusan 22 days ago

mikdusan wrote in #note-1:

FreeBSD's fdisk does 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.

Actions

Also available in: Atom PDF