Leap 42.3 cannot be booted after automatic Kernel update or large tar -xvzf from a backup disk

English Install/Boot/Login
#1

On 30 August 2017 I installed openSUSE Leap 42.3 on a new SAMSUNG 850 EVO 500 GB SSD on my Laptop. During the installation it was mentioned that the boot loader would not be written to the MBR, only to the root partition and possibly another partition (cannot remember). My partitions are:
/dev/sda1 4 GB swap
/dev/sda2 40 GB btrfs / (I tried to select EXT4 but it would only accept 10 GB, which I had on my previous Leap 42.1 and which was too small)
/dev/sda3 420 GB EXT4 /home

On the next day, after the installation was complete and after I had rebooted successfully a couple of times, a message came that 8 security updates were required - which I accepted. I noticed that the last update was a kernel update - I was not able to catch which version kernel that was. Soon after that I had another problem, which is relevant here. I had saved my 12 GB user data in /home of my previous system on a 500 GB USB backup disk with tar gzip. I had successfully restored other users, whose tgz files were much smaller, with tar -xvzf xxx.tgz. When I did the same with the tgz file for the 12 GB user the system froze after extracting about 40%. Nothing moved on the screen, keyboard and mouse had no effect - I could not start tty2 or shutdown the system in any of the known ways, except by holding down the power button for 10 seconds.

When rebooting after turning the power back on, the boot screen output about 20 lines and then came up with the following message:

…] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

On booting there were 2 kernels to choose from 4.4.79-19-default and an earlier one 4.4.76-1-default. Choosing either kernel gave the same kernel panic above. After much head scratching I successfully used the following workaround to boot the system.

  • Boot the Leap 42.3 installation DVD and select “Boot Linux System” - accept all prompts - this boots OS on /dev/sda2.

I had the system back but still had to recover the 12 GB of user data to /home. Two more attempts with tar -xvzf caused the system to freeze after 10% and 30% of the transfer, with workaround boots in between.

Now I successfully used a second workaround to restore the data:

  • Boot the Leap 42.3 installation DVD and select “Rescue system”. I was able to mount /dev/sda2 on /mnt and my home /dev/sda3 on /mnt/home. I was also able to mount the 500 GB USB backup disk on /media/floppy . With this setup and using tar -xzf xxx.tgz (left out -v option, which I had not tried earlier) the 12 GB of user data was successfully extracted in 7 minutes using the Rescue System. I still have to boot the system with the first workaround. But I could now finish some urgent work.

Before the first workaround tried to do a grub-install I had found on the net (using another computer) but it made no difference.

My urgent question is: How do I restore GRUB or the installed system so it will boot normally?

PS: I will try the tar -xzf (without -v) on the system and report what happens. Maybe the excessive amount of stdout output because of -v made the system freeze ??

PPS: Here is my system information:

Software
openSUSE Leap 42.3
KDE Plasma Version 5.8.7
KDE Frameworks Version: 5.32.0
Qt Version: 5.6.2
Kernel Version: 4.4.79-19-default
OS Type: 64 bit

Hardware
Processors: 2 x Intel Pentium CPU B940 @ 2.00GHz
Memory: 3.7 GiB of RAM

Disk
SAMSUNG 850 EVO 500 GB SSD
I would also appreciate any tips or links to tips about running Linux on an SSD

#2

I’m assuming that you use MBR boot and not dual/multi-booting.

Do you get a grub boot screen? if so select advanced and try the previous kernel.

If you get in go to Yast-bootloader and re configure grub there.

Not knowing what was in that Tar it is hard to say what may have been changed. Did you restore it to root or home?? If you wrote it to root you may have destroyed the system
:open_mouth:

#3

First: Any reason not to copy the entire /home to USB disk??
Second:: Sure the UUID’s are the same as the ones in the tar files?

#4

6 September 17

  1. not using a dual boot configuration. The Leap 42.3 installation specifically mentioned that the MBR would not be used for booting and would not be touched.

  2. I did get a grub boot screen, which I assume the boot process must be past the initial phase using one block. On 31 August I could choose two kernels, both of which failed immediately with the kernel panic.

  3. I tried looking at the grub configuration, but do not know enough about what is correct, so I did not change anything.

  4. the TAR file failed to extract to completion 3 times to /home with the installed system, which froze each time. I was able to extract it fully with the Rescue system on the installation DVD.

I then had some urgent work to do with the recovered data. At this stage I had not tried to reboot since the 31 August.

7 September 17

  1. Lo and behold - now the Leap 42.3 system boots perfectly directly from the SSD, whereas it failed consistently with the kernel panic after the kernel update on the 31 August.

  2. Even stranger - the tar -xvzf of my 12 GB user backup .tgz file now extracts flawlessly, which also failed 3 times and froze the system on 31 August.

I can only surmise, that there has been another update, although I have not seen one announced since the 31 August and I certainly have not acknowledged an update. KInfocenter now reports Kernel Version: 4.4.79-19-default, which is the same as was reported on 31 August and the first of the GRUB selections, which then failed with the kernel panic.
PS: There is a chance that the kernel version on 31 August was different. I did not record it in my workbook at the time. In my post on 5 September I reported the kernel version in KInfocenter, at which point the system was probably already fixed.

I guess you can close this thread - Thanks :wink:

#5

First: I have always been happy with TAR-GZIP and find it a good and reliable way to bundle directories, files, and soft-links between computers.
Second: The UUID’s in the TAR definitely match the ones on my different systems - I am very careful about that.

As reported above to the previous respondent, the system now boots correctly and the tar -xvzf works correctly. I just wonder what went wrong last week - Ho hum, as they say in Australia.