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.

The 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.

Second install

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.


Tags: , , ,

About Neil Rickert

Retired mathematician and computer scientist who dabbles in cognitive science.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: