On 2018-02-09 16:36, Michael Albert wrote:
Everyone,
I have a bit of a problem after 20180206 snapshot on a Tumbleweed server installation. First, I haven't been able to upgrade to any of the 4.14 kernels for some reason (I've had text color corruption on my tty and very common kernel panics, this is on a server installation so no display manager). So, I can't that it was this specific snapshot that caused the problem. I'm just looking for help to get my system back to a working state.
Since I skipped the entire set of updates with a 4.14 kernel, it has been a couple of months since I've updated. I did a zypper dup to 20180206 since the kernel was now 4.15.1 and I wanted to see if the new kernel had fixed my problem. After the zypper dup, I did a rpmconfigcheck to see what config files needed attention, and there were a number that seemed innocuous (samba and the like), but there was also an entry for "/etc/default/grub.rpmnew".
I looked briefly at the diff between /etc/default/grub.rpmnew and the old grub, and I hadn't really customized it outside of some kernel parameters given through yast, so I replaced the old grub with the grub.rpmnew (renaming the old grub to grub.old), and I used yast to set the kernel parameters back to what I had them as.
This will not help now, but next time. I do a backup of the "new" config files: md /root/Upgrades/{VERSION} cd /root/Upgrades/{VERSION} cat /var/adm/rpmconfigcheck | xargs -I '{}' -n 1 cp --parents '{}' . Then I use meld on each pair of files: meld /etc/default/grub /etc/default/grub.rpmnew "Meld is a visual diff and merge tool. You can compare two or three files and edit them in place (diffs update dynamically). You can compare two or three folders and launch file comparisons. You can browse and view a working copy from popular version control systems such such as CVS, Subversion, Bazaar-ng and Mercurial." If meld is not installed, do it :-) To see what is different, what new and I want to use, or what I'll ignore, or to edit my own things, it is a full editor. In fact, this time I used this new script: #!/bin/bash while read FILES ; do echo "Before:" ls -l ${FILES%.*} ${FILES} meld ${FILES%.*} ${FILES} echo "After:" ls -l ${FILES%.*} ${FILES} echo Press enter for next or control-C read done < /var/adm/rpmconfigcheck (the press ^C doesn't work) Finally, I deleted the .rpm files: cat /var/adm/rpmconfigcheck | xargs rm
Then I restarted the computer. The computer boots to the grub menu, but no matter if I choose to boot the current kernel or the old kernel, I get the following error:
Loading Linux 4.15.1-1-default error: can't find command `linux'. Loading initial ramdisk... error: can't find command `initrd'.
Press any key to continue...
Then I'm spit back to the grub menu. Moreover, there is no option to boot a snapshot, so I can't rollback (which I would consider to be a fine solution to my problem).
This is the standard procedure I'll describe - but note that I don't use btrfs, I don't if you have to do something special with it. Boot the machine with any Linux system on CD or USB stick you have, or from some other partition. Mount your failed system in, for instance, /mnt. Then do: mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys chroot /mnt At this point, you have your "failed" system available in that terminal, and you can run commands. You can now edit /etc/default/grub and repair it. Once done, there is a comment at the top of the file that says what command you have to run to apply the changes. You need a text mode editor; I can suggest joe (aka jstar, jmacs, & jpico), or mcedit, or vi - but in the later case you do not need my editor advice ;-) You can also run "yast" in text mode in that window, and change the bootloader configuration. Trick: to make YaST write to disk if there are no changes, I simply change the number of seconds Grub is told to wait before booting an entry. Say it is 8, I write 9. Once done, type "exit" or ^D on the terminal to exit the chroot. Caveat: I have done all of the above several times, it works; but never in Tumbleweed, which I don't use on real hardware. And never on btrfs, which I don't use. I see no reason why it would not work, but just take that into consideration :-) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)