Installing opensuse 13.1 Beta
I have spent much of my day with installing the Beta release. Thorough testing will have to wait. For now, I will report on how the installing went.
The installing experience can reasonably be described as “interesting”. It is only a beta, so we expect things to go wrong. If we learn from our mistakes, then there could be a lot to learn from this.
I have three completed installations of the Beta. They all look as if they are smooth running systems, though I have not adequately tested them. But installing was another story entirely.
My installs were all done using the DVD image written to a USB. I also did some testing with the live KDE image, and I’ll comment on that, too. My first install was on a 2007 desktop 64 bit system, a Dell Dimension C521. My second install was on a newer Dell Inspiron 660, with UEFI firmware. My third install was on a 2004 vintage Toshiba laptop, and was 32 bit. All installs were successful, though none was completely smooth.
32-bit KDE live USB
While I did not install from the live KDE image, I did test it. This was a complete disaster. I have filed bug report 841364 on the failure. In short, the USB is self-desctructive. On booting, the kernel loads. Shortly after the kernel has loaded, the system reports an error and reboots. On reboot, the live USB is no longer bootable.
I have only tested this with the a KDE live USB. However, it seems likely that a Gnome live USB, and a live rescue USB will both suffer from the same problem.
What is supposed to happens, is that on the first boot a “hybrid” partition should be created where any changes to files can be written. Instead of creating a hybrid partition, the entire USB seems to have been formatted as an ext4 hybrid file system.
I also tested creating a live USB using the “live-fat-stick” script. That worked, and the KDE live system booted fine with that “live-fat-stick”. While I did not try installing, I expect that would probably work. I did not try writing the live image to a DVD, but I expect that would also work.
The difference here is that when booted with “live-fat-stick” or from an actual DVD, there is no attempt to create a hybrid partition. And that’s why the self-destructive failure is avoided.
64-bit KDE live USB
The 64-bit live USB does not self-destruct. It works fine for booting to a live system. However, install is likely to fail. If you boot the 64-bit live USB, and check the content of “/boot” it will look wrong. Since installing from a live system involves copying it, the installed copy would also have a bad “/boot” and would be unbootable. This has previously been reported as bug 827520. And, it is also related to the creation of the hybrid partition, though it is less clear what is going wrong.
Fortunately, there is a workaround. Boot the live system. Then shut it down. Now mount the hybrid partition (it will be “/dev/sdX3” for some X) and “rmdir” the “boot” subdirectory of the hybrid partition. On future boots of that USB, everything should work properly. In particular, “/boot” will have the proper content.
Again, as in the 32-bit case, if you make an actual live DVD then that should be fine because no hybrid is created. I did not try, but in past experience the “live-fat-stick” script does not work with the 64-bit live images. The UEFI formatting confuses the script.
My first attempt to install on my UEFI box did not go well. Booting the DVD image (on a USB) got as far as the “loading kernel” message. And then everything seemed to stop. I then tried the 64bit KDE live USB, with the same result.
Next, I disabled secure-boot, and tried booting the DVD image in MBR mode that worked. A later check showed that both the DVD and the live KDE system would boot in UEFI mode, as long as secure-boot is disabled.
Having found this work-around, I was able to install. However, the installed system would not boot with secure-boot enabled. I had to leave secure-boot disabled to be able to use the system. Or, alternatively, I could edit “/boot/grub2/grub.cfg” and change “linuxefi” to “linux” and “initrdefi” to “initrd” on each boot command. So something is broken about secure-boot support in the 13.1 Beta.
While installing, there is no information on progress. The installer screen lists how many packages to be installed. And that number never changes. So it is hard to anticipate when the install will complete.
Encrypted LVM woes
None of my installs was to an encrypted LVM, but I did some testing anyway. I was alerted to a possible problem while running Tumbleweed on my Dell Dimension C521. After installing a 3.11.0 kernel on Tumbleweed, found that it would not boot. During boot, I was prompted for the LVM encryption key. But the system seemed to never respond to what I typed in. It looks to me as if it is failing to read the USB keyboard. I could boot Tumbleweed to the 3.10.x kernel, but not to the 3.11.0 kernel.
After installing 13.1 Beta on that same box, I decided that I should test for that problem. With an entry for the encrypted LVM in “/etc/crypttab”, I am prompted by systemd for the key. And that works. If I add “initrd” to the “crypttab” entry to force the request to be handled by the “initrd” processing, then I get the same kind of hang that I had with Tumbleweed on that box. At this stage, it is a bit of a mystery.
I also tested for this problem on the other two boxes. The problem did not show up there.
Other problems were relatively minor. The one that comes to mind, is that I was unable to reboot from the logout menu of Icewm. This only happens on one of my three installations. It happens on the system where I used “btrfs” for the root file system. I am wondering whether that might be related.
Happy testing, everybody.