[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: one remaining mystery about the FreeBSD domU failure on NetBSD XEN3_DOM0
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
>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
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:
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:
total sectors: 789520
headswitch: 0 # microseconds
track-to-track seek: 0 # microseconds
# 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
Main Index |
Thread Index |