I’m using Endeavor OS. My computer lost power during system update. Now I can boot into it.
This just happened on another one of my computers with BTRFS. I didn’t run pacman or manually run any other installations or updates. This is on a vanilla ArchLinux machine I’ve installed KDE using archinstall a few months ago. I use this machine often and its the first time it happened on this machine. Perhaps Discovery or Flatpak ran an update in the background. I’m not aware of automatic updates being enabled though.
I have a problem when my computer where when I put it in sleep, or press the power bottom once, it automatically turns back on after sleeping / shutting down. I get frustrated with this sometimes and force shutdown my computer, either by holding the power button or pulling the cable. I know I shouldn’t do this. Turning on my monitor, going into the UI, safely shutting down my computer can become very time consuming on my busy schedule. Its rare it happens, but life happens and I sometimes don’t have time to wait a minute for my computer.
May I note when going through archinstall and choosing a filesystem, do we want BTRFS or EXT4 to be shown as the default option? Currently BTFS is shown. And there is no way these errors are happening this easy for me, and not across the board.
The backup time machine aspect as BTFS is what drawn me. Except now I strongly agree with @CrankyRebel to stay away from BTRFS, at least for personal out-of-the-box Desktop filesystems.
This reply within this thread helped me with this other machine. I’m back up and running well again. https://lemmy.ca/post/48538362/17944139
I’m guessing SystemD wasn’t broken on this one like the other one.
Thanks @take6056@feddit.nl
Boot a live environment, chroot in to it and re-run the update.
There ist a btrfs Error in the Log.
Do Not Update. Fix your Filesystem! (Live USB Stick and btrfs-check)
Some ppl are missing the point. Ignore any instructions that are telling you to repeat any upgrades - you clearly have a btrfs (filesystem) corruption that needs to be sorted out. I don’t use btrfs in a while but if you’re lucky then a ‘btrfs-check’ should be able to fix it. You need to boot from an install/live disk, and run the command on your disk, without installing, nor mounting the disk.
No errors came up when I tried that.
My system was also freezing with message “Starting Flush Journal to Persistent”.
Adding the following to /etc/systemd/journald.conf made the error go away. Storage=persistent
Then the system was freezing with message “Create files and directories.” Doing the following made the message go away.
mv /tmp /old.tmp mkdir /tmp chmod 777 /tmp
But now I’m system freezes with message “Starting D-Bus System Message Bus”
I’ve had this exact error a couple of weeks ago. You have to clear the replay log (and lose potentially 30 seconds of disk writes). Let’s see if I can find exact instructions before the end of my commute.
This is the command I used after unlocking the luks device in a rescue environment and confirming it not mounting further:
sudo btrfs rescue zero-log /dev/mapper/luksrootAfter that, I could mount again and boot.
Here’s more info on the command, to verify advice is sound: https://manpages.debian.org/testing/btrfs-progs/btrfs-zero-log.8.en.html#zero
EDIT: For me it didn’t happen during an update, btw. You might still need the chroot approach to make the system bootable again.
Thanks. I tried this, was able to get into my system. After playing around with WPA_supplicant and IP link, I was able to get internet and run the updates with pacman.
But I’m getting a similar problem as I was having at some point before, where I boot into a black screen, I can change the terminal with CTL + Alt + F1, then my login screen shows up, put my password, and the login freezes.
When I booted into my system earlier to do the updates, I used init=/bin/bash, but SystemD didn’t auto start then, hence why I used WPA_supplicant. Perhaps SystemD is still not starting, hence why I’m not able to log in or open other terminal window.
This worked for me. Thankfully, I didn’t have a hard crash during an update, so my system proceeded to boot normally.
The craziest part is that I didn’t google this. My computer crashed, I rebooted it via magic sysrq keys, and then booted to an error.
I went on Lemmy on my phone out of frustration and by sheer chance one of the first things I saw was a solution.
Are you using BTRFS as your file structure? If so, this is the little dirty secret the BTRFS fans don’t like to discuss. It is well documented in the BTRFS wiki, that during power-outages/power fails, even OS errors, files become corrupt under BTRFS. I finally had enough of this happening to me (lots of power outages where I live,) and switched back to ext4, never had this issue again.
How often did it corrupt for you? As a BTRFS user, is there anything that can be done about it short of reformatting?
It did it first on my PC, then it happened again on my laptop. That is when I investigated the cause and found out BTRFS corrupts on hard shutdowns/failures. Beyond maybe a UPS battery backup that will allow you to MAYBE have some extra time to shut down properly before the battery fails, no. I would highly recommend backing up your data and reformatting to ext4.
I have several (at least 5) BTRFS filesystems, on SSDs and HDDs of varying speeds, with somewhat longer cache writeback and commit times, AND some wire problems that trip my apartment breakers once or twice every month;
I’ve been using BTRFS for about a year and a half, and at worst I suffered loss of newer data.The BTRFS users are relying on backup systems, so make sure you have extensive backups as power failures can happen at any moment, etc. For me personally, a files system that so easily corrupts files, especially when power failures occur frequently, is not what I want. I will stick with ext4, a log file system, which is more stable.
BTRFS lets me backup my stuff more conveniently too, although it does start throwing a tantrum if you run out of space due to COW…
All the drives in my file server are btrfs. Is there an easy way to switch in place? I don’t have enough spare space to hold everything while reformatting.
I don’t think you can switch filesystems with files in place, sorry.
Never listen to BTRFS shills. EXT4/XFS or bust.
LUKS > LVM > ext4
Every time I install a new OS I ask myself if I should use BTRFS, if for no other reason than just to experience it. But I’ve never found a good enough reason that’s worth even a sliver of stability loss over more mature options.
It’s probably because I’ve also been burned too many times trying ReFS over NTFS on Windows (except for Veeam).
Scenarios as this one are why you need backups. Always.
And yes, Ext4 is a log file system which is much more stable in the scenario of a power outage, but it won’t protect you e.g. from faulty RAM and corruption of kernel data structures.
On top of that, it can also be a adequate solution to use BTRFS (plus backups) for a system install of a few GB, and EXT4 (PLUS BACKUPS) for user data.
Also, because sibling comment mentions LVM, it is great, and solid, but it has its own complexity which introduces extra chances for user error. And user error is a main cause for data loss, so it is no silver bullet either.
How do i backup my filesystem? It is a 2tb drive… where do i backup my filesystem to?
Are we saying that BTRFS corruption is not recoverable? 😦
Usually with several larger external drives, e.g. 8 TB.
Are we saying that BTRFS corruption is not recoverable? 😦
You need to check the docs for the version you are using. Generally, in that area it is much weaker than ext4.
Is this a use case for snapshots?
- create snapshot
- # pacman -Syu
- if boot fails, boot from last snapshot
I think I’m getting the same error as OP, and booting from a snapshot sadly does not work.
Follow the instructions you did when you performed a manual Arch install up to the step where you ran
arch-chroot, then re-runsudo pacman -Syu. Google (duck duck go) any error messages you receive if any and work through each to resolve. Theoretically you shouldn’t have any, but just in case.deleted by creator
