Thank you @rjonasz! Followed your tip with changing the “FILES” row in
/etc/mkinitcpio.conf. After running the obligatory
mkinitcpio -p linuxeverything is up and running again!
For completeness sake:
/etc/mkinitcpio.conf. Add the filename as such:
mkinitcpio -p linux
If in a chroot, exit, unmount and reboot.
Should be up and running!
Even BSD-based FreeNAS systems don’t boot from ZFS, but from a SD flash card. The only easy way to do ZFS root is PC-BSD and–unless you have ALL BSD-supported hardware–you’ll be having lots of problems with Xorg, Wifi, and sound. I think PC-BSD is great, but *BSD is just not widely enough used to have good hardware support.
This is true for versions prior to version 9.3 of FreeNAS, however now the USB memory stick/SD-card or whichever (typically flash based) storage you use is formatted as a ZFS volume by default.
I have two USB-sticks in a mirror:
pool: freenas-boot state: ONLINE scan: scrub repaired 0 in 0h1m with 0 errors on Sat May 14 03:46:12 2016 config: NAME STATE READ WRITE CKSUM freenas-boot ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 da1p2 ONLINE 0 0 0 da0p2 ONLINE 0 0 0 errors: No known data errors
Otherwise I agree, it would be so much nicer if the number of “moving parts” would be kept lower, i.e. kernel and ZFS integration.
@romanaOne I’m sure that one day it all be sorted and we can work with the best of the available tools, btrfs, zfs and more…
I’m just amazed by the responsiveness of this community, the issue over at github have already been closed and the source of the problem we had today is fixed. Just awesome
My typical approach to this problem is to archive/save the whole drive/directories where config files tend to end up, to be able to retrieve what I may need after the actual reinstall.
Went from other distro to Antergos not so long ago (long-time Arch user though).
I booted from a live medium, antergos install cd would do perfectly fine, and then cloned my whole SSD to another spare drive.
The whole drive is not necessary, but great for peace of mind.
Typical directories would be
From there I installed Antergos on the SSD, and then when booted and all set, I could start to move over things like nfs-mounts in /etc/fstab, telegram-data, vim-configs, ssh-keys, and on and on.
Personally I keep the spare drive for a while, usually something you forgot and it saves a bunch of time just doing a quick copy rather than figuring out just how you wanted to have it, if it’s a program you don’t use all the time.
If you are dead set on moving the actual install, just like karasu mentioned, a clone and deploy solution like clonezilla would be fine, the potential problem being the typically smaller SSD if you came from a harddrive.
Hope this is of any help!
Hi! I experienced the very same thing today.
You are correct, the same happens with
linux-headersinstalled as well.
It seems the dkms.conf in the supplied zfs-0.6.5.7 package contains: (take note of PACKAGE_VERSION)
$> head -n 2 dkms.conf PACKAGE_NAME="zfs" PACKAGE_VERSION="0.6.5.7.r2178_4.5.4_1"
whereas the previous version:
without the revision and kernel version info.
and remove the revision and kernel version. Should look like this:
Symlink to use the correct name:
# pwd /usr/src # ln -s zfs-0.6.5.7.r2178_4.5.4_1/ zfs-0.6.5.7
dkms statusif you have any zfs module, remove if broken etc.
Then clean and reinstall with DKMS:
$> sudo dkms add -m zfs -v 0.6.5.7 Creating symlink /var/lib/dkms/zfs/0.6.5.7/source -> /usr/src/zfs-0.6.5.7 DKMS: add completed. $> sudo dkms install -m zfs -v 0.6.5.7 *BUILD LOG STUFF* $> sudo mkinitcpio -p linux *SHOULD SUCCEED NOW!*
I have added an issue to the relevant git repo