SoylentNews

Is it just me? It appears comments are disabled on the Atomically-smooth Gold Crystals Help to Compress Light for Nanophotonic Applications article.
 
Not that I have anything too intelligent to say. Seems like the application is limited to photonic processors and waveguides. I'm academically interested if it can be adapted to semiconductor lithography to facilitate further semiconductor feature shrink. Though TFA reports the application is better suited for sensors and microscopes.
 
Edit: editors have corrected a mistake that prevented comments.

from the we're-all-grasshoppers-at-some-level dept.

Since the SN polls only allows for 8 entries, and I really thought this poll should have more and I don't have the time to learn perl at this moment just to suggest the necessary changes in rehash, I'm throwing it up here. (and it's also here because there's a good chance any election related poll will get veto'ed by the editors... and it's probably better that way too)

For the 2020 election, I intend to stock up on:

1. food
2. water
3. ammo
4. masks
5. Motrin
6. rage
7. relevant information
8. propaganda
9. campaign stickers
10. righteous karma
11. some combination of above as described below
12. all of the above
13. I'm a grasshopper man, I don't stock up anything.
     
    --= Write In Ballots =--
14. Booze

15. (42) weed, beer, beans, tortillas

My recommendation is to vote as AC, responding to the top comment "vote here" using the list number and provide commentary as logged in user or AC as you would normally below the voting thread.

So, a little background. I have a FreeBSD fileserver in the basement used for running Samba and as a Minecraft server for the kids (and a bit for myself). This was built back in the "systemd will destroy all the Debian derivatives" era, and thus how it ended up on a BSD instead of an OS I'm more familiar with, like Ubuntu, Debian, or Slackware (my preferences, in that order, at that time). Also, at the time of building the server, ZFS was just starting to really to peculate through the news aggregators and pique my interest. All of this info affected my choices and I ended up replacing the aging Via C7 (x86) Ubuntu Samba server running reiserfs partitions on mdadmin (mirror) on lvm containers. The new system featured four, GELI encrypted, 1-TB drives sporting ZFS Z2 made possible by FreeBSD 10 or 11 if I can remember correctly. The system works great, but there are a few detractors.

1. I don't really know BSD.
2. GELI, as configured on my system, requires keyboard input to unlock disks
3. Updates suck

On the first point, BSD and Linux are very similar. You can go from one to another and have an idea of what you're doing on the terminal, but they are more different than say RHEL and Debian. If you had to compare it to languages, Linux is like Spanish and BSD is like Portuguese. Much of the roots are the same, but the differences are greater than the regional dialects of British English to American English. This often leaves you in a position where you think you know what you are doing only to find out that you don't.
 
Second, GELI is a lot like LUKS on Linux. It works and I generally don't have to think about it. My issue is my specific configuration. As a dumb noob, during the installer I opted to install root on my ZFS partiton, that was encrypted by GELI. All of that should be great, right? I have LUKS encrypted ZFS on root on the laptop, and it works like a champ. Rhetorical question, how could this be bad? I can ZFS snapshot my OS as I do updates, I have block checksums, and it is all encrypted at rest. Well, the problem is boot. Anytime this system is rebooted, GELI requires keyboard input from the keyboard physically attached to the machine. So that requires running down to the basement, plugging in a keyboard, and unlocking the drives so /boot can have a / to boot into. Regrettably, when I'm traveling, that sometimes requires a flight back home too. Now, I'm told that if I'm willing to make a two line edit to the source code, I can make GELI accept input from the serial console which would fix the remote input issue, That would require me to recompile the source, install it on a "foreign" OS, and then setup a tty link to some other box just for the purpose to inputting a password a few times a year the box gets rebooted. Knowing myself and the other projects I do around the house, I was not going to find the time to make that happen when the alternative is just a visit to the basement.
 
Thirdly, updates suck. For the first four years, there weren't any real issues. Every few months, I would open up the FreeBSD handbook in a browser window and walk through the upgrade process. This is where BSD is not Linux. There is the core OS updates, the package updates, and the ports updates. All three handled differently. And if your package updater happens to see applications from your ports and decides to update them, things break. I guess I was fortunate for the most part, but the last round of updates obliterated my minecraft-server install causing the most unpleasant misfortune to my children. Fortunately I had backed up the world, so the builds were saved, but the player data never did fair correct after that causing weird game breakage.
 
There's a few other issues, like things I wanted to play with on this server like VMs, NextCloud, wiki server (for documenting things like configurations, home appliances, etc), and experimenting. Sure, these things exists in FreeBSD's packages and ports, but I'm not as comfortable working with those as I would in a Debian or it's derivatives like Ubuntu or Devuan.
 
What is the culmination of all of this? It was time to fix things. One, it was time to move the OS off of the encrypted drives. I don't want to travel to the basement to let the computer boot. Unlocking the drives with my precious data should be possible via ssh. Booting the OS should be done unattended. This is how it should have been in the beginning, but on a tight budget and not having to experience this before, it wasn't considered. Two new SSDs were procured to house the OS, and the spinning rust (now upgraded to 3TB disks) would only house the data. ZFS on the root is fine, but encryption is reserved for the data. This setup would also afford some more flexibility for trying new OSes. If I wanted to try it on Devuan, or on Ubuntu 20.04 with Wireguard and ZFS in the kernel, it is possible without jeopardizing my data. However, there is one complication to this: GELI. Just like how LUKS is only available for Linux, GELI is only for BSD. That is what leads me to this Journal, stripping GELI encryption from partitions used for ZFS.
 
The first point, you have to have root on the OS and the second, you have to be able to unlock the GELI encryption. I can't help you if you lost your GELI keys/password. Here's the process of what is going to happen. Each drive is removed from the zpool, removed from GELI, and then reattached to the zpool. The process is much the same to replacing a failed disk from a zpool. Here we go.
 
Removing the decrypted drive
Get the layout of the zpool. We'll start with disk 0, where the encrypted zfs partition is on p4.

me@system% zpool status
    pool: zroot
  state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
        still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
        the pool may no longer be accessible by software that does not support
        the features. See zpool-features(7) for details.
    scan: resilvered 776G in 0 days 02:15:09 with 0 errors on Tue May 26 16:47:15 2020
config:

        NAME STATE READ WRITE CKSUM
        zroot ONLINE 0 0 0
            raidz2-0 ONLINE 0 0 0
                ada0p4.eli ONLINE 0 0 0
                ada1p4.eli ONLINE 0 0 0
                ada2p4.eli ONLINE 0 0 0
                ada3p4.eli ONLINE 0 0 0

errors: No known data errors

We can see the four disk decrypted partitions attached. Note the ".eli" after each disk? GELI takes the encrypted /dev/ada0p4 and provides decrypted link to the device at /dev/ada0p4.eli which ZFS is using for its zpool. Let's start with disk 0 and remove that from the zpool.

me@system# zpool offline zroot ada0p4.eli

Now that the disk is offline, we can tell GELI to stop decrypting it which destroys the /dev/ata0p4.eli device.

me@system# geli detatch ada0p4.eli

After that is done, we reattach the disk to the zpool. Note this time it is the partition directly, and not the decrypted volume. This command requires the zpool you are working with, the old device and the new device.

me@system# zpool replace zroot ada0p4.eli ada0p4

This triggers ZFS to resilver the zpool. If you have large drives, this will take some time. For me, it was half a workday or the first installment of the Lord of the Rings if work is a foreign concept. You can use zpool status to check in on the process.

me@system% zpool status
    pool: zroot
  state: DEGRADED
status: One or more devices is currently being resilvered. The pool will
                continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
    scan: resilver in progress since Tue May 26 16:59:15 2020
                3.13T scanned at 617M/s, 2.40T issued at 473M/s, 3.13T total
                594G resilvered, 76.61% done, 0 days 00:27:03 to go
config:

                NAME STATE READ WRITE CKSUM
                zroot DEGRADED 0 0 0
                    raidz2-0 DEGRADED 0 0 0
                        replacing-0 OFFLINE 0 0 0
                            11670088260588674329 OFFLINE 0 0 0 was /dev/ada0p4.eli
                            ada0p4 ONLINE 0 0 0
                        ada1p4.eli ONLINE 0 0 0
                        ada2p4.eli ONLINE 0 0 0
                        ada3p4.eli ONLINE 0 0 0

errors: No known data errors

While this is going on, you might as well modify the boot loader to keep GELI from trying to unlock the disk on boot. So load /boot/loader.conf in your editor of choice and change geli_ada0p4_keyfile0_load="YES" to "NO" to keep GELI from touching it at boot.

me@system# vim /boot/loader.conf
geli_ada0p4_keyfile0_load="NO"
geli_ada0p4_keyfile0_type="ada0p4:geli_keyfile0"
geli_ada0p4_keyfile0_name="/boot/encryption.key"
geli_ada1p4_keyfile0_load="YES"
geli_ada1p4_keyfile0_type="ada1p4:geli_keyfile0"
geli_ada1p4_keyfile0_name="/boot/encryption.key"
geli_ada2p4_keyfile0_load="YES"
geli_ada2p4_keyfile0_type="ada2p4:geli_keyfile0"
geli_ada2p4_keyfile0_name="/boot/encryption.key"
geli_ada3p4_keyfile0_load="YES"
geli_ada3p4_keyfile0_type="ada3p4:geli_keyfile0"
geli_ada3p4_keyfile0_name="/boot/encryption.key"
aesni_load="YES"
geom_eli_load="YES"
geom_eli_passphrase_prompt="YES"
vfs.root.mountfrom="zfs:zroot/ROOT/default"
kern.geom.label.gptid.enable="0"
zpool_cache_load="YES"
zpool_cache_type="/boot/zfs/zpool.cache"
zpool_cache_name="/boot/zfs/zpool.cache"
zfs_load="YES"

After the resilver finished, I rebooted the system to make sure it all came back just fine. Now I'm on my third disk and it looks very promising. When it's done, I'll give an update here.
 
***UPDATE: 2020-05-27 04:45am***
The process is complete an the zpool is good. GELI still asks for a password at boot, but no partitions are getting unlocked and the *.efi devices are not getting created. It is likely a simple edit of the /boot/loader.conf file to make that disappear completely. The "geom_eli_passphrase_prompt="YES"" looks very promising to give me the results I desire, but I'm not likely to boot into BSD much more anyway, so I'm not certain I will spend time on it. The new focus is systemd+wireguard in kernel+zfs in kernel or the alternate sysv.init+dkms module zfs+maybe an older kernel without wireguard. These are the questions. The end result is a Samba server sporting zfs, and a minecraft server, and maybe NextCloud and/or Plex as well. Any thoughts?

So, I'm setting up a RockPro64 to takeover email and apache duties for an aging server in the basement and in the process, I managed to do something incredibly stupid. So, I have the base OS installed and updated and I was setting up my ZFS partitions before installing and setting up services for the server. The plan was to make ZFS datasets on a mirror of SSD disks for /home /var and /etc. I first made the /home dataset, temporarily mounted it on /mnt, rsync'ed the data from /home to /mnt. Then I sudo rm -rf /home/*, unmounted /mnt, and remounted the zpool/home dataset on the /home directory. Everything looked good, so I added that change to the fstab and rebooted. System came up with the zfs dataset mounted on the /home directory. Perfect!

Next, it was time to do the zpool/var dataset. So I mount zpool/var to /mnt and cd into /etc, rsync it all over, unmount the zfs dataset and finally sudo rm -rf *. Next mount the partition...Ah crap, I copied the /etc data on the zpool/var dataset. No big deal, I'll mount the zpool/etc dataset to /etc and copy the data over--this should be no problem. So I attempt to remount the zpool/var dataset to get the /etc data, sudo mount -t zfs zpool/var /mnt.

sudo: you do not exist in the passwd database

Ah crap. I think I'm in trouble. Let me try root and fix all of this, su -.

su: user root does not exist

As you can figure, I'm pretty much screwed and am no longer able to do anything to recover this over ssh. I hope tonight when I get home I can pull the emcc module off of the board and one of the zfs drives, plug them both into the laptop and fix this. I'll probably mount both and rsync the /etc data back to the emmc device. Sure, I can likely reinstall at this point and start over, but I'd rather not have to if I can just pull the files from device and put them on the other.

If anybody thinks they have a way to fix this over the current SSH session, I'm up for suggestions. I'm pretty sure this ssh session is the last time a user can log into the system until /etc is restored.

If I learned anything from this, it is if the command has the potential to hose user logins, do it as root and never with sudo.

**EDIT**

The system is back up. I pulled the emmc module and one of the SSDs from the zpool and mounted them both on my laptop. A quick rsync moved the /etc data from the zfs dataset back to the original /etc directory. All in all, this was good because it gave me a sanity check. Who puts /etc on a separate partition? How do you then read fstab if it is on a different partition than root without doing funny initramfs monkey business? So, if I really want to keep my etc config files backed-up, I either need to cron a rsync job or figure out how I'm booting a SBC with the root on ZFS. I think I could keep /boot on the emmc and move the rootfs to ZFS. I once saw a guide for installing EFI and grub on the emmc and installing Gentoo on a SSD. I could probably do something similar, but I'd have to figure how to do it with the Debian/Devuan tools as I have very little time to keep what will be a hobby/production server up-to-date.

So this is mostly notes for myself if I ever decided to upgrade my hard drives again in my file server. Today I went 4x1TB drives in a Z2 configuration to 4x3TB. Big tip: pay attention to updating the EFI bootloader onto the disk. Otherwise, you'll be kicking your own ass when you replace the last drive and then the system doesn't boot. Kind of why I'm writing this here, I'll have an idea where I should look for documentation when I upgrade the drives again.
 
In this guide we're replacing drive ada1. The old disk is gone and the new one is already installed. Get a look at how the drive should be setup. This command will show all the partitioned drives, we're going to use ada0 as the template. The first time you do this on the system, you'll likely have to manually remove and recreate partition 4 or figure out how to resize the partition. After that, you can copy the partition scheme as shown below.

# gpart show
        40          5860533088      ada0 GPT (2.7T)
        40          2008              - free - (1.0M)
        2048        1600        1 efi (800K)
        3648        448              - free - (224k)
        4096        4194304     2 freebsd-zfs  (2.0G)
        4198400     4194304     3 freebsd-swap (2.0G)
        8392704     5852139520  4 freebsd-zfs (2.7T)
        5860532224  904              - free - (452K)

 
The EFI partition is more or less your mbr. Partition 2 is the zfs pool for your /boot directory. Partition 3 is swap space, and Partition 4 is the big zpool for all of the stuff including the root file system. Don't ask me why I did it this way and expect an intelligent answer. That was 4 years ago. This was my first FreeBSD install, first ZFS install, first EFI install, and this is what i cobbled together from all of the guides I was referencing. It works, so I don't touch it. Theoretically, I can survive two failed disks and also can rollback failed release updates and such with ZFS snapshots. In practice, I know I can make snapshots and yank a disk (as long as another disk happens to have the EFI data needed to make the system boot).
 
Clone the partition table from the good disk (ada0) to new disk (ada1)

# gpart backup ada0 | gpart restore -F ada1

 
Modify the partitions to have the correct drive labels.

# gpart modify -i1 -l efiboot1 ada1
# gpart modify -i2 -l boot1 ada1
# gpart modify -i3 -l swap1 ada1
# gpart modify -i4 -l zfs1 ada1

 
Turn on the swap.

# swapon /dev/ada1p3

 
Check swap status

# swapinfo

 
Replace bootpool device

# zpool replace bootpool /dev/gpt/boot1

 
Check zpool status

# zpool status

 
Encrypt the zfs pool and then attach it.

# geli init -b -e AES-XTS -K /boot/encryption.key -l 256 -s 4096 /dev/ada1p4
# geli attach -k encrypton.key /dev/ada1p4

 
Replace zroot device

# zpool replace zroot /dev/ada1p4.eli

 
Check zpool status

# zpool status

 
Make the new drive bootable

# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1 <<<<====DOESN'T DO SHIT, BECAUSE: _EFI_
# /sbin/gpart bootcode -p /boot/boot1.efifat -i 1 ada1

 
Keep watching the zpool status for the resilvering process to finish before rebooting, shutting down, or off-lining the next disk. The pool size will determine how long that will take. My 1.5TB pool took about 3 hours to resilver each disk.
 
EDIT:
 
If you're replacing disks like I did to expand your pool, you are not done yet! Although the larger disks are installed and the system is using larger partitions, your zpool is not setup yet to use the additional space. First you have to enable the autoexpand feature on your storage pool.
To check the autoexpand value:

# zpool get autoexpand zroot
NAME    PROPERTY    VALUE    SOURCE
zroot   autoexpand   off    default

 
And to change that value to on:

# zpool autoexpand=on zroot

 
After that we online each partition to automatically grow the pool.

# zpool online -e zroot ada0p4.eli
# zpool online -e zroot ada1p4.eli
# zpool online -e zroot ada2p4.eli
# zpool online -e zroot ada3p4.eli

 
And now you are done.

Over the New Years break I finally decided to change OS on my laptop. A little background, the laptop started on Ubuntu 14.04 (12.04 LTS is my preferred, but no longer possible) and then changed to FreeBSD. Frankly, FreeBSD was exciting, unpolished, and ultimately ditched because because my Minecraft frame rates hovered around 4 fps.
 
Due to my work schedule and home responsibilities, stripping systemd from modern Ubuntu didn't seem like a sustainable option. With the recent release of Devuan 1.0, it seemed like a perfect time to give it a try. Why Devuan? well, you know the old phrase, learn Debian and know the Debian derivatives, learn Red Hat and know the Red Hat derivatives, learn Gentoo and know how to compile everything (still compiling?), learn Slackware and know linux. Well, I learned Debian and am most comfortable with it--Devuan fits the Debian without systemd niche. The one caveat, playing with ZFS when testing FreeBSD was pretty neat, and I'd like to continue using it. Unfortunately, Devuan + ZFS is not available strait out of the box. So, I practiced my googlefu and found a few guides to make it happen. Results? I'm writing from chromium on Devuan with root on ZFS. Wifi works, suspend works, music and video works... pretty much everything works. The best part, my Minecraft framerate now averages around 40 fps.
 
Here's my sources:

http://xenotrope.blogspot.com/2017/08/encrypted-zfs-on-root-for-devuan-zfs.html

https://talk.devuan.org/t/quest-for-the-devuan-laptop/600
 
And the steps executed are below. The bulk of it comes from the first link, but that guide is for a server install, so I had to work out a few things to get the desktop going from the install.

Wipe and partition the destination disk.
# wipefs --force --all /dev/sda

# /sbin/parted --script --align optimal /dev/sda mkpart primary 1MiB 100%

# /sbin/parted --script --align optimal /dev/sda set 1 boot on
(so, I cheated here an used gparted from the Devuan live usb. I made two partions, one 16GB swap partion and the rest for my zpool.)
 

Check the partition table:
# /sbin/parted --script /dev/sda p
 

Get the laptop online, then edit your package sources.

# echo 'deb http://auto.mirror.devuan.org/merged jessie-backports main contrib' > /etc/apt/sources.list.d/backports.list
 
That will add the repository with ZFS, but you also need to add contrib and non-free to get your wifi drivers and such. Fire up your editor and add them to your source list.
# vi /etc/apt/sources.list
edit the line:
    deb http://auto.mirror.devuan.org/merged jessie main
to this:
    deb http://auto.mirror.devuan.org/merged jessie main contrib non-free
 

Update and install cryptsetup (in my case, it was already installed).

# time apt update

# time apt install -y cryptsetup
 

Setup your encryption
# cryptsetup luksFormat -h sha512 /dev/sda1 (in my case, sda1 is swap, and thus I used sda2 here. For the rest of this journal, I will copy my source article and use sda1 everywhere.)
# cryptsetup luksOpen /dev/sda1 cryptroot
 

Time to install and compile the kernel modules. You'll need to first het the kernel headers

# time apt install -y linux-headers-$(uname -r)

# time apt-get install -y -t jessie-backports zfs-dkms
 

zfs is only in the jessie-backports repository, so you have to specify it. Watch for errors here, fix them before continuing.
 

Now with zfs-dkms package installed, add it to the kernel.
# /sbin/modprobe zfs
Again, fix any errors before continuing.
 

Time to setup your zpool and datasets.
# zpool create -f -O mountpoint=none -O compression=lz4 -O atime=off -o ashift=12 zdevuan /dev/mapper/cryptroot
# zfs create -o mountpoint=/ zdevuan/root
# zfs create -o mountpoint=/boot zdevuan/boot
# zfs create -o mountpoint=/home zdevuan/home
# zpool set bootfs=zdevuan/root zdevuan
 

With that done, export the pool, import and mount.
# zpool export -a
# zpool import -R /mnt zdevuan
 

Just keep following the guide. If you're using the desktop live usb, you'll have to install debootstrap
# apt-get install -y debootstrap
# time /usr/sbin/debootstrap jessie /mnt /https://auto.mirror.devuan.org/merged
 
The guide notes that --no-check-gpg flag will fubar the process.
 

Next we copy some things from the live USB to the new system.
# cp -v -p /etc/apt/sources.list.d/backports.list /mnt/etc/apt/sources.list.d
# cp -v -p /etc/locale.gen /mnt/etc
 

Here I departed from the guide as I found that debootstrap doesn't install the rich set of applications that differentiate the desktop environment from a server. The most annoying is the lack of wifi, which makes fixing this a pain. Since I didn't feel inspired to run a 100ft ethernet cable from the basement and installing the wifi firmware after my first reboot, I created a list of installed packages from the desktop live USB that I later fed to apt-get after the system is chrooted.
# dpkg-query -f '${binary:Package}\n' -W > /mnt/root/pkg_list
 

Getting back on track, we edit /mnt/etc/fstab for the new system. Remember to add your swap partition here if you created it.

    /dev/mapper/cryptroot / zfs defaults,noatime 0 0
    zdevuan/boot /boot zfs defaults,noatime 0 0
    zdevuan/home /home zfs defaults,noatime 0 0

 

Edit /mnt/etc/crypttab to add the UUID of the encrypted container. I'm using blkid to get the UUID of the cryptroot LUKS container.
# blkid /dev/sda1
# echo 'cryptroot UUID=UUID_HERE /rootkey.bin luks,keyscript=/bin/cat' > /mnt/etc/crypttab
 

Now create a key--this will take some time. Depending on your system, you'll likely to have time to get drive thru coffee from the neighboring zipcode. The original guide author recommended switching to another terminal screen to continue on while dd plugs away.
# time dd if=/dev/random iflag=fullblock of=/mnt/boot/rootkey.bin bs=512 count=4

 

Set the hostname.
# echo myhostname > /mnt/etc/hostname
# echo '127.0.0.1 myhostname' >> /mnt/etc/hosts
 

I copied the interfaces file from the USB stick, the author did otherwise.
# cp -v -p /etc/network/interfaces /mnt/etc/network/interfaces
 

Mount the system directories.
# cd /
# for i in /dev /dev/pts /proc /sys; do mount -B $i /mnt/$i; done
 

Chroot into the new system. Do some basic setup, and then install zfs into the new system.
# chroot /mnt /bin/bash --login
# passwd
# passwd -u root
# dpkg-reconfigure tzdata
# ln -sf /proc/self/mounts /etc/mtab
# apt update
# apt install -y locales kbd
# time apt install -y cryptsetup linux-image-amd64
# time apt install -y linux-headers-$(uname -r)
# time apt-get install -y -t jessie-backports zfs-dkms zfs-initramfs
 

If you went out for coffee, your LUKS key should be done by now. If so, create the crypto keyfile hook fo rthe initramfs.
# cryptsetup luksAddKey /dev/sda1 /boot/rootkey.bin
# chmod 0 /boot/rootkey.bin
# vi /etc/initramfs-tools/hooks/crypto_keyfile
Add the following lines to the crypto_keyfile:
    #!/bin/sh
    cp -p /boot/rootkey.bin "${DESTDIR}"
 

Set the script as executable.
# chmod +x /etc/initramfs-tools/hooks/crypto_keyfile
 

Symlink the crypto device into /dev. If you ever want to update your kernel, checkout the original author's other howto on adding a udev rule for automating this. Otherwise, you're expected to never, ever update your kernel.
# ln -sf /dev/mapper/cryptroot /dev
 

Since Devuan Jessie doesn't yet have a ZFS-compatible bootloader, borrow one from Devuan testing and then return it. FYI, it's called Ascii.
# cp -v -p /etc/apt/sources.list /etc/apt/sources.list.orig
# echo 'deb http://auto.mirror.devuan.org/merged ascii main' >> /etc/apt/sources.list
# apt update
# time apt install -y grub-pc/ascii
# mv /etc/apt/sources.list.orig /etc/apt/sources.list
 

Edit your grub config file.
# vi /etc/default/grub
 

Make the following changes to the grub file:

    -GRUB_CMDLINE_LINUX_DEFAULT="quiet"
    -GRUB_CMDLINE_LINUX=""
    +GRUB_CMDLINE_LINUX_DEFAULT="boot=zfs"
    +GRUB_CMDLINE_LINUX="cryptdevice=UUID=UUIDHERE:cryptroot"
    +GRUB_ENABLE_CRYPTODISK=y
 

Hopefully you can now build your initramfs and install grub without any errors.
# update-iniramfs -u -k all
# update-grub
# grub-install /dev/sda
 

With that done, it is time to install those packages to make your system run like the desktop live USB.
# time xargs -a <(awk '! /^ *(#|$)/' "/root/pkg_list") -r -- apt-get install
 

Pay attention to what installs and what isn't in the repositories. The first time through I had no wifi drivers. I also didn't add the non-free repository, so it was an easy fix once I figured out what happened. Obviously, there will be some redundancy and some undesired packages. Feel free to edit the pkg_list file to your liking before piping it to apt-get.
 

When this is done, add users, groups, configure sudo, etc. Once you're finished, exit the chroot.
# exit
 

Set the mountpoint /boot and /home to "legacy" so they will mount at boot time.
# zfs set mountpoint=legacy zdevuan/boot
# zfs set mountpoint=legacy zdevuan/home
 

Kill off the processes keeping you from unmounting your zpool. If you skip this, you'll be forced to manually import your zpool from single-user mode.
# killall irqbalance
# umount /mnt/sys
# umount /mnt/proc
# umount /mnt/dev/pts
# umount /mnt/dev
# zfs umount -a
# zpool export -a
# halt -p
 

Liberal use of lsof | grep /mnt/whatever to find the process that is using the mount point. Fire up your PID assassin of choice and kill those processes preventing you from unmounting your zfs datasets.
 

At this point, your machine is off. Remove your live USB media and boot the system. Here's your no compromise system with apt, zfs, and no systemd on your desktop. Next up...figuring out hibernation with encrypted partitions and zfs because suspend drains my old, anemic battery in about 12 hours.

 

Let me know if this guide was any help.

Cheers!

I admit that at times I'm easily entertained. One regular amusement of mine are the lines spouted out by the fortune application whose output can be seen on the bottom of each soylentnews page. The quips and quotes often get a chuckle or smile from me. Some have struck me enough that I've copied them down for reference. Here are a few of those that I've thought entertaining enough to write down:

A candidate is a person who gets money from the rich and votes from the poor to protect them from each other.

#if _FP_W_TYPE_SIZE < 32 #error "Here's a nickel kid. Go buy yourself a real computer." #endif -- linux/arch/sparc64/double.h

To hell with the Prime Directive;
Let's KILL something!

And my personal favorite:

Human beings were created by water to transport it uphill.

If you have them, share your favorites below.

Orig post

The Church of the Banker
Articles of Incorporation

Chapter 1
In the beginning there was nothing.¹ᵛ¹ Then the Bank said, "Let there be a Loan."² From that Loan, the Banker created the heavens and the earth, and it was good.³ The banker separated the Light from the Dark and created Power and Profits, and it was good.⁴ On the 5th day, the Banker created Money, and it was good.⁵ On the sixth and seventh day the Banker vacationed in the Bahamas.⁶ In the end, the Loan will come Due.⁷ The Banker will cast Judgement against the Creditworthy and Uncreditable.⁸ If He finds that the Debt is not paid in full, the Banker shall call upon the Repo-man to take what is good and leave the impoverished Uncreditable in the Dark.⁹ And there will be much gnashing of teeth.¹⁰ But the faithful Creditable shall be worthy and be rewarded with young supermodels, and mansions, and yachts, and a Loan of their very own.¹¹ They shall known as the Banker's chosen people and be called the 1%.¹²

The Banker's one and only son, born in poverty, becomes a home furniture manufacture and entrepreneur.¹³ At 33 years of age, he resigned as CEO to become an economics teacher and prophet.¹⁴ He is crucified in bankruptcy court, and in three days time, he rises again as the chairman of the Federal Reserve to lead the 1% to maximum profits.¹⁵ Whoever tithe the most and believith in him shall not perish, but have everlasting wealth.¹⁶

This page was generated by a Throng of Overworked Soylents for DECbot (832).

I thought it was fairly accurate. I reloaded the page to ensure it was randomly generated and not changed to static text by a Throng of Overworked Soylents after the latest round of Rehash updates. It looks to be dynamic like always, unless they're doing a good job of changing it every time I hit the refresh button.

*click* *click* *clickclickclick*

A really good job.

This morning I wake to my daughter throwing up all over my pillow.
File under: "when you known today is going to be a good day."