Re: ZFS on root - almost there

[Chavdar Ivanov <ci4ic4%gmail.com@localhost>]

s/relevant/irrelevant/

On Wed, 26 Feb 2020 at 15:04, Chavdar Ivanov <ci4ic4%gmail.com@localhost> wrote:
>
> On Tue, 25 Feb 2020 at 22:49, Chavdar Ivanov <ci4ic4%gmail.com@localhost> wrote:
> >
> > On Tue, 25 Feb 2020 at 21:51, Roy Marples <roy%marples.name@localhost> wrote:
> > >
> > > On 25/02/2020 21:40, Chavdar Ivanov wrote:
> > > > On Tue, 25 Feb 2020 at 20:14, Roy Marples <roy%marples.name@localhost> wrote:
> > > >>
> > > >> On 22/02/2020 19:22, Roy Marples wrote:
> > > >>> https://wiki.netbsd.org/wiki/RootOnZFS/
> > > >>
> > > >> Updated the wiki and the ramdisk - either the bootloader needs to load the
> > > >> modules via boot.cfg or the modules need to be built into the kernel.
> > > >
> > > > I don't get it - with my present, still 9.99.47 setup, I am able to
> > > > load modules:
> > >
> > > Because we can label a GPT parition "boot".
> > > However, that won't work for MBR based systems.
> > > It's also not very friendly if you have any other OS present who might for
> > > similar reasons have a parition named boot either.
> > >
> > > >> There's just no easy way to load the modules from the ramdisk without putting
> > > >> them inside the ramdisk .... and I think too many people would forget to
> > > >> re-build the ramdisk or put it against the wrong kernel.
> > > >
> > > > So is the option of loading them as per the above no longer available?
> > >
> > > No it's not.
> > > It is however available from the source history if you really want it.
> >
> > Trouble is, I do - for the moment - the tests on a VirtualBox VM and
> > I'd like to have the vboxguest module loaded - otherwise X doesn't
> > work very well in the case of a vm with efi enabled. The module is
> > built elsewhere and I wonder how I could I add it...
>
> OK, I rebuilt 9.99.48 with the latest root-on-zfs changes.
>
> The wiki should be ammended with the instruction to run MAKEDEV
> ( cd /altroot/dev; ch MAKEDEV all )
>
> I tried to preload the vboxguest module by copying it to the initial
> boot system and modifying the boot.cfg file - it didn't work (I have a
> screenshot, but it is relevant).
>
> However, when I booted eventually the root on zfs system, I was able
> to copy the vboxguest.kmod file and load it  without problems; I am
> also able to load any kernel modules.
>
> Swap also works:
>  nzfs# swapctl -l
> Device      1K-blocks     Used    Avail Capacity  Priority
> /dev/dk2      4182016        0  4182016     0%    0
>
> (this was the swap device used by the initial system, as its fstab was
> copied to the new one, it worked fine).
>
> Swap in zvol still doesn't work:
>
> nzfs# zfs create -V 4G rpool/SWAP
> nzfs# swapctl -a /dev/zvol/dsk/rpool/SWAP
> swapctl: /dev/zvol/dsk/rpool/SWAP: Device not configured
> (but then, I just tested, it doesn't work on any other NetBSD system,
> so it is perhaps something of a shortcoming of the ZFS
> implementation).
>
> Anyway, it seems a rather usable combination.
>
> Next is to see how to make any use of zfs snapshot / zfs promote....
>
> The mount table of the booted system appears weird, though:
>
> nzfs# df -k
> Filesystem    1K-blocks       Used      Avail %Cap Mounted on
> root_device        4551       2538       2013  55% /
> rpool/ROOT     21829363    1237365   20591998   5% /
> tmpfs           1045272          0    1045272   0% /altroot/tmp
> ptyfs                 1          1          0 100% /altroot/dev/pts
> tmpfs           1045272          0    1045272   0% /altroot/var/shm
> rpool          24987128         23   24987105   0% /altroot/rpool
> kernfs                1          1          0 100% /altroot/kern
> procfs                4          4          0 100% /altroot/proc
>
> even if / /tmp /kern /proc appear normal. If you look at anything
> below /altroot, it shows nothing.
>
> The /etc/fstab is:
>
> # NetBSD /etc/fstab
> # See /usr/share/examples/fstab/ for more examples.
> NAME=boot /altroot ffs rw,noauto 1 1
> NAME=swap none swap sw,dp 0 0
> tmpfs           /tmp    tmpfs   rw,-m=1777,-s=ram%25
> kernfs          /kern   kernfs  rw
> ptyfs           /dev/pts        ptyfs   rw
> procfs          /proc   procfs  rw
> /dev/cd0a               /cdrom  cd9660  ro,noauto
> tmpfs           /var/shm        tmpfs   rw,-m1777,-sram%25
> #rpool/ROOT /altroot zfs rw
>
> Chavdar
>
>
>
>
> >
> > >
> > > As a last metric, since reverting back to letting the bootloader load the
> > > modules, zpool is no longer panicing randomly. Or the randomness just hasn't
> > > struck yet!
> > >
> > > Roy
> >
> >
> >
> > --
> > ----
>
>
>
> --
> ----



-- 
----