Re: one remaining mystery about the FreeBSD domU failure on NetBSD XEN3_DOM0

[mlelstv%serpens.de@localhost (Michael van Elst)]

woods%planix.ca@localhost ("Greg A. Woods") writes:

>SALVAGE? [yn] ^Cada0: disk error cmd=write 8145-8152 status: fffffffe

That seems to be a message from the disk driver:

 /* Operation not supported (only happens on barrier writes). */
#define BLKIF_RSP_EOPNOTSUPP  -2


If I understand that correctly, a NetBSD Dom0 will return this
status for writing to a read-only backend or for issuing a
cache sync to a disk that doesn't support this operation.

The latter case should log a message on Dom0 about DIOCCACHESYNC
failing.




>So, what could be different about how fsck reads v.s. the kernel itself?

With NetBSD the major difference is how kernel and userland address
disk blocks.

The original BSD code would address disks in sector size units. This is
still true for userland, the NetBSD kernel however was changed to address
blocks in DEV_BSIZE units.

AFAIK FreeBSD stayed with using sector size units.

But if you have sectors of DEV_BSIZE like here there is no difference
and no conflict.



>It seems NetBSD can make sense of the BSD label inside the FreeBSD
>mini-memstick.img file, e.g. when accessed through vnd(4),

No, it cannot. You see a fictious label generated from the MBR.

The FreeBSD-12.2-RELEASE-amd64-mini-memstick.img I just fetched
has two MBR partitions:

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

Making our disklabel program read the FreeBSD disklabel was a bit
tricky, there is a bug that makes it segfault, but:

type: unknown
disk: 
label: 
flags:
bytes/sector: 512
sectors/track: 1
tracks/cylinder: 1
sectors/cylinder: 1
cylinders: 789520
total sectors: 789520
rpm: 3600
interleave: 0
trackskew: 0
cylinderskew: 0
headswitch: 0           # microseconds
track-to-track seek: 0  # microseconds
drivedata: 0 

8 partitions:
#        size    offset     fstype [fsize bsize cpg/sgs]
 a:    789504        16     4.2BSD      0     0     0  # (Cyl.     16 - 789519)
 c:    789520         0     unused      0     0        # (Cyl.      0 - 789519)


Apparently the MBR partition 1 starting at sector 1601 is a disk
image itself and the disklabel is in sector 1 of that image.

Adding a wedge to access the partition at offset 16 (+1601) gives:

# dkctl vnd0 addwedge freebsd 1617 789504 ffs
dk6 created successfully.

# file -s /dev/rdk6
/dev/rdk6: Unix Fast File system [v2] (little-endian) last mounted on , volume name FreeBSD_Install, last written at Fri Oct 23 08:04:24 2020, clean flag 1, readonly flag 0, number of blocks 98688, number of data blocks 97871, number of cylinder groups 1, block size 32768, fragment size 4096, average file size 16384, average number of files in dir 64, pending blocks to free 0, pending inodes to free 0, system-wide uuid 0, minimum percentage of free blocks 8, TIME optimization

# fsck -f -n /dev/rdk6
** /dev/rdk6 (NO WRITE)
** File system is already clean
** Last Mounted on 
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
12129 files, 92127 used, 5744 free (128 frags, 702 blocks, 0.1% fragmentation)

NetBSD can even mount that partition:

# ls /mnt
COPYRIGHT      HARDWARE.TXT   RELNOTES.TXT   docbook.css    media          rescue         usr
ERRATA.HTML    README.HTML    bin            etc            mnt            root           var
ERRATA.TXT     README.TXT     boot           lib            net            sbin
HARDWARE.HTML  RELNOTES.HTML  dev            libexec        proc           tmp