The title is a play on words. I had to go into rescue mode after a bad install of opensuse 12.1 rc1 (the first release candidate). This post reports how I got the system going.
I’ll start by describing what happened. And, incidentally, I was not at all surprised that I ran into problems – I was expecting them.
My plan was to install the 32 bit version on a 64 bit system (with 6G of memory). Normally, you can only access 4G of memory in a 32 bit system. However, the PAE that is built into the desktop version of the kernel does allow accessing more memory. I had previously installed opensuse 11.3 and opensuse 11.4 on this particular computer (a Dell laptop), and was able to use all 6G of memory. With the early test releases of 12.1, I was also able to use all 6G. But with the milestone 3 release – the first to use a 3.x kernel version, that no longer worked. I installed from the KDE live CD, which uses the default kernel and can only access 4G of memory. So I then installed the desktop version of the kernel, expecting to be able to use all of the memory.
Unfortunately, the desktop kernel would not load. The system would hang during kernel loading. I had to boot from the default kernel if I wanted it to work.
The same problem showed up with the milestone 5 release, and then with the Beta1 release, which were using more recent versions of the kernel. It was becoming obvious that this bug was not likely to be fixed any time soon. A fix would have to come from the kernel developers. And they are probably thinking that people should just install a 64 bit kernel and not depend on the PAE hacks.
For the rc1 pre-release version, I had planned to install from the DVD. The installer on the DVD is more flexible than that on the live CD, so I expected that it would decide that the desktop kernel is best for my system and install that. My plan was to go into the software selection part of the install, and make sure that the default kernel was also installed so that I would have an alternative in case the desktop kernel failed to load.
My plans ran into another problem. A bug in the installer prevented one from going into the software select part. So I would be stuck with whatever kernel was installed.
I went through with the install anyway, expecting problems. My main reason for this install was to test whether the desktop kernel would load. And an install that failed because of the problem would still be a valid test.
As expected, the installer chose the desktop kernel. And, as expected, the kernel failed to load on the reboot for final configuration.
I could have stopped there. I had already tested what I wanted, and I already had a successful 64 bit install on the same computer, which I could use for testing other software in the release. But I decided this could be a learning experience if I tried to rescue the bad install.
I knew what was needed. I had to somehow install the default kernel, build the “initrd” and update the boot configuration on an unbootable system.
It took a little experimentation to work out how to proceed. The man pages for mkinitrd were particularly helpful.
Here’s what I finished up doing:
I began by booting the DVD into rescue mode, where I logged in as root. Then I mounted the root directory of the failed install as “/mnt”, and mounted other partitions onto that. After the mounts “/mnt” was the complete system that I wanted to repair.
# mount --bind /dev /mnt/dev ## make the devices available # chroot /mnt ## switch to the damaged system # mount /proc # mount /sys # yast
That got me into the yast administrative tool in command line mode. There, I installed the default kernel. That went well. Yast built the “initrd” file and updated the boot configuration as part of its install.
I could then exit from yast, exit from the chroot environment, and reboot. I selected the default kernel in the reboot. The configuration stages of the initial install picked up where they had left off. And I now had a bootable system provided that I used the default kernel for booting.