DragonFlyBSD

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).

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

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

[..]

-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

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

Okay then.

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

cheers
simon

[...]

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

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..

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

-thomas

Okay, committed.

Sascha

: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 
                    <dillon@backplane.com>

: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