Linux reinstalling

Intro and nostalgia

For no very good reason (maybe just a consequence of extended lock-down!) I got the urge to look again at my GNU/Linux setup. For the longest time I’ve been using Debian Stable on pretty much everything. I bought a couple of printers lately, one of which had some problems with the cupsfilters version that’s included in stable, and that started me looking at other options.

I used Debian testing for a long time before, without much difficulty or problem, and it generally has very up to date software.

Then I took a look at SuSE (or OpenSuSE as it is now called). This is a big nostalgia trip for me as SuSE Linux was the first Linux distribution I bought. This would have been back around 1999. The first unix-type system I installed was FreeBSD, because there was a guy in Dublin with a bunch of sets of FreeBSD CDROMS (I think it was a 4 disk set, so had lots of software on there, handy when your internet access is 56kbps dialup). I honestly don’t remember why I made the move to GNU/Linux, but I think it was because of a hardware support / graphics card issue. The big selling points for SuSE were: 1. I could find it for sale in a bookshop in Dublin 2. It came with lots of software! I think it was SuSE Linux 6.3, and there could have been like 6 CD-ROMs. 3. It had a great manual: an actual printed paper manual that covered lots of general GNU/Linux information as well as the specifics of SuSE (so both how to do things via YAST and how to do things on command line. I’m very pleased to see that SuSE still has a great bookshelf of documentation, and the Reference Guide looks like the closest equivalent to the old in-box manual.

This is a long way round to saying I didn’t end up going with SuSE this time! In installed Leap 15.1 (even though it actually doesn’t have the version of cupsfilters that I want, but 15.2 will be out in under a month, and upgrade should be easy).

It was tricky to get the partitioning setup that I wanted via the installer (root and home as logical volumes on a LVM volume group, with /boot and /boot/efi both larger than default and as regular partitions, though it did eventually work.

Sound was (for whatever reason) not detected, even though I’m using a pretty pedestrian and not brand new motherboard, with common-enough Realtek audio.

I did a couple more reinstalls, trying out the current Leap 15.2 Release Canddiate, and also tumbleweed (via tumbleweed installer, and via first 15.1 and then upgrade). Again a few niggles (sound, but also the default terminal having an odd glitch where the cursor was always a few characters to the right of where the characters being typed would appear.

YAST, which I loved all those years back, now was more of a burden given that I wasn’t sure whether to go under the hood to fix something like the sound issue, or to try to resolve it via YAST.

In the end I decided to go back to Debian for now, but to leave space on the new SSD for another try at SuSE at some point in the future (perhaps after 15.2 lands).

Debian Install

My goal was to install Debian Testing onto a new 500GB SSD I had bought for this purpose (so I could leave my working installation intact, since it’s a machine I need for daily work.

Target:

• Debian Testing (Bullseye) installation
• Partitioning (GPT and LVM)
  • 500 GB SSD
  • 5 GB /boot
  • 1 GB /boot/efi
  • 465 GB LVM Volume Group (VG)
    • 50 GB for /
    • 100 GB for /home
    • Free space for growth or for further installations
  • Free space on disk, can later create PV to grow the VG above, or can use for partitions that need to be outside of LVM (like the /boot partition already)

Install Debian Stable (Buster)

This is generally very straight-forward. Since you’re going to immediately upgrade it, it’s better to do a minimal install (no desktop environment) as long as you’re comfortable to work from the command line.

Some issues did present however, probably because of what I was trying to achieve:

• If you have LVM configurations on your hard drive already, you won’t be able to recreate them or change them within the installer as they will already have been activated. I had this due to having gone through the installs with OpenSuSE already.

  • The fix that I found was to go via installer or rescue system to a terminal and use the lvm tools in the background to destroy the volume group. Be careful that you do this to the right groups/volumes if you have more than one setup (and I do).
  • Then restart the installer, and work from scratch again, using partitioner to create according to what you want.

• Using the guided partitioner (I wouldn’t normally use this, but was having problems with getting bootloader to work with my first expert partitioner trials, and wanted to see how the automated config would look) you either use all free space, or entire disk. If you pick LVM, the system will automatically setup /boot and /boot/efi for you, but the sizes are very tight (250MB or something for /boot). I’m more than happy to throw a few GB at these partitions in the interest of not needing to worry about space there when I have a few kernels installed, and to have somewhere to store e.g. a rescue-disk bootable image.

  My basic fix was to go back to the expert partitioner. Doing that the sequence I followed was:

  • Do a rescue disk boot and delete LVM logical volumes and volume groups
  • Re-Boot to installer and partitioner
  • Delete all partitions on the target drive
  • Create EXT4 partition (e.g. 5GB), and pick /boot as mount point
  • Create EFI BIOS partition (e.g. 1GB, note you don’t need to pick mount point)
  • Create a partition for the LVM volume, leaving some free space at end of disk in my case
  • Then go to the LVM management options (which are up at top of the partitioner screen). It will want to write the partition table to the device, which is fine (double check you’re doing what you think you’re doing though!).
  • Start creating the logical volumes on the new volume group as you want, pick file-systems (e.g. EXT4) and mount points (/ and /home in my case).

• Booting: unfortunately, my installations always failed because of not being able to install the bootloader. This was irrespective of whether I did expert or guided/automatic partitioning (but always with LVM). You can skip that and finish the installation, but of course it won’t be bootable. I didn’t want to rely on the bootloader from my pre-existing Debian installation. I don’t know exactly why this happened, but found a fix, after reading through this bug report:

  • Do the installation as you would normally do
  • When bootloader fails to install, skip that step and continue on
  • Reboot
  • Use your BIOS boot menu to boot again from the installation medium, but go to “Advanced” and rescue system. During boot you’ll pick your root-device (an LVM logical volume) and be asked if you want to mount /boot and /boot/efi. Say yes to each of these.
  • Start a root terminal. Run following commands to get grub installed

    mount -t efivarfs efivarfs /sys/firmware/efi/efivars
    grub-install /dev/sdXXXXX
    update-grub

    Obviously fix sdXXXX to match the hard drive you’re using.
  • Then exit and reboot, and in your BIOS boot from the relevant hard drive. Once you boot into the system, efivarfs will be installed, so grub-install will work without special provision.

Upgrading to Debian Testing (Bullseye)

The relevant upgrade process in Debian is very straight-forward. I got caught out on only one issue (so far, Daumen drucken!). After upgrade, I thought my system might be failing to boot as it went to black-screen. I fixed this by booting again from rescue medium. However, I discovered later (I reinstalled a few times trying out different things!) that what was happening was that Bullseye was switching to using my on-board Intel graphics in preference to the nvidia graphics card that is also installed. The onboard HDMI was not connected to a monitor, and motherboard is set to prefer the installed (not onboard) graphics adapter.

I’m not entirely sure what fixed it, but essentially I went through the package list in aptitude and picked out a bunch of the packages that have “firmware” in their title. e.g. firmware-linux, firmware-linux-free, firmware-linux-nonfree firmware-misc-nonfree. This seemed to fix the issue, however I’m sure there’s a more well thought out way to get this to work.

Closing remarks

Obviously these notes are not a blow-by-blow account of how to do the install, and I wrote it the day after so could forget or misremember a step. In any case the online documentation from Debian is in any case already very good. However, I hit a few snags that I know I’ll struggle to remember in a few months (years!?) and so wanted to record them at least for myself.

The last install I did was pretty much a clean run through. I repeated the process because the last-but-one attempt had used automatic partitioning and left no free space after the LVM Physical Volume (that was ok), and a very small /boot that was already 50% full and with no way to resize. So I bit the bullet and had one more run through the entire process using the expert installer to achieve exactly the configuration I wanted. The total time was about 1h20 (based on doing a basic install of stable, with no desktop environment, manual partitioning etc., then kicking off the update process, and after that adding some things like the desktop environment task and so on).

End result, in any case, is that I have Debian Testing up and running, and going well. I still have my old Debian Stable installation ready to boot should something happen that causes problems with this install, so I have a bit of insurance in the background against any Debian Testing related instability.