For my daily driver I’m fortunate enough to have mirrored ZFS setup, my secondary machine has only a single SSD slot. While that makes mirror setup unproductive, I still want to use ZFS. Yes, it cannot automatically correct errors but it can at least help me know about them. And that’s before considering datasets, quotas, and beautiful snapshots.
For this setup I will use LUKS instead of the native ZFS encryption. Computer is fast enough that I don’t notice difference during daily work and total encryption is worth it for me.
As before, if you are beginner with ZFS, you might want to use Ubuntu’s built-in ZFS installatiion method. It will result in similar enough setup but without all these manual steps.
Why do I use this setup? Well, I like to setup my own partitions and I definitely love setting up my own datasets. In addition, this is the only way to make Ubuntu do a very minimal install. Lastly, I like to use hibernation with my computers and setting this during manual installation is often easier than sorting issues later.
With preamble out of the way, let’s go over all the steps to make it happen.
The first step is to boot into the USB installation and use “Try Ubuntu” option. Once on the a desktop, we want to open a terminal, and, since all further commands are going to need root access, we can start with that.
sudo-i
Next step should be setting up a few variables - disk, hostname, and username. This way we can use them going forward and avoid accidental mistakes. Just make sure to replace these values with ones appropriate for your system.
I want to partition disk into 4 partitions. The first two partitions are unencrypted and in charge of booting (boot + EFI). While I love encryption, I almost never encrypt the boot partitions in order to make my life easier as you cannot seamlessly integrate the boot partition password prompt with the later password prompt. Thus encrypted boot would require you to type the password twice (or thrice if you decide to use native ZFS encryption on top of that). Third partition is largest and will contain all user data. The last partition is actually swap that we need for hibernation support. Since we’re using SSD, its position doesn’t matter (on the hard drive you definitely want it way ahead) so I put it these days at the end to match my mirrored ZFS setup.
All these requirements come in the following few partitioning commands:
The next step is to setup all LUKS partitions. If you paid attention, that means we need to repeat formatting a total of 2 times. Unless you want to deal with multiple password prompts, make sure to use the same password for each:
Since creating encrypted partitions doesn’t mount them, we do need this as a separate step. I like to name my LUKS devices based on partition names so we can recognize them more easily:
Finally, we can set up our ZFS pool with an optional step of setting quota to roughly 85% of disk capacity. Since we’re using LUKS, there’s no need to setup any ZFS keys. Name of the pool will match name of the host and it will contain several datasets to start with. Most of my stuff goes to either Data dataset for general use or to VirtualBox dataset for virtual machines. Consider this just a suggestion and a good starting point, adjust as needed:
At this time, I also often disable IPv6 as I’ve noticed that on some misconfigured IPv6 networks it takes ages to download packages. This step is both temporary (i.e., IPv6 is disabled only during installation) and fully optional:
Now we’re ready to onboard the latest Linux kernel. I find that hwe is a nice compromise between using generic and oem but you can use whichever you or your hardware prefers:
To mount all those partitions, we also need some fstab entries too. ZFS entries are not strictly needed. I just like to add them in order to hide our LUKS encrypted ZFS from the file manager:
On systems with a lot of RAM, I like to adjust memory settings a bit. This is inconsequential in the grand scheme of things, but I like to do it anyway. Think of it as wearing “lucky” socks:
aptinstall--yes zfs-initramfs cryptsetup keyutils \
grub-efi-amd64-signed shim-signed
update-initramfs -c-k all
And then, we can get grub going. Do note we also set up booting from swap (needed for hibernation) here too. If you’re using secure boot, bootloaded-id HAS to be Ubuntu:
My alpine setup is modest and pretty usual. I installed it back in 3.19 times with the main partition using Ext4 and all data on ZFS. Why didn’t I install the root file system on ZFS? Well, I needed the machine quickly and installing using default settings instead of messing with ZFS was a faster way to do it. And, as it often happens, temporary installation became permanent.
As Alpine Linux is on 3.20.2 now, I felt my system might do well with a bit of upgrading. It’s easy after all. I just changed my /etc/apk/repositories ti point toward the latest stable repositories:
And followed this with standard update-upgrade dance:
apk update
apk upgrade
One short reboot later and my system was upgraded! Oh, yeah, and my data was gone. What gives?
Fortunately for my blood pressure, I quickly determined that my data was not really gone but just hiding as my ZFS modules weren’t loaded and all ZFS commands advised me to do modprobe zfs. I followed the same only to be greeted by an error message:
modprobe: ERROR: could not insert zfs: Invalid argument
I tried removing and readding packages, fixing them, and making many more small adjustments. Pretty much any command that the internet had to offer, I tried. But all those things always brought me back to the same cryptic message.
At the end, I decided to fall forward. If one upgrade broke the system, maybe another upgrade would solve it. And yes, someone smarter would probably go with a downgrade instead, but I don’t roll that way. It was either upgrade or reinstall for that naughty server.
Where do you upgrade from 3.20, you ask? Well, there’s always an “edge”. And upgrade to it was again just a minor change to /etc/apk/repositories followed by update/upgrade:
Wouldn’t you know it, edge was fine and my ZFS was buzzing along once more.
But, while I didn’t mind reinstalling this machine, keeping it on edge long-term (as my “temporary” projects tend to get), didn’t really give me a level of confidence I wanted. So I decided either 3.20 would work or I would reinstall it fully now I knew for sure my data was fine.
How do you downgrade to 3.20? Well, the first step is to change /etc/apk/repositories yet again:
For disabled icons in Avalonia toolbar, you can go two ways. One is just using an external tool to convert your existing color icons into their color-less variant and have them as a completely separate set. The one I prefer is to actually convert images on demand.
As I’m currently playing with this in Avalonia, I decided to share my code. And it’s not as straightforward as I would like. To start with, here is the code: As I’m currently playing with this in Avalonia, I decided to share my code. And it’s not as straightforward as I would like. To start with, here is the code:
publicstaticBitmapBitmapAsGreyscale(Bitmap bitmap){var width = bitmap.PixelSize.Width;var height = bitmap.PixelSize.Height;var buffer =newbyte[width * height *4];var bufferPtr = GCHandle.Alloc(buffer, GCHandleType.Pinned);try{var stride =4* width;
bitmap.CopyPixels(default, bufferPtr.AddrOfPinnedObject(), buffer.Length, stride);for(var i =0; i < buffer.Length; i +=4){var b = buffer[i +0];var g = buffer[i +1];var r = buffer[i +2];var grey =byte.CreateSaturating(0.299* r +0.587* g +0.114* b);
buffer[i +0]= grey;
buffer[i +1]= grey;
buffer[i +2]= grey;}var writableBitmap =newWriteableBitmap(newPixelSize(width, height),newVector(96,96), Avalonia.Platform.PixelFormat.Bgra8888);using(var stream = writableBitmap.Lock());
Marshal.Copy(buffer,0, stream.Address, buffer.Length);return writableBitmap;}finally{
bufferPtr.Free();}}
Since Avalonia doesn’t really expose pixel-level operations, first we need to obtain values of all the pixels. The easiest approach I found was just using the CopyPixels method to get all the data to our buffer. As this code in Avalonia is quite low-level and requires a pointer, we need to have our buffer pinned. Anything pinned also needs releasing, thus our finally block.
Once we have raw bytes, there is just a matter of figuring out which byte holds which value, and here I suspect that pretty much anybody will use the most common RGBA byte ordering. It’s most common by far, and I would say it will be 99% what you end up with.
To get gray, we can use averages, but I prefer using slightly more complicated BT.601 luma calculation. And yes, this doesn’t take into account gamma correction; nor is it the only way to get a grayscale. However, I found it works well for icons without much calculation needed. You can opt to use any conversion you prefer as long as the result is a nice 8-bit value. Using this value for each of RGB components gives us the gray component. Further, note that in code above, I only modify RGB values, leaving the alpha channel alone.
Once the bytes are in the desired state, just create a WritableBitmap based on that same buffer and with the same overall properties (including 32-bit color).
It all started with Avalonia and a discovery that its clipboard handling under Linux doesn’t include the primary buffer. Since I was building a new GUI for my password manager this was an issue for me. I wanted to be able to paste directly into the terminal using Shift+Insert instead of messing with the mouse. And honestly, especially for password prompts, having a different result depending on which paste operation you use is annoying at best. So, I went onto building my own X11 code to deal with it.
The first idea was to see if somebody else had written the necessary code already. Most useful source for this became mono repository. However, its clipboard support was intertwined with other X11 stuff. It was way too much code to deal with for a simple paste operation but I did make use of it for figuring out X11 structures.
DisplayPtr = NativeMethods.XOpenDisplay(null);
RootWindowPtr = NativeMethods.XDefaultRootWindow(DisplayPtr);
WindowPtr = NativeMethods.XCreateSimpleWindow(DisplayPtr, RootWindowPtr,-10,-10,1,1,0,0,0);
TargetsAtom = NativeMethods.XInternAtom(DisplayPtr,"TARGETS",only_if_exists:false);
ClipboardAtom = NativeMethods.XInternAtom(DisplayPtr,"PRIMARY",only_if_exists:false);
Utf8StringAtom = NativeMethods.XInternAtom(DisplayPtr,"UTF8_STRING",only_if_exists:false);
MetaSelectionAtom = NativeMethods.XInternAtom(DisplayPtr,"META_SELECTION",only_if_exists:false);
EventThread =newThread(EventLoop){// last to initialize so we can use it as detection for successful init
IsBackground =true,};
EventThread.Start();
This code creates a window (XCreateSimpleWindow) for an event loop (that we’ll handle in a separate thread) and also specifies a few X11 atoms for clipboard handling.
In order to set clipboard text, we need to tell X11 that we’re the owner of the clipboard and that it should use our event handler to answer any queries. I also opted to prepare UTF-8 string bytes so we don’t need to deal with them in the loop.
There are two subrequests possible here. The first one for the other application asking for text formats (i.e., TARGETS atom query). Here we can give it UTF8_STRING atom that seems to be universally supported. We could have given it more formats but I honestly saw no point in messing with ANSI support. It’s 2024, for god’s sake.
After we told the terminal what formats we support, we can expect a query for that data type next within the same SelectionRequest event type. Here we can finally use previously prepared our UTF-8 bytes. I opted to allocate a new buffer to avoid any issues. As in the previous case, all work is done by setting the property on the destination window (XChangeProperty) with XSendEvent serving to inform the window we’re done.
And that’s all you just need in order to support SetText. However, it seemed like a waste not to implement GetText method too.
The code for retrieving text is a bit more complicated since we cannot retrieve text directly. We must ask for it using our UTF8_STRING atom. However, we cannot read the clipboard text directly but only via our event loop. So, we need to wait for our AutoResetEvent to signal data is ready before returning.
In the event loop, we need to add an extra case for SelectionNotify event where we can handle reading the data and signaling our AutoResetEvent.
case NativeMethods.XEventType.SelectionNotify:{var selectionEvent = @event.xselection;if(selectionEvent.target != Utf8StringAtom){continue;}// we ignore anything not clipboardif(selectionEvent.property ==0){// nothing in clipboard
BytesIn =[];
BytesInLock.Set();continue;}var data = IntPtr.Zero;
NativeMethods.XGetWindowProperty(DisplayPtr,
selectionEvent.requestor,
selectionEvent.property,long_offset:0,long_length:int.MaxValue,delete:false,0,// AnyPropertyTypeoutvar type,outvar format,outvar nitems,outvar bytes_after,ref data);
BytesIn =newbyte[nitems.ToInt32()];
Marshal.Copy(data, BytesIn,0, BytesIn.Length);
BytesInLock.Set();
NativeMethods.XFree(data);}break;
With all this code in, you can now handle primary (aka, middle-click) clipboard just fine. And yes, the code is not fully complete, so you might want to check my X11Clipboard class, which not only provides support for primary but also for a normal clipboard too. E.g.:
As I switched quite a lot of my daily work to Linux, I kept printing and scanning to the Windows. It’s not that my Brother MFC-J475DW had no Linux drivers - they are available. However, since the printer is quite an old beast now, you’ll notice that the official instructions call for installing i386 packages. Guess what I don’t want on my system?
So, I used my new installation as an opportunity to adjust procedure a bit and do as minimal setup as possible.
When it comes to printer packages, there is some good news. While packages do identify as 32-bit, they are actually agnostic and they don’t actually need i386 architecture installed. We just use dpkg to install them:
With those, your printer is installed, assuming you’re happy with the default settings. You can access CUPS interface at http://localhost:631/printers and adjust it further from there. However, since I use it via a network, this will not work. I need to adjust its IP address (the easiest way to do it is by deleting and recreating the printer):