On Sun, 11 Apr 2021, Greg A. Woods wrote:
NetBSD can actually make some sense of this FreeBSD filesystem though:
# fsck -n /dev/mapper/rscratch-fbsd--test.0
** /dev/mapper/rscratch-fbsd--test.0 (NO WRITE)
Invalid quota magic number
CONTINUE? yes
** File system is already clean
** Last
On Sun, 11 Apr 2021, Greg A. Woods wrote:
Anyway this does something slightly different (and better, or worse) on
the FreeBSD side, but still ends up with a corrupted filesystem, as seen
from both sides, though maybe not so bad from NetBSD's point of view:
# mount /dev/da1
mount: /dev/da1:
At Sun, 11 Apr 2021 23:04:29 - (UTC), mlel...@serpens.de (Michael van Elst)
wrote:
Subject: Re: one remaining mystery about the FreeBSD domU failure on NetBSD
XEN3_DOM0
>
> wo...@planix.ca ("Greg A. Woods") writes:
>
> >SALVAGE? [yn] ^Cada0: disk error cmd=write 8145-8152 status: fffe
>
wo...@planix.ca ("Greg A. Woods") writes:
>system was suffering the effects of accessing the corrupted filesystem I
>was experimenting with. Note the SIGSEGV's from processes apparently
>after the kernel has gone into its halt-spin loop (this is the first
>time I've seen this particular
On Sun, Apr 11, 2021 at 01:28:46PM -, Michael van Elst wrote:
> bou...@antioche.eu.org (Manuel Bouyer) writes:
>
> >The size of the disk is indeed 790528 in the xenstore (and the dom0's
> >kernel message) but I don't know where this comes from.
>
> >The file is definitively 791121 sectors
bou...@antioche.eu.org (Manuel Bouyer) writes:
>The size of the disk is indeed 790528 in the xenstore (and the dom0's
>kernel message) but I don't know where this comes from.
>The file is definitively 791121 sectors long:
vnd computes a fake geometry based on 1MB cylinders.
791121 truncated to
bou...@antioche.eu.org (Manuel Bouyer) writes:
>On Sun, Apr 11, 2021 at 01:28:46PM -, Michael van Elst wrote:
>> bou...@antioche.eu.org (Manuel Bouyer) writes:
>>
>> >The size of the disk is indeed 790528 in the xenstore (and the dom0's
>> >kernel message) but I don't know where this comes
wo...@planix.ca ("Greg A. Woods") writes:
>I'm thinking (esp. given what I see from "od -c < /dev/rvnd0d") that
>what's wrong is the vnd(4) driver is (also?) imposing some
>mis-interpreted idea about the number of cylinders and heads or
>something like that, especially given that "fdisk vnd0" is
On Sat, Apr 10, 2021 at 03:17:35PM -0700, Greg A. Woods wrote:
> [...]
> # fdisk -F /images/FreeBSD-12.2-RELEASE-amd64-mini-memstick.img
> Disk: /images/FreeBSD-12.2-RELEASE-amd64-mini-memstick.img
> NetBSD disklabel disk geometry:
> cylinders: 49, heads: 255, sectors/track: 63 (16065
Date:Sun, 11 Apr 2021 15:53:07 +0200
From:Manuel Bouyer
Message-ID:
| On Sun, Apr 11, 2021 at 01:28:46PM -, Michael van Elst wrote:
| > vnd computes a fake geometry based on 1MB cylinders.
|
| Why does this trucates the total number of sectors of the vnd
Date:Sun, 11 Apr 2021 14:25:40 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| + dg->dg_secperunit = vnd->sc_size / DEV_BSIZE;
While it shouldn't make any difference for any properly created image
file, make it be
wo...@planix.ca ("Greg A. Woods") writes:
> dg->dg_secperunit =
> ((vnd->sc_size * DEV_BSIZE) + DEV_BSIZE - 1) /
> vnd->sc_geom.vng_secsize;
@@ -2104,11 +2108,12 @@ static void
vnd_set_geometry(struct vnd_softc *vnd)
{
struct disk_geom *dg = >sc_dkdev.dk_geom;
k...@munnari.oz.au (Robert Elz) writes:
>Date:Sun, 11 Apr 2021 14:25:40 - (UTC)
>From:mlel...@serpens.de (Michael van Elst)
>Message-ID:
> | + dg->dg_secperunit = vnd->sc_size / DEV_BSIZE;
>While it shouldn't make any difference for any properly created
jaromir.dole...@gmail.com (=?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=?=) writes:
>Le dim. 11 avr. 2021 =C3=A0 17:51, Robert Elz a =C3=A9c=
>rit :
>>
>> Date:Sun, 11 Apr 2021 14:25:40 - (UTC)
>> From:mlel...@serpens.de (Michael van Elst)
>> Message-ID:
>>
>> | +
At Sun, 11 Apr 2021 16:06:27 - (UTC), mlel...@serpens.de (Michael van Elst)
wrote:
Subject: Re: I think I've found why Xen domUs can't mount some file-backed disk
images! (vnd(4) hides labels!)
>
> k...@munnari.oz.au (Robert Elz) writes:
>
> >Date:Sun, 11 Apr 2021 14:25:40 -
Date:Sun, 11 Apr 2021 14:25:40 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| Seems to have been introduced with netbsd-7.
Perhaps, but the effect was probably invisible until Jan this year
when the calculation of ncylinders was corrected -
Le dim. 11 avr. 2021 à 17:51, Robert Elz a écrit :
>
> Date:Sun, 11 Apr 2021 14:25:40 - (UTC)
> From:mlel...@serpens.de (Michael van Elst)
> Message-ID:
>
> | + dg->dg_secperunit = vnd->sc_size / DEV_BSIZE;
>
> While it shouldn't make any difference for
wo...@planix.ca ("Greg A. Woods") writes:
>SALVAGE? [yn] ^Cada0: disk error cmd=write 8145-8152 status: fffe
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
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
So, with the vnd(4) issue more or less sorted, there seems to be one
major mystery remaining w.r.t. whatever has gone wrong with the ability
of NetBSD-current XEN3_DOM0 to host FreeBSD domUs.
I still can't create a clean filesystem on a writeable disk. The
"newfs" runs fine, but a subsequent
At Sun, 11 Apr 2021 13:23:31 -0700, "Greg A. Woods" wrote:
Subject: one remaining mystery about the FreeBSD domU failure on NetBSD
XEN3_DOM0
>
> In fact it only seems to be fsck that complains, possibly along
> with any attempt to write to a filesystem, that causes problems.
Definitely writing
Date:Sun, 11 Apr 2021 18:14:44 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| + spb = vnd->sc_geom.vng_secsize / DEV_BSIZE;
Do we know for sure here that vng_secsize >= DEV_BSIZE ?
When I first used unix (long long ago) the drives I
wo...@planix.ca ("Greg A. Woods") writes:
> } 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
At Sun, 11 Apr 2021 21:13:44 + (UTC), RVP wrote:
Subject: Re: one remaining mystery about the FreeBSD domU failure on NetBSD
XEN3_DOM0
>
> I've run into this before. This is a NetBSD vs. FreeBSD UFS issue. Create
> a UFS v1 FS on FreeBSD if you want to write it on NetBSD:
>
> newfs -O1
k...@munnari.oz.au (Robert Elz) writes:
>Date:Sun, 11 Apr 2021 18:14:44 - (UTC)
>From:mlel...@serpens.de (Michael van Elst)
>Message-ID:
> | + spb = vnd->sc_geom.vng_secsize / DEV_BSIZE;
>Do we know for sure here that vng_secsize >= DEV_BSIZE ?
>When I
25 matches
Mail list logo
