Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debian: Failure when booting after rollback (Kernel panic) #61

Closed
74cmonty opened this issue Dec 7, 2018 · 11 comments
Labels

Comments

@74cmonty
Copy link

@74cmonty 74cmonty commented Dec 7, 2018

Hi,
I have setup BTRFS snapshots successfully and can boot any snapshot from Grub.
However I have identified an issue related to snapshot rollback.

Steps to reproduce the issue (with Debian 9.6):

  1. Boot snapshot X
  2. After system is loaded it is read-only and not fully usable
  3. Rollback snapshot X with command snapper rollback X
  4. snapper rollback will create additional snapshots, of which one is a read-write snapshot Y of snapshot X; in addition this snapshot Y will be set as default snapshot (corresponding to btrfs subvolume set-default Y)
  5. reboot and select default entry

The system will not boot and run into Kernel panic.

A workaround to boot w/o errors is to edit the entry related to default by means of modifying the line starting with "linux"; here the string rootflags=... must be deleted.

Do you have an idea for a permanent fix?

@Antynea

This comment has been minimized.

Copy link
Owner

@Antynea Antynea commented Dec 7, 2018

hello,
Thanks for your feedback.

I don't use snapper software
but what you describe makes me think of this video.
Maybe @maximbaz can help you.

While waiting for an answer from him.

  1. After system is loaded it is read-only and not fully usable

According to my knowledge, snapper creates "snapshots read only by default"
The systemd software needs to write its log on a write file system.
To start on a read-only file system is a problem.
However you can fine tune the systemd setting and avoid this inconvenience :)

A workaround to boot w/o errors is to edit the entry related to default by means of modifying the line starting with "linux"; here the string rootflags=... must be deleted.

I don't understand.
If you start on the default entry, my script has nothing to do with your problem.
your default entry is wrong, and i think after rollback you must launch grub-mkconfig for update grub.

Sorry, i can take the time to install debian 9.6 on vm
and test your setup, jsut tell me how is your setup :)

@Antynea Antynea added the question label Dec 7, 2018
@maximbaz

This comment has been minimized.

Copy link
Collaborator

@maximbaz maximbaz commented Dec 7, 2018

It's on my list to actually try out and document the rollback procedure, but I'm not sure when I'll get to this... However I agree this isn't really an issue with grub-btrfs project, since you managed to boot into a snapshot and execute some commands, grub-btrfs has successfully accomplished its mission 🙂 It's a question about how to properly rollback, with snapper or default btrfs commands.

@Antynea

This comment has been minimized.

Copy link
Owner

@Antynea Antynea commented Dec 7, 2018

@maximbaz
That's what I thought,
and that's why I opened a new branch for version4.
I removed any indication about a rollback on the readme,
because grub-btrfs doesn't do that. it just boot on "btrfs snapshots"

edit: I need to add a warning about starting snapshots in read only
and some examples to counter this

@74cmonty

This comment has been minimized.

Copy link
Author

@74cmonty 74cmonty commented Dec 8, 2018

Hi,
thanks for your feedback.

With regards to my setup, this is a basic Debian 9.6 installation on KVM with 1 disk (2 partitions: root, swap) booting in BIOS mode.

I would agree that the issue is related to snapper on the one hand.
But on the other hand snapper is working correctly when creating snapshots and rolling back.

In my opinion the default grub entry must be modified by means of deleting boot option rootflags=subvol=@ as snapper sets a new default subvolume that is booted only w/o this rootflag option.

I will now validate if this issue is reproducible after updating snapper (to 0.8.1), grub-common (to 2.02+dfsg1-8) and linux-kernel (to 4.18.0).

Update:
The issue is reproducible with latest tools and linux-kernel.

@Antynea

This comment has been minimized.

Copy link
Owner

@Antynea Antynea commented Dec 10, 2018

If I summarize your request.
Your snapshots are available in the Grub menu
You are able to start from the menu on a snapshot
Your request doesn't concern grub-btrfs project....

How can we help you?

@74cmonty

This comment has been minimized.

Copy link
Author

@74cmonty 74cmonty commented Dec 11, 2018

This is not totally correct.

Snapper is setting a new default subvolume that is the RW snapshot of the rollback.
In order to boot this RW snapshot I must select is from Grub menu. This is inconvenient in particular if the PC reboots and I cannot interrupt default boot sequence.

If the default boot entry in Grub menu would not include this string rootflags=subvol=@ the system would boot like charm, means the new default subvolume would be started.

@Antynea

This comment has been minimized.

Copy link
Owner

@Antynea Antynea commented Dec 11, 2018

The default boot entry is managed by Grub (not grub-btrfs) ...

However here is the solution to your request :

Warning

modify a system file is dangerous.

I can not be held responsible for consequences that flow

Edit /etc/grub.d/10_linux
Replace line 79
GRUB_CMDLINE_LINUX="rootflags=subvol=${rootsubvol} ${GRUB_CMDLINE_LINUX}"
by
GRUB_CMDLINE_LINUX="${GRUB_CMDLINE_LINUX}"

then update Grub

Ps: contact Grub mailing list, I don't support it.

@74cmonty

This comment has been minimized.

Copy link
Author

@74cmonty 74cmonty commented Dec 11, 2018

Many thanks.
Basically you confirm my assumption for the required modification.

I will now reach out to Grub and report this issue and the proposed solution.

@74cmonty 74cmonty closed this Dec 11, 2018
@74cmonty

This comment has been minimized.

Copy link
Author

@74cmonty 74cmonty commented May 23, 2019

Hi André,
I have reopened this issue because I want to address another question related to this issue.

After setting up a new Debian 9.9 installation I noticed an inconsistency in Grub Menu vs. /boot/grub/grub.cfg.

If you compare the attached screenshot with the current /boot/grub/grub.cfg the lines "linux" and "initrd" are different and the header header displays another Grub version than installed (grub-common = 2.02).
2019-05-21_17-16-41

I put my grub.cfg here.
Could you please share some information on this finding?
Is my assumption that Grub Menu must display the same content as /boot/grub/grub.cfg wrong?

THX

@74cmonty 74cmonty reopened this May 23, 2019
@Antynea

This comment has been minimized.

Copy link
Owner

@Antynea Antynea commented May 23, 2019

Hello,

The version of "grub-common" available in debian 9 is this one
2.02 ~ + beta3-5 deb9u1

If you think, you have a different version installed, update your source list and reinstall grub.
If you have an old grub install on this hdd, and the mbr is not up to date, reinstall grub.

Is my assumption that Grub Menu must display the same content as /boot/grub/grub.cfg wrong?

It is possible in the case of multiple subvolume that files started by grub do not match the default subvolume. Reinstall grub.

I think the screenshot is correct but the grub.cfg provided is out of date.
So you shouldn't have to reinstalled grub.
Check in your fstab that no invalid entries are registered corresponding to /boot then correct it.
You can easily check this with the findmnt command available in util-linux

If you don't find an error, please put the findmnt output here.

@74cmonty

This comment has been minimized.

Copy link
Author

@74cmonty 74cmonty commented May 24, 2019

Thanks for your advise.
I finally fixed the issue by re-installing Grub in the MBR of the relevant device.

Now all issues, means inconsistency in Grub menu and booting snapshots, works as expected.

@74cmonty 74cmonty closed this May 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.