Cannot update silverblue (grub2-mkconfig error) #322
Comments
|
|
I'm having the same issue with the same ostree image. |
|
I had the same issue. After some searching I found these issues: After that I used the following to fix the issue: Edit: |
|
Same issue. did help though. |
|
I ran into the same issue on two separate systems, one running 36.20220810.0 and the other one running 36.20220812.0. Both systems are quite vanilla and I am not running any special kernels on them. Running got both updated to 36.20220814.0 successfully. The somewhat scary thing is that I only noticed the failed update when I was looking at an unrelated issue and noticed the failure in rpm-ostree status. Depending on when and how this gets fixed, Silverblue installations may go without system updates without the user noticing. This might deserve its own issue, but I think there should probably be more notification about failure to update. |
Yeah I noticed it when I got like 3 times the same packages when upgrading. And was like huh didn't I update those packages already. Very good point. |
I agree, I noticed this after 2 days only when trying to layer new package and it wasn't in If this means that the current ostree image is corrupted and it couldn't be updated this could lead to systems that will not get any new update without user even noticing this happened. |
Fully agree, I noticed it on my system only because some folks on Fedora Discord was talking about it, I check it out and boom I was affected also. |
|
I am facing the same error. Although I can layer other package in 36.1.5 but not with latest version. This is the error |
|
I posted about this on reddit, but I was able to get around this mysterious issue just now with: And that's it. No idea why it worked, but here I am (for now). |
|
same here will try the workaround this worked, thanks |
|
I had the same issue with the same symptoms and error messages at the others in this thread. I tried the proposed fixes and was able to get one instance of updating/layer to take, but trying to then do another deployment failed with the same error as before. |
+1 that. They feel like temporary fixes, aka workarounds. Hopefully this issue will get a fix soon. Good luck If anyone wants to put those workarounds in a single command, you can use the && notation. Example-1 from #322 (comment) Example-2 from #322 (comment) rpm-ostree update is an alias to rpm-ostree upgrade, so you can interchange them. Please note that you can also add |
|
is this bug still present in current deployments or was it just if you grabbed it from like august 10-14? |
|
I still see it with I'm actually not sure if the update will finish even if the fix is introduced in newer version. If not it potentially means we will have plenty of Silverblue systems, that will just stay on those versions that are broken. |
|
Looks like grub is trying to write into a read-only etc and failing. Added the following drop-in: After running a This is the section of The |
|
OK, this history is messy here, but I think essentially there are two separate GRUB issues at hand. The first was GRUB not handling epoch timestamps on the EFI. This was fixed in grub2-2.06-43.fc36, which is already in the latest Silverblue composes. The second was introduced more recently by rhboot/grub2@0837dcd (i.e. rhboot/grub2#105) and it causes issues on libostree systems because we run |
jlebon
added a commit
to jlebon/grub2
that referenced
this issue
Aug 17, 2022
On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
This was referenced Aug 17, 2022
This worked and fixed the issue, but can someone explain WHY this fixes the issue? |
|
It works because |
frozencemetery
pushed a commit
to jlebon/grub2
that referenced
this issue
Aug 17, 2022
On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
So are all existing silverblue systems frozen on the version where this bug first appeared, unless they use one of those manual fixes? Or can a grub update be pushed separate from ostree's system image stuff? |
|
(I don't have any
Should this be the official workaround? (It worked for me too.) I guess this issue is impacting a lot of users. (Also fwiw my laptop host was still on 36.20220725.0 and upgraded normally to 36.20220819.0 without a hitch.) |
lsandov1
pushed a commit
to lsandov1/grub2
that referenced
this issue
Jan 2, 2024
On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
vathpela
pushed a commit
to vathpela/grub2-fedora
that referenced
this issue
Jan 8, 2024
On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
lsandov1
pushed a commit
to lsandov1/grub2
that referenced
this issue
Jan 8, 2024
On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
vathpela
pushed a commit
to vathpela/grub2-fedora
that referenced
this issue
Jan 9, 2024
On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
vathpela
pushed a commit
to vathpela/grub2-fedora
that referenced
this issue
Jan 9, 2024
On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
lsandov1
pushed a commit
to lsandov1/grub2
that referenced
this issue
Jan 9, 2024
On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
vathpela
pushed a commit
to vathpela/grub2-fedora
that referenced
this issue
Jan 9, 2024
On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
lsandov1
pushed a commit
to lsandov1/grub2
that referenced
this issue
Jan 15, 2024
On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
lsandov1
pushed a commit
to lsandov1/grub2
that referenced
this issue
Jan 22, 2024
On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
lsandov1
pushed a commit
to lsandov1/grub2
that referenced
this issue
Jan 23, 2024
…sh: BLS: only write /etc/kernel/cmdline if writable On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
lsandov1
pushed a commit
to lsandov1/grub2
that referenced
this issue
Jan 30, 2024
…sh: BLS: only write /etc/kernel/cmdline if writable On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
lsandov1
pushed a commit
to lsandov1/grub2
that referenced
this issue
Feb 8, 2024
…sh: BLS: only write /etc/kernel/cmdline if writable On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
lsandov1
pushed a commit
to lsandov1/grub2
that referenced
this issue
Feb 8, 2024
…sh: BLS: only write /etc/kernel/cmdline if writable On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
lsandov1
pushed a commit
to lsandov1/grub2
that referenced
this issue
Feb 8, 2024
…sh: BLS: only write /etc/kernel/cmdline if writable On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
lsandov1
pushed a commit
to lsandov1/grub2
that referenced
this issue
Feb 9, 2024
…sh: BLS: only write /etc/kernel/cmdline if writable On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
lsandov1
pushed a commit
to lsandov1/grub2
that referenced
this issue
Feb 9, 2024
…sh: BLS: only write /etc/kernel/cmdline if writable On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
lsandov1
pushed a commit
to lsandov1/grub2
that referenced
this issue
Feb 15, 2024
…sh: BLS: only write /etc/kernel/cmdline if writable On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
lsandov1
pushed a commit
to lsandov1/grub2
that referenced
this issue
Feb 15, 2024
…sh: BLS: only write /etc/kernel/cmdline if writable On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
lsandov1
pushed a commit
to lsandov1/grub2
that referenced
this issue
Feb 20, 2024
…sh: BLS: only write /etc/kernel/cmdline if writable On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
lsandov1
pushed a commit
to lsandov1/grub2
that referenced
this issue
Feb 22, 2024
On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
lsandov1
pushed a commit
to lsandov1/grub2
that referenced
this issue
Mar 19, 2024
On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
lsandov1
pushed a commit
to lsandov1/grub2
that referenced
this issue
May 14, 2024
On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
lsandov1
pushed a commit
to lsandov1/grub2
that referenced
this issue
May 28, 2024
On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
lsandov1
pushed a commit
to rhboot/grub2
that referenced
this issue
Jun 19, 2024
On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
lsandov1
pushed a commit
to lsandov1/grub2
that referenced
this issue
Jul 9, 2024
On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
lsandov1
pushed a commit
to lsandov1/grub2
that referenced
this issue
Aug 31, 2024
On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
lsandov1
pushed a commit
to rhboot/grub2
that referenced
this issue
Sep 25, 2024
On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
lsandov1
pushed a commit
to rhboot/grub2
that referenced
this issue
Sep 25, 2024
On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
andreabolognani
pushed a commit
to andreabolognani/grub2
that referenced
this issue
Nov 15, 2024
On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
lsandov1
pushed a commit
to rhboot/grub2
that referenced
this issue
Dec 13, 2024
On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
Solution
See the article: https://fedoramagazine.org/manual-action-required-to-update-fedora-silverblue-kinoite-and-iot-version-36/
Run:
Then update your system as usual.
Original issue below
This issue tracker is intended only for Silverblue specific issues. We would like to ask you to try to reproduce the issue on a relevant Fedora Workstation release. If you will be able to reproduce there, then please report it in Red Hat Bugzilla or in upstream (preferred for GNOME projects) and not in this issue tracker.
Describe the bug
I can't update silverblue. I run rpm-ostree upgrade, then reboot but the update is not implemented. I'm on 36.20220810.0 and want to update to 36.20220812.0
To Reproduce
Please describe the steps needed to reproduce the bug:
Expected behavior
system to update to newest version 36.20220812.0
Screenshots
If applicable, add screenshots to help explain your problem.
OS version:
Additional context
I'm only running silverblue, no dual boot
The text was updated successfully, but these errors were encountered: