tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: I think I've found why Xen domUs can't mount some file-backed disk images! (vnd(4) hides labels!)



So I just tested the patch below, and it actually works!

FreeBSD complains a wee bit during boot that it can't read the last few
sectors of the disk and later the last few sectors of its root FS, but
it does find all the the partitions, and the right filesystem(s) in
/dev/vnd0d:

First from the NetBSD kernel:

      xbd backend: attach device vnd0d (size 792576) for domain 2

Next from the FreeBSD kernel:

xbd0: 387MB <Virtual Block Device> at device/vbd/768 on xenbusb_front0
xbd0: attaching as ada0
xbd0: features: flush
xbd0: synchronize cache commands enabled.
GEOM: new disk ada0
ada0: disk error cmd=read fsbn 792574 status: ffffffff
ada0: disk error cmd=read fsbn 792575 status: ffffffff
ada0: disk error cmd=read fsbn 792574 status: ffffffff
ada0: disk error cmd=read fsbn 792575 status: ffffffff
ada0: disk error cmd=read fsbn 792575 status: ffffffff
ada0: disk error cmd=read 792513-792516 status: ffffffff
xn0: backend features: feature-sg
Trying to mount root from ufs:ufs/FreeBSD_Install [ro]...
ada0: disk error cmd=read fsbn 792575 status: ffffffff
ada0: disk error cmd=read fsbn 792575 status: ffffffff
arc4random: no preloaded entropy cache
xen_et0: providing initial system time
start_init: trying /sbin/init
Script /etc/rc.d/ccd running
Starting file system checks:
/dev/ufs/FreeBSD_Install: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/ufs/FreeBSD_Install: clean, 5744 free (128 frags, 702 blocks, 0.1% fragmentation)
ada0: disk error cmd=read fsbn 792574 status: ffffffff
ada0: disk error cmd=read fsbn 792575 status: ffffffff
ada0: disk error cmd=read fsbn 792574 status: ffffffff
ada0: disk error cmd=read fsbn 792575 status: ffffffff
ada0: disk error cmd=read fsbn 792575 status: ffffffff
ada0: disk error cmd=read 792513-792516 status: ffffffff
ada0: disk error cmd=read fsbn 792575 status: ffffffff
Mounting local filesystems:.

.....  and from FreeBSD userland:

# ls -l /dev/*fs/
/dev/msdosfs/:
total 0
crw-r-----  1 root  operator  0x42 Apr 11 18:02 EFISYS

/dev/ufs/:
total 0
crw-r-----  1 root  operator  0x45 Apr 11 18:02 FreeBSD_Install
# fdisk ada0
******* Working on device /dev/ada0 *******
parameters extracted from in-core disklabel are:
cylinders=49 heads=255 sectors/track=63 (16065 blks/cyl)

parameters to be used for BIOS calculations are:
cylinders=49 heads=255 sectors/track=63 (16065 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 239 (0xef),(EFI System Partition)
    start 1, size 1600 (0 Meg), flag 0
        beg: cyl 1023/ head 255/ sector 63;
        end: cyl 1023/ head 255/ sector 63
The data for partition 2 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 1601, size 789520 (385 Meg), flag 80 (active)
        beg: cyl 1023/ head 255/ sector 63;
        end: cyl 1023/ head 255/ sector 63
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>




On NetBSD fdisk and cmp are both much happier too, though I'm a wee bit
concerned about the differences between "Partitions aligned to 16065
sector boundaries, offset 63" and "Partitions aligned to 2048 sector
boundaries, offset 32":

(the following are all run from NetBSD, of course, with the FreeBSD domU
running, thus /dev/vnd0d is supposed to be the whole image file)

# ls -ls /build/images/F*.img
791488 -rw-r--r--  1 woods  wheel  405053952 Oct 22 23:04 /build/images/FreeBSD-12.2-RELEASE-amd64-mini-memstick.img
# vnconfig -l
vnd0: /build (/dev/mapper/scratch-build) inode 10306562
vnd1: not in use
vnd2: not in use
vnd3: not in use
# ls -i /build/images/F*.img
10306562 /build/images/FreeBSD-12.2-RELEASE-amd64-mini-memstick.img
# cmp /build/images/F*.img /dev/rvnd0d
# fdisk -F /build/images/F*.img
Disk: /build/images/FreeBSD-12.2-RELEASE-amd64-mini-memstick.img
NetBSD disklabel disk geometry:
cylinders: 49, heads: 255, sectors/track: 63 (16065 sectors/cylinder)
total sectors: 791121, bytes/sector: 512

BIOS disk geometry:
cylinders: 49, heads: 255, sectors/track: 63 (16065 sectors/cylinder)
total sectors: 791121

Partitions aligned to 16065 sector boundaries, offset 63

Partition table:
0: EFI system partition (sysid 239)
    start 1, size 1600 (1 MB, Cyls 0/0/2-0/25/26)
1: FreeBSD or 386BSD or old NetBSD (sysid 165)
    start 1601, size 789520 (386 MB, Cyls 0/25/27-49/62/30), Active
2: <UNUSED>
3: <UNUSED>
First active partition: 1
Drive serial number: 2425393296 (0x90909090)
# fdisk vnd0
fdisk: Cannot determine the number of heads
Disk: /dev/rvnd0
NetBSD disklabel disk geometry:
cylinders: 387, heads: 64, sectors/track: 32 (2048 sectors/cylinder)
total sectors: 791121, bytes/sector: 512

BIOS disk geometry:
cylinders: 387, heads: 64, sectors/track: 32 (2048 sectors/cylinder)
total sectors: 791121

Partitions aligned to 2048 sector boundaries, offset 32

Partition table:
0: EFI system partition (sysid 239)
    start 1, size 1600 (1 MB, Cyls 0/0/2-0/50/1)
1: FreeBSD or 386BSD or old NetBSD (sysid 165)
    start 1601, size 789520 (386 MB, Cyls 0/50/2-386/18/17), Active
2: <UNUSED>
3: <UNUSED>
First active partition: 1
Drive serial number: 2425393296 (0x90909090)



So, as you can see below I think it's better to round the device out to
a full number of cylinders if we're still going to play the CHS
silliness.

But for vnd(4) in particular I think it does beg the questions I ask
in the new comments below, especially the first one.

--- vnd.c.~1.278.~	2021-03-07 17:18:43.000000000 -0800
+++ vnd.c	2021-04-11 11:00:52.147530152 -0700
@@ -1480,20 +1480,41 @@
 			}
 		} else if (vnd->sc_size >= (32 * 64)) {
 			/*
-			 * Size must be at least 2048 DEV_BSIZE blocks
-			 * (1M) in order to use this geometry.
+			 * The file's size must be at least 2048 DEV_BSIZE
+			 * blocks (1M) in order to use this (fake) geometry.
+			 *
+			 * XXX why ever use this arbitrary fake setup instead of the next????
 			 */
 			vnd->sc_geom.vng_secsize = DEV_BSIZE;
 			vnd->sc_geom.vng_nsectors = 32;
 			vnd->sc_geom.vng_ntracks = 64;
-			vnd->sc_geom.vng_ncylinders = vnd->sc_size / (64 * 32);
+			vnd->sc_geom.vng_ncylinders = (vnd->sc_size + (64 * 32) - 1) / (64 * 32);
 		} else {
+			/*
+			 * XXX is there anything that pretends which is worse:
+			 * rotational delay, or seeking?  Does it matter for < 1M?
+			 */
+#if 1
+			/* else pretend it's just one big platter of single-sector cylinders */
 			vnd->sc_geom.vng_secsize = DEV_BSIZE;
 			vnd->sc_geom.vng_nsectors = 1;
 			vnd->sc_geom.vng_ntracks = 1;
 			vnd->sc_geom.vng_ncylinders = vnd->sc_size;
+#else
+			/* else pretend it's just one big cylinder */
+			vnd->sc_geom.vng_secsize = DEV_BSIZE;
+			vnd->sc_geom.vng_nsectors = vnd->sc_size;
+			vnd->sc_geom.vng_ntracks = 1;
+			vnd->sc_geom.vng_ncylinders = 1;
+#endif
 		}

+		/*
+		 * n.b.:  this will round the disk's size up to an even cylinder
+		 * amount, but (if it is writeable) writing into the partly
+		 * empty cylinder, i.e. past current end of the file, will
+		 * simply extend the file....
+		 */
 		vnd_set_geometry(vnd);

 		if (vio->vnd_flags & VNDIOF_READONLY) {



--
					Greg A. Woods <gwoods%acm.org@localhost>

Kelowna, BC     +1 250 762-7675           RoboHack <woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost>     Avoncote Farms <woods%avoncote.ca@localhost>

Attachment: pgpj_DpRBgf5H.pgp
Description: OpenPGP Digital Signature



Home | Main Index | Thread Index | Old Index