Yeah, I'm using the subvolume structure intended for snapshots, and in the past I've had no problem rolling back snapshots (I kept having to do it since no 4.14 kernel was stable for me and I kept trying to update). However, I don't have an easy way to show the current /etc/default/grub and the output of "btrfs sub li /path/to/root" because I can't boot the system. I can get the system running with a recovery disk, so I may be able to get the output, but I will have to wait until tonight. Do you think it's likely to work if I just restore my old /etc/default/grub and then do: grub2-mkconfig -o /boot/grub2/grub.cfg; grub2-install /dev/sda; after properly setting up the root filesystem and then doing a chroot? I used the standard btrfs subvolume layout for TW when I installed the system (a little over a year ago), so is there any documented way to mount the subvolumes in order to chroot into a properly structured root filesystem? Michael On Fri, Feb 9, 2018 at 2:07 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
09.02.2018 18:36, Michael Albert пишет:
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.
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...
It sounds like you have subvolume structure intended for snapshots but /etc/default/grub lacks SUSE_BTRFS_SNAPSHOT_BOOTING=true. This variable changes how grub2 works with btrfs, and it probably simply does not find /boot/grub2/x86_64-xxx/ directory (where "xxx" is for "pc" or "efi").
Can you show current /etc/default/grub and "btrfs sub li /path/to/root" output?
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).
Something has gone wrong with grub, and I'm not sure how to fix it. I use BTRFS, and I use the standard filesystem layout (the old one, I've seen that there is a new layout in more recent snapshots). I can make a rescue cd from the most recent snapshot, but I'm not certain exactly how I would manually mount the btrfs filesystem in order to chroot into it correctly. I'm also not certain what I should do after chrooting into the old filesystem.
Any help on this would be greatly appreciated. Also, any insight on what I did wrong in the update would be valuable information for the future.
Thanks in advance!
Michael
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org