-
Notifications
You must be signed in to change notification settings - Fork 60
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
Booting to baremetal drops to emergency mode due to ostree-remount.service failure. #746
Booting to baremetal drops to emergency mode due to ostree-remount.service failure. #746
Comments
Also allow override of flavor at cluter scope. See: coreos/fedora-coreos-tracker#746
Also allow override of flavor at cluter scope. See: coreos/fedora-coreos-tracker#746
Also allow override of flavor at cluter scope. See: coreos/fedora-coreos-tracker#746
I confirm. I have the same problem.
add to ignition file |
Can you share the full journal output or the AVC errors because I can not find one in the output you posted here. |
Hmm, looks like there's something earlier than |
Same problem here, this only occur on first reboot after new install, all right after that ... |
Can you post the full journal from the boot where this occurred? |
Hmm I cant find a good way to scrape the output to paste here, do you have any suggestions? |
You can try saving the journal to an external drive or maybe uploading it over the network. |
Been digging into this. I think this is diff --git a/src/boot/ostree-remount.service b/src/boot/ostree-remount.service
index af40453c..a54114f9 100644
--- a/src/boot/ostree-remount.service
+++ b/src/boot/ostree-remount.service
@@ -28,7 +28,7 @@ After=systemd-remount-fs.service
# But we run *before* most other core bootup services that need write access to /etc and /var
Before=local-fs.target umount.target
Before=systemd-random-seed.service plymouth-read-write.service systemd-journal-flush.service
-Before=systemd-tmpfiles-setup.service
+Before=systemd-tmpfiles-setup.service systemd-rfkill.service systemd-rfkill.socket
[Service]
Type=oneshot @dustymabe Would you be able to try that on your Raspberry Pi 4? (Rather than rebuilding, you could also modify the service from an Edit: actually, it should be totally fine to add the drop-in from Ignition too. Though if you've already got the config embedded, it might be easier to just do it live in the switchroot shell. |
Adding something like this:
seemed to get me a functioning system:
|
The `systemd-rfkill.*` service falls in the category of things that need write access to `/etc` and `/var`, so we need to make sure we run before or it might hit the read-only sysroot. The long-term fix for this is ostreedev#2115. Closes: coreos/fedora-coreos-tracker#746
The `systemd-rfkill.*` service falls in the category of early things that need write access to `/var`, so we need to make sure we run before or it might hit the read-only sysroot. The long-term fix for this is ostreedev#2115. Closes: coreos/fedora-coreos-tracker#746
Thanks @dustymabe for checking! I opened ostreedev/ostree#2387. |
Has this been incorporated into a stable release? |
Upstream release has happened now: https://github.com/ostreedev/ostree/releases/tag/v2021.3 Should be in the next FCOS |
The fix for this went into testing stream release |
The fix for this went into stable stream release |
Describe the bug
Stable releases 32.20201104.3.0 and onwards fail to boot smoothly on baremetal.
Reproduction steps
Steps to reproduce the behavior:
Expected behavior
Boot normally.
Actual behavior
Drops to emergency mode shell due to ostree-remount.service failure:
I checked the journal and around this error, there is avc denial errors. I tried setting selinux to permissive via ignition but the problem did not go away.
It continues to boot normally after I press ctrl+D but gets stuck on this prompt so networking doesnt come up until then.
System details
broken:
working images:
As you can see , 32.20201104.3.0 is the next stable image after 32.20201018.3.0. Can anyone shed a light on any substantial change which could be leading to this issue?
Ignition config
Please attach your FCC or Ignition config used to provision your system. Be sure to sanitize any private data. If not using FCCT to generate your Ignition config, does the Ignition config pass validation using ignition-validate?
Additional information
Add any other information about the problem here.
The text was updated successfully, but these errors were encountered: