[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: ZFS on root - almost there
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
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
> > 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
Main Index |
Thread Index |