My September Tumbleweed install
For this month, I decided to install the 20150903 Tumbleweed snapshot. I planned to install on an external drive, and to install only KDE (i.e. Plasma 5).
This install turned out to be a disaster. But that’s why I do these monthly installs. I have reported the problems as bug 944662.
The downloading went well. I used “aria2c” to download “openSUSE-Tumbleweed-DVD-x86_64-Snapshot20150903-Media.iso”. And I used “wget” to download the checksum file “openSUSE-Tumbleweed-DVD-x86_64-Snapshot20150903-Media.iso.sha256”. I then used “gpg” to verify the signature on the checksum file. And I used “sha256sum” to compare the checksum of the downloaded iso with that in the checksum file. All went well.
I then “burned” to a USB, with the command:
# dd_rescue openSUSE-Tumbleweed-DVD-x86_64-Snapshot20150903-Media.iso /dev/sdd
Before long, I was ready to boot that USB and attempt an install.
Booting the installer was straightforward. I was using my Dell laptop. I inserted the USB, powered on, and hit F12 to get the BIOS boot menu. There, I selected “boot from USB”. When the menu screen for the installer showed up, I connected the external drive to which I planned to install. Then I selected “Installation” from the menu. The installer booted up. Everything looked ready to go.
My external drive uses an encrytped LVM. I was prompted for the encryption key and provided it. I’ll note that I did not get a network setup screen. That was probably because I had an ethernet cable connected.
The partitioner made a proposal which I ignored. I instead selected “create partitioning” followed by “custom partitioning”. I then used the button for importing partitioning. That listed several possible choices. I selected the choice for installing on the external drive. Specifically, “/dev/sdb2” was to be formatted for “/boot” as “ext2”, and volumes in the volume group were to be used for root, home and swap.
It all looked good. I accepted the result, and continued with installation.
I was a bit surprised at the boot settings. There was no option to boot from “/boot”. In retrospect, that’s when I should have realized that there was a problem. I told it to boot from “/dev/sdb2”, and ignored the warning that this wouldn’t work. I proceeded with install.
There was an error message about a boot install problem. I also ignored that.
Then we got to the reboot. It seemed to boot into the system. But then I found that I was in a dracut shell. Looking around, I began to suspect what had happened. The “/dev/sdb2” partition for “/boot” had not been used at all. Something had gone badly wrong.
I decide to repeat the install. This time, I would pay more careful attention. I was now looking for information for a potential bug report.
The first steps were as above, with one exception. I unplugged the ethernet cable for the install. As a result, I did get a network configuration page. While on that page, I plugged the ethernet cable back in. But I also did the network settings, including the hostname for the machine.
Continuing to the partition stage, I did much the same as before. When I imported the partitioning, it did not list “/dev/sdb2” for “/boot”. That’s because it was importing from my earlier failed install which did not use a separate “/boot”.
I carefully configured “/dev/sdb2” for “/boot” and to be formatted as “ext2”. Then I carefully rechecked.
After accepting the partitioning, I looked carefully at the summary partitioning screen. But it did not list the partition for “/boot”. Twice more, I went back into partitioning to setup “/boot”. Each time, the partitioning summary screen failed to show it. Apparently, the installer was ignoring that partition setting.
I continued with the install anyway, ignoring errors related to booting.
When it came to the stage of rebooting into the installed system, I instead went into rescue mode.
In rescue mode,I noticed that “/dev/sdb2” had not been formatted or touched. So I formatted it. Next, I fixed “/etc/fstab” so that it would include mounting “/dev/sdb2” as “/boot” (I mounted by UUID). Then I copied the “/boot” from the root file system to the newly formatted “/boot”. I used a “tar” pipe for that copy. I mounted the “/boot” as needed for rescues, and did the other “–bind” mounts needed. I then did chroot to the mounted system. And there, I ran:
# grub2-install --force /dev/sdb2 # grub2-mkconfig -o /boot/grub2/grub.cfg
That seemed to be successful.
Booting the system
Booting almost worked. But it stopped with a message about device name needed. I hit enter to continue, and it successfully booted.
I got that message again on subsequent boots. Then I realized what had happened. Without a separate “/boot”, grub2 would need to use crypto to read the kernel and to read its configuration file. So there was something in grub wanting to decrypt a device, but with no device name given. That’s probably a bug. But the solution was simple. I edited “/etc/default/grub”, and changed the “GRUB_ENABLE_CRYPTODISK” line to disable that crypto. I regenerated “grub.cfg”. And that fixed the problem.