Bug #655

vkernel filesystem checks fail

Added by josepht almost 7 years ago. Updated almost 7 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

I'm running a HEAD vkernel (from today) on a HEAD machine from May 13,
2007 and I get the following error during the filesystem checks. I
assume this is related to the recent disklabel work. I'm not sure
what I should or can do to fix this. I tried creating a new root
image but had the same problem.

Can't stat /dev/vkd0a: No such file or directory
Can't stat /dev/vkd0a: No such file or directory
/dev/vkd0a: CAN'T CHECK FILE SYSTEM.
/dev/vkd0a: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

I also tried using the new disklabel
in /usr/obj to fix the disklabel for vn0 but got this error:

$ .../disklabel -e vn0
disklabel: Operation not supported by device

Thanks,
Joe

History

#1 Updated by dillon almost 7 years ago

:I'm running a HEAD vkernel (from today) on a HEAD machine from May 13,
:2007 and I get the following error during the filesystem checks. I
:assume this is related to the recent disklabel work. I'm not sure
:what I should or can do to fix this. I tried creating a new root
:image but had the same problem.
:
:Can't stat /dev/vkd0a: No such file or directory
:Can't stat /dev/vkd0a: No such file or directory
:/dev/vkd0a: CAN'T CHECK FILE SYSTEM.
:/dev/vkd0a: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
:
:I also tried using the new disklabel
:in /usr/obj to fix the disklabel for vn0 but got this error:
:
:$ .../disklabel -e vn0
:disklabel: Operation not supported by device
:
:Thanks,
:Joe

I'm going to guess that your disk image did not use a MBR or fdisk,
but just had a straight disklabel. In that case try accessing it via:

disklabel vn0s0

Remake your vn0* devices if necessary (cd /dev; ./MAKEDEV vn0).

Same with vkd. Mount the root image with vn and remake the devices in
the root image's /dev. Inside the vkernel the mount points will probably
be vkd0s0a, etc.

-Matt
Matthew Dillon
<>

#2 Updated by josepht almost 7 years ago

You are correct that it is a straight disklabel. However my host
system is from before your disklabel update. I don't have a vn0s0 in
/dev though I do have a vn0s1 but get this error when using disklabel
on it:

disklabel: ioctl DIOCGDINFO: Inappropriate ioctl for device

Joe

#3 Updated by josepht almost 7 years ago

Okay, I managed to mount the image and edit /etc/fstab to correct the
mount points.

Joe

#4 Updated by corecode almost 7 years ago

I'm kind of feeling uneasy that we now "require" a slice. I thought that's just IBM PC legacy? How about having "vkd0a" == "vkd0s0a"? That would look nice again. Or maybe the other way around?

cheers
simon

#5 Updated by dillon almost 7 years ago

:I'm kind of feeling uneasy that we now "require" a slice. I thought that=
:'s just IBM PC legacy? How about having "vkd0a" =3D=3D "vkd0s0a"? That =
:would look nice again. Or maybe the other way around?
:
:cheers
: simon

We don't require a slice. The internal representations haven't changed,
just the external device names and device numbering. The external
names and numbering had to change because of two problems.

(1) The 'raw' disk also doubled as the labeled disk for the compatibility
slice. e.g. you could 'disklabel da0'. This meant that one
could not access the raw disk directly as a raw disk without going
through some hand waving... there was no way to do it without
the kernel trying to snoop reads and writes for MBR and disklabel
accesses.

(2) The 'raw slice' also doubled as partition 'c' in the slice. e.g.
if you look on a 1.8 or earlier system, 'da0s1' had the same device
number as 'da0s1c'. This meant that we could not distinguish between
a raw slice and partition 'c' within a raw slice.

To fix these problems the compatibility device names and the raw-slice
devices had to be renumbered. That is, in 1.9 now, 'da0' really does
mean a raw disk, the kernel doesn't attempt to process the MBR or
disklabel or snoop reads and writes or enforce reserved areas. 'da0s0'
is the faked compatibility slice (aka for disklabeled disks without
DOS partition tables). They are separate entities now. And, in 1.9,
we distinguish between a raw slice, aka da0s1, and a partition
specification using a disklabel installed on that slice, aka da0s1{a-p}.

Pre 1.9 there was no distinction... you could run disklabel on
anything and the system would silently 'translate' the device to
a device that was label capable, and the system also tried to snoop
MBR and label accesses even for the whole-raw-disk device (e.g. da0),
which created serious confusion. Now we have real device names
representing the labelable raw slices (e.g. da0s1), a faked compatibility
slice (e.g. da0s0) that can be labeled if you don't have an DOS partition
table (otherwise it aliases the first BSD partition just like the
compatibility slices used to, but I might remove that feature), the
partition specifications are properly distinct from the raw slice
name (da0s1 != da0s1c any more), and the disk layer can now avoid
snooping labels or scanning the whole partition table until they
are actually accessed.

-Matt
Matthew Dillon
<>

Also available in: Atom PDF