errors reported during update after setting attrib +i on config file
at some point I ran
now when updating I get errors like
The update process runs as usual but I do get a prompt and an error message each time.
Undoing the attribute change now doesn't seem to help.
37 Replies
did you remove it with
sudo chattr -i /etc/systemd/zram-generator.confyes, but doing so didn't seem to make a difference
have you done any custom changes to it?
why did you make it immutable to begin with?
a guide written for fedora (not bazzite) suggested doing so, I disabled zram to enable swap (and hoping to enable hibernation, but nevermind that)
just changing the file itself should be enough for updates to not touch it since your changes are prioritized
try just restoring the original and moving the changes back
you can find the original in
/usr/etc/
rm or mv the file first then cp the original from /usr/etc/systemd/originally there was no file, the guide I followed instructed to touch an empty file there to disable zram
thats odd because we setup zram through that file
this is for fedora workstation which is not the same as fedora silverblue or fedora kinoite
ah, I see I
sudo cp /dev/null /etc/systemd/zram-generator.conf to disable it
what did you mean "moving the changes back?"you had not sent the link, i assumed you had edited the file
now I'm looking to remedy the situation where I have this immutable file in my /ostree/
I'm not looking to re-enable zram
when maybe consider, delete the file
copy original back
remove content from the copied original
tada š
becaus
/ostree should never be edited directly
its literally the physical location of your /why would copying the original back help?
becase removing the immutability from the file didnt help so remove the file reference completely and see if that helps
which you do by deleting
then copying the new file
and then just empty the file since you dont want anything in it
or just delete the file and re-touch it, whichever makes you happy
in /etc/systemd ? will this address the immutable file in /ostree/ ?
please just try
and if you have had 2 updates while it has been immutable, go into both deployments (ostree:0 and ostree:1) and make the file mutable again
that gives an error,
/etc is not read only
literally only /usr is read only
when the rest of the system goes read only you either have a corrupt btrfs filesystem or you have messed up something
the rest of the system is not read-only
yeah well
/sysroot which is / and /usr is read only which is correctand that is where the immutable file is
yes in
/etcwhich is not immuatbleI'm guessing a copy was made or something during the update process and I got stuck with an immutable file where there shouldn't be one
the current /etc/ is not ro as expected
come back when you have tried that and rebooted
on both
ostree:0 and ostree:1after that I still have one immutable file there
rpm-ostree status -vyeah so your index 1 is broken
idk about fetching image metadata, I think that problem is newer than the unlink during upgrade problem
also booting off the 2nd grub entry seemed fine
you ran the commands on both right?
in both entries
oh, I understood you to say "reboot on both"
I think I've resolved the issue by:
something like that was going to be my last resort since that can severely break things
I think what you suggested may have worked if I'd acted sooner
if it works and does not cause issues, good but avoid doing anything like that in the future, if you need to make something immutable make it not be a part of the root system, only a part of external mounts or your home š
your own changes to
/etc are prioritized over what we provide with updates
essentially if you have edited a file in etc, it will not be overwritten by an update
if you delete a file though that is provided by an update, it will be restored on boot
files like /etc/fstab however are local for you meaning you have the only valid copy, those will never be "restored" if deleted, thats just one way to brick your install so dont delete thatchattr +i was probably not strictly required even for plain fedora, but I didn't consider the effect it would have when following the instructions I'd found
if you want to
restore a default file, the best way is to copy it from /usr/etc
yeah i have no idea why they even recommended that
anyways glad it works, but if you start seeing errors that might be side effects from this, consider a reinstall if you cant figure it out.
if you see no errors, good, dont do anything and move on with your day š
anyways im going back to gaming, my friend has been waiting to start this bossfight for a bit now š