Bug #762

missing 's0' in device use

Added by thomas.nikolajsen about 7 years ago. Updated over 6 years ago.

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

0%

Category:-
Target version:-

Description

After change to use s0 for 'compatibility' slice, as described
in UPDATING, its use need to be changed in a few places.

A few small patches attached.

ccdconfig(8) man page, EXAMPLES section, also may need changes,
I didn't test yet, but it has several uses like /dev/da3e,
which I guess should be /dev/da3s0e.
disklabel should use ccd0 (or maybe ccd0s0), not ccd0c.

Also it would be nice to have info about this in a man page,
not just in UPDATING. But which man page?

On the same note, it would be really nice to have usage of slice number
for device nodes in a man page. Eg. MBR s1 - s4 primary/extended slices and s5
upward are in extended slices.

-thomas

rc.d.patch Magnifier (565 Bytes) thomas.nikolajsen, 08/03/2007 09:04 PM

swapon.8.patch Magnifier (508 Bytes) thomas.nikolajsen, 08/03/2007 09:04 PM

vnconfig.8.patch Magnifier (1.41 KB) thomas.nikolajsen, 08/03/2007 09:05 PM

vnconfig.8.2.patch Magnifier (1.83 KB) thomas.nikolajsen, 08/09/2007 09:48 PM

ccd.4.patch Magnifier (436 Bytes) thomas.nikolajsen, 08/09/2007 09:48 PM

ccdconfig.8.patch Magnifier (2.47 KB) thomas.nikolajsen, 08/09/2007 09:48 PM

disklabel.8.patch Magnifier (5.89 KB) thomas.nikolajsen, 08/09/2007 09:49 PM

disklabel64.5.patch Magnifier (1.67 KB) thomas.nikolajsen, 08/09/2007 09:49 PM

disklabel64.8.patch Magnifier (3.65 KB) thomas.nikolajsen, 08/09/2007 09:49 PM

vinum.4.patch Magnifier (2.25 KB) thomas.nikolajsen, 08/09/2007 09:49 PM

vinum.8.patch Magnifier (12.6 KB) thomas.nikolajsen, 08/09/2007 09:49 PM

History

#1 Updated by thomas.nikolajsen about 7 years ago

I have looked into this; think I'm finished for now.

New patches attached:
- vnconfig(8)
forgot one place in prev. patch.

- ccd(4), ccdconfig(8)
tested, not just guessing.

- disklabel(8)
I have called 's0' for 'compatibility slice',
other (w/ positive slice number) 'normal slice'.
Terms used was: 'base disk/raw disk' and 'slice';
this had to change if 's0' is called a slice, which seems natural.
I'm not sure s0 always technically is a compatibility slice;
eg. for vn0s0 or ccd0s0; if other terms should be used,
give me a hint or just change it.
Also first disklabel example is changes a bit:
a ccd partition is added (we don't use 4.2BSD for that any more),
and an error is fixed: sizes and offsets didn't add up correctly.

- disklabel64(5), disklabel64(8)
Minimal changes: just to show disklabel64; not 'disklabel'
(which I think is confusing at best).
I could make a more elaborate patch if needed
(including same change for disklabel64.c).

- vinum(4), vinum(8)
This isn't tested yet; will do that.
's0' is added to devicenames without;
I guess this is correct as eg. /dev/da1h doesn't exist any more.
Also disklabel output for a vinum partition is dropped,
as preceeding text says it server no useful purpose.
(if needed I could change output to current form instead).
A few comments on ccd(4) are updated.

I came to think about that information on changed disk device use,
is only in /usr/src/UPDATING, which isn't on release CD.
I think easiest solution would be to just copy UPDATING to root of CD.

-thomas
-
http://leaf.dragonflybsd.org/mailarchive/commits/2007-06/msg00169.html
http://leaf.dragonflybsd.org/mailarchive/commits/2007-06/msg00169.html

PS: It could be really nice it this could be committed ASAP and MFC'ed,
so it could hit the next release update
(Matt talked about this coming week-end for mbuf fix).

#2 Updated by swildner about 7 years ago

Committed.

Committed.

Uh, I looked into this for some time and ended up frustrated. For
example, shouldn't it then also be

disklabel [-r] slice

instead of

disklabel [-r] disk

??

I'm kinda confused over adjusting disklabel.8.

Committed.

Not committed. Is this tested yet?

Yea, that would be a good thing.

Sascha

#3 Updated by nthery about 7 years ago

Hello,

There is also a missing 's0' in vkernel man page.

Cheers,
Nicolas

Index: dfly/src/share/man/man7/vkernel.7
===================================================================
--- dfly.orig/src/share/man/man7/vkernel.7 2007-07-24 16:02:10.000000000 +0200
+++ dfly/src/share/man/man7/vkernel.7 2007-08-08 13:25:00.000000000 +0200
@@ -291,7 +291,7 @@
make installworld DESTDIR=/mnt
cd etc
make distribution DESTDIR=/mnt
-echo '/dev/vkd0a / ufs rw 1 1' >/mnt/etc/fstab
+echo '/dev/vkd0s0a / ufs rw 1 1' >/mnt/etc/fstab
.Ed
.Pp
Edit

#4 Updated by corecode about 7 years ago

[..]
> -echo '/dev/vkd0a / ufs rw 1 1' >/mnt/etc/fstab
> +echo '/dev/vkd0s0a / ufs rw 1 1' >/mnt/etc/fstab

are you sure that this is needed? I thought vkd don't use a slice table.

cheers
simon

#5 Updated by nthery about 7 years ago

Hello,

Well, when I "ls /dev/vkd0*", I get:

/dev/vkd0 /dev/vkds0 /dev/vkds0a ...

There is no /dev/vkd0a printed.

First time I configured the vkernel, I referred to an old version of
vkernel.7 and had to manually add 's0' to some other commands so after
checking /dev as shown above I added it in /etc/fstab too and it's
been running ok since.

However, I've just put /dev/vkd0a in /etc/fstab and it works too.

Is 's0' somehow added by mount or the kernel?

Cheers,
Nicolas

#6 Updated by corecode about 7 years ago

Okay then.

The root mount information does not come from /etc/fstab :)

cheers
simon

#7 Updated by nthery about 7 years ago

[...]
> > However, I've just put /dev/vkd0a in /etc/fstab and it works too.
> >
> > Is 's0' somehow added by mount or the kernel?
>
> The root mount information does not come from /etc/fstab :)

Fair enough. I forgot I'm passing -r /var/vkernel/rootimg.01 to
vkernel everytime I'm starting it :-).

According to init_disk() in src/sys/platform/vkernel/platform/init.c,
the root virtual disk is associated with vkd0s0a. So I reckon my
patch makes sense.

Anybody knows what /etc/fstab is used for in the vkernel env?

Cheers,
Nicolas

#8 Updated by c.turner about 7 years ago

Any other mounted filesystems as usual..
see /etc/rc.d/mountcritlocal, etc.

The vkernel boots on the first partition in the vkd by default,
see init_vkd in sys/platform/vkernel/platform/init.c:705
(sets to vkd0s0a for VKD_DISK and cd9660:vcd0a for VKD_CD)

Probably good to have fstab and the docs match something that works
(as discussed elsewhere)
in case you want the shorthand to 'mount -o rw /'
after an unclean shutdown, mount -a from vcd booted chroot,
etc..

#9 Updated by thomas.nikolajsen about 7 years ago

I have tested vinum: patches for vinum(4), vinum(8) are OK.
(but I did find problems with vinum; another issue for that)

-thomas

#10 Updated by swildner about 7 years ago

Okay, committed.

Sascha

#11 Updated by dillon about 7 years ago

:Well, when I "ls /dev/vkd0*", I get:
:
:/dev/vkd0 /dev/vkds0 /dev/vkds0a ...
:
:There is no /dev/vkd0a printed.
:
:First time I configured the vkernel, I referred to an old version of
:vkernel.7 and had to manually add 's0' to some other commands so after
:checking /dev as shown above I added it in /etc/fstab too and it's
:been running ok since.
:
:However, I've just put /dev/vkd0a in /etc/fstab and it works too.
:
:Is 's0' somehow added by mount or the kernel?
:
:Cheers,
:Nicolas

The manual page is definitely wrong, it needs to be vkd0s0a. It works
because even though the manual page is wrong, the vkernel doesn't
actually use the '/' entry in /etc/fstab to figure out what to do.
But it does create confusion so I'm fixing it right now.

-Matt
Matthew Dillon
<>

#12 Updated by dillon about 7 years ago

:The root mount information does not come from /etc/fstab :)
:
:cheers
: simon

The vkernel synthesizes it in the root mount code, so no it doesn't.
But other things use /etc/fstab so I corrected it.

-Matt

Also available in: Atom PDF