To Hop or Not-To-Hop that is the question (#100DaysToOffload Day11)

Todays post is about my itch to distro hop. Back a few years ago it was something i did almost daily. Then i found Gentoo. I stuck with it for a few months then switched to Funtoo. 2 reasons prompted that switch.

1. It used Git instead of Rsync for ebuild tree. Much faster sync

2. Linux should be Fun-Too

I stuck with Funtoo for quite a while. Then they where going to do away with 32-bit support all together this meant that Steam would no longer work unless i setup a chroot or something which i felt was too much trouble(for some reason...looking back i should have probably stuck with it). They now have an “official” solution but only for Nvidia cards so no help to me. So after Funtoo i went to Arch it was an old faithful type choice for me. I had used Arch on and off during my crazy Hopping years so knew it well. I stuck with Arch when i get my new PC just over a year ago. A few month ago i made the lateral jump to Artix which is just Arch without systemd.

Now i'm getting the itch for something different again. I don't know if it's just something different or if it just a “Everything works lets break something...” type mood. I posted about this on Pleroma a few weeks ago and someone suggested i switch DE to see if that helps. I did that switched to Qtile. It helped at the time but now i'm back at feeling like i want something else...

I think part of my itch would require going back to something Source based like Gentoo/Funtoo. Steam support is important as i do game. I don't want to dual boot because i don't want to have to commit disk space to each distros then be locked into that choice.

I think in the end i'm going to end up going to Gentoo. It still has full 32-bit support which means Steam will just work. They even provide a nice guide for setting it up in a Chroot which i might do. It also comes with OpenRC by default which i like. I'm going to think on it some more the next few days and this might be my weekend project.

Now to address something. I embarked on this #100DaysToOffload journey but somedays i just can't find anything to write/post about. Instead of stressing about it i either skip that day or post a silly/insignificant post. In situations like that what should i do? Pleroma Poll

Also i know i should really just do this for myself in a way but sometimes it's hard to justify the time when i get little views/comments. Comments can be made by replying to this post on Pleroma/Mastodon. This is a new feature of WriteFreely so maybe most don't know about it. It now support Activitypub mentions. That's why i tag myself. Then if you reply i will get mentioned and we can have interactions about the post in question.

Anyways that is all for today.

Untill tomorrow. Stay Safe!!

@mgrondin@youdabomb.social

#Tech #Linux

Until next time. Stay safe!

G @mgrondin@youdabomb.social

So long Systemd!

So I, like probably a fair chunk of you, have always felt like systemd was forced onto me. I did not ask for a new init system. Systemd in may ways is doing more than what an init system should do. In some ways that's great but an init system should just init. I was finding myself getting used to it after the last few years(had avoided it till then). Probably partly due to the fact that it EVERYWHERE. I was actually starting to like it even. I finally had enough and woke up.

Yesterday I read an article about the systemd devs trying to force a change on the linux kernel because they did not want to change how systemd worked. Now it turns out that this article was like 6 years old but still it highlighted the fact that systemd is trying to be more than what it is. Kernel is king! Everything else comes after.

So this morning I migrated from Arch Linux to Artix Linux. It was fairly smooth other than a few issues related to having root on encrypted partition but those where mostly my doing in trying to go too quickly. No format/reinstall and no more systemd!

My views may be ill explained but that's it for this post.

Have a great day

G

#linux #nosystemd #tech

Until next time. Stay safe!

G @mgrondin@youdabomb.social

Migrate all the things!!

As i stated in my previous post my primary harddrive is failing on me. To be proactive i am replacing it before it fully dies.

So this will be a somewhat technical post where I will outline the steps I took to migrate to my new HDD. Some of these steps will be specific to my setup but most could be applied to other situations. Hope you find some of this useful or at least informational.

First some details on the setup. I use BTRFS as my filesystem on all my drives. BTRFS provides a subvolume functionality. Subvolumes are similar to partitions in which they can be mounted/accessed independently from the main/root of the filesystem. So my old drive was setup with the following subvolumes:

Subvolume	Description
@Home	This contains my Home partition
@Storage	This contains my primary storage (Hold Downloads,Wallpapers and other general data)
@HomestBU	This was used to make backups(More will be explained on how to handle backups with BTRFS subvolumes/snapshots)

This same layout will be replicated on the new drive later.

To avoid any data loss I had moved my @Home subvolume to my raid5 array(Called Storage2) which typically holds my media files and my @Storage subvolume to my external storage device(called Storage3) that normally holds my backups. Now the task will be to move those subvolumes to the new harddrive. So lets get on with it.

This is the drive I am migrating stuff to

Lets begin the migration.

Since I have all my storage encrypted the first step is to setup the encryption container. This is done by issuing the following cammand:

cryptsetup -v --type luks --cipher anubis-xts-plain64 --keysize 640 --hash whirlpool --iter-time 5000 --use-random -d /etc/homest luksFormat

Lets breakdown that command a bit shall we

Option	Desctiption
-v	This simply makes the cryptsetup command output mor detailed information about what it does
--type luks	This instructs cryptsetup that we are working in luks mode instead of plain mode (See here for an explanation of the differences between plain and luks mode.)
--cipher anubis-xts-plain64	This is defining the cipher to be used for the encryption operation. I always use a cipher that is not as mainstream. In this case i am using the anubis cipher. I like this cipher for a few reasons. One of them being that it is named after an egyptian god and the creator has stated that anyone who breaks it will be cursed.
--keysize 640	This defines the size(in bits) of the key used for encryption. The bigger the key the stronger the encryption. Anubix has a maximum key size of 320 but since the xtx cipher mode splits the key in 2 we specify 640 here.
--hash whirlpool	This defines what hash function(default sha256) will be used the hash the passphrase.
--iter-time 5000	This defines how long(in miliseconds) cryptsetup will spend processing the keyphrase. Default is 1 second I make it go for 5.
--use-random	This define the source used for the generation of random numbers used by the format process. Choices are urandom or random. I always use random as it produces a more random result
-d /etc/homest	This defines a keyfile to use instead of prompting for a passphrase. That key file is a giant string of random characters
luksFormat	This just says to format the device that follows
/dev/sdxY	The device to format

Now that the encrypted container is ready we can open it to use it:

cryptsetup open -d /etc/homest /dev/sdxY homest

Now we can format the container with a filesystem:

mkfs.btrfs /dev/mapper/homest

And mount it:

fstab entry

/dev/mapper/homest                              /mnt/btrfsroot           btrfs           compress=zlib,space_cache=v2       0 0

mount /mnt/btrfsroot

Starting with my @Storage subvolume we will now move it to the new drive

First we create a read-only snapshot of the subvolume:

btrfs subvol snap -r \@Storage/ \@Storage.migrate

A snapshot is like a picture of the data currently in that subvolume.

Now we send it over to the new drive:

btrfs send -vvv \@Storage.migrate/ | btrfs receive -vvv /mnt/btrfsroot/

Once this is complete we update the fstab entry to mount the subvolume from it's new location:

/dev/mapper/homest                              /media/Storage  btrfs           compress=zlib,space_cache=v2,subvol=@Storage    0 0

Notice how this entry is similar to the previouse with the differences being the mountpoint(/media/Storage) and that we specify the subvolume to mount.

Now we do the same thing with the @Home subvolume.

First we create a read-only snapshot of the subvolume:

btrfs subvol snap -r \@Home/ \@Home.migrate

Now we send it over to the new drive:

btrfs send -vvv \@Home.migrate/ | btrfs receive -vvv /mnt/btrfsroot/

Once this is complete we update the fstab entry to mount the subvolume from it's new location:

/dev/mapper/homest                              /Home  btrfs           compress=zlib,space_cache=v2,subvol=@Home    0 0

Now the subvolumes on the receive side(now in /mnt/btrfsroot) are still in read-only mode which wont work. To resolve that we simply take a read-write snapshot of the subvolume:

btrfs subvol snap \@Home.migrate \@Home btrfs subvol snap \@Storage.migrate \@Storage

And That is it. Migration complete. All that is left to do is reboot to start using the new drive. Hope you maybe found this post informational.

Have a great day.

G

#Tech #Migration #Linux #BTRFS

Until next time. Stay safe!

G @mgrondin@youdabomb.social