Crash!

‘I will never take you for granted again, good to see you buddy.’

I said to my wallpaper as it finally lit up to greet me, after an entire evening of black screens and white text.

I’d done some tinkering, and I broke things – quite unnecessarily, with hindsight. It all started late lastnight, I had the wise idea of updating my Linux kernel: for the fun of it. Didn’t particularly need doing, it was working just ok – but I thought it just probably needed doing.
It didn’t go to plan, and it broke my WiFi dongle support – I’d done a bit of digging, and the 5.x kernel does cause problems with Realtek adapters, which is what this was, and now everything is pretty much the same, except my WiFi is borked.

---

“Command shells are like Gremlins, don’t feed them after midnight.”

My mate Matt, years ago.

---

My only option at that small hour of the morning was to haul everything downstairs, and plug into my router – or go to sleep. I tried to do the responsible but very out-of-character thing and forget about it for the night (admittedly, getting up a couple of times to try something, and going back to bed).
I bought a new adapter from Argos on the way home from work today, a different make and hoped that that would just plug in and function straight away. It wasn’t detected at all.
So… I had to bring everything downstairs and plug into the router after all that.

I carried on the updates with: $ sudo dpkg --configure -a

To make sure the update I’d ran the night before had all been completed successfully before continuing the upgrade (an upgrade will include the most updated drivers, right?).

I completed the update and rebooted, and was presented with:

I booted from up from a Linux Mint USB drive, and from here was able to at least access my system files, only my drive is encrypted – so I couldn’t just browse straight to them and copy them somewhere. I had to decrypt my drive first, and mount it as an accessible filesystem.

I did this by running the following commands:
cryptsetup luksOpen /dev/sda3 sda3_crypt
vgchange -ay
mount /dev/mapper/mint--vg-root /mnt
mount /dev/sda2 /mnt/boot
mount -t proc proc /mnt/proc
mount -o bind /dev /mnt/dev

The above commands will firstly decrypt the contents of your hard drive, change the Volume Group to modifiable, and mount the filesystem into folders in which you are able to access from the Live USB environment, by navigating to the /mnt folder

One problem with how I set this memory stick up, is that it doesn’t remember anything after I reboot (and there were a lot of reboots!) – so it’s very Groundhog Day when it loads back up, I have to go and find the same posts (this was useful) online, run the same commands, not be able to decrypt my home folder to back anything up, all in the back of my mind is:

I know, I last put my savefile on Github 6 days ago… nearly a weeks work.

After running the above commands, I was then able to login to the encrypted drive as if I was an administrator and use a command shell to try and bring it back to life. I used:

sudo chroot /mnt to access the contents of the drive, change system files in order to get the drive up and running again, reboot. Repeat.

And to (hopefully) save you the hours I spent figuring this out, I’ll show you what worked for me:

/etc/fstab

Before, in my /etc/fstab file, the first line of each of the drives (sda#) was set to its corresponding UUID identifier, we can see which one is which by looking at the blkid output above, so when it loaded up – it was looking for UUID=xxxxxxxx and not being able to find it.

If you look on the left of the image below, the drive is located at /dev/mint--vg-swap, whereas in the screenshot above – it refers to it as /dev/mapper/mint----vg-root-swap. They’re different.

This is only my swap partition, and I’m not too bothered about that, it still works despite the slight discrepancy, but it also applied the same mismatch to my entire file system and could not find it, which did cause problems (and panic).

/etc/fstab (fixed)

This is what worked for me, obviously yours will be different depending on your setup- so compare with blkid (or gparted if you would like something a little more visual than a commandline)

I changed them to their hardware addresses, knowing that it would always be able to find them at that location, and I’m back!
…but my WiFi still doesn’t work.

Backup

I did try to backup my progress, but my .blend savefile now exceeds 100mb: it’s too large to store on Github due to their filesize limit.
In future, I’ll be using Github more for the development side of things, 3D assets (much smaller files!) – and will be storing the ever-growing 3D savefile on this server – but for now, there’s a copy on Google Drive – more for my sake than anyone elses, but if you want to have a look – feel free!