(Bonus update) I’m back on KDE6 and it’s actually working! I ran Cinnamon for about a day before missing KDE and tried a fresh install of EndeavourOS. It worked fine, Wayland still doesn’t work but I’m only getting minor bugs with x11 compared to when I tried to update from 5.27
(Update) Well finally back on my desktop but sadly not on my original install, Thanks for all the help and advice! Sadly every path just sent me into another brick wall, I’m starting to think my drive itself is physically failing as I couldn’t mount it in chroot and even had trouble reformatting it…I’ll keep an eye on it and not save anything important to it.
I’ve decided I’m just not cut out for vanilla Arch just yet and gone back to Endeavour but this time with Cinnamon (for now) Thanks again!
After upgrading to KDE 6 and experiencing too many bugs for it to be useable for me I went back to a snapshot I made right before upgrading.
Now I’ve spent half my Friday tracking down different systemctl errors and trying to fix corrupted conf files from live USB environments, physically unplugged all but my nvme boot drive.
Rn I’m in a situation where I’m getting
[FAILED] Failed to mount /boot. See ‘systemctl status boot.mount’ for details [DEPEND] Dependency failed for Local File System.
Then it’s asking to give root password or press control-D, which I’ve dealt with before but this time my keyboard just doesn’t work
I tried to just sort it myself reading the Arch Wiki before begging for help on forums but I’m kinda at my wits end, This is a pretty new Arch installed and the first time using btfs on my main drive, I last updated maybe 4 days ago before today. I’ve also successfully restored from timeshift snapshots on this install before without issues.
Any help where to go from here would be great, thanks in advance.
You must log in or register to comment.
So you rolled back your root filesystem’s system state to a snapshot but did you roll back the kernel you’re booting into aswell?
If you didn’t, that’d explain the symptoms seen here; you might be booting into a newer kernel than the system state has modules for. Without the appropriate kernel modules, Linux cannot mount filesystems or accept keyboard input. (This depends on which modules are required by the HW and whether they’re built into the kernel or copied to the initrd though.)
For debugging, simply boot a live ISO and chroot into the system. The Arch Wiki has a page for that. You should be able to look at the journal inside the chroot and it’ll tell you exactly what’s wrong.
I rolled back using timeshift, which I have used many times before without issue.
I’m not sure it that also rolls back the kernal but I seem to recall it typically does? I can be mistaken.
That fully depends on where your kernels are stored. If they’re in a separate partition, then no; it won’t roll back with the rest of your system.
Yeah /boot is probably separate to root
They were but both located on the same drive
Linux doesn’t really know about drives, it knows about partitions and mount points.
Obviously this is a simplification, but in general it’s close enough. It also could well be your problem - timeshift doesn’t know or care that /boot is on the same physical drive as the rest of your system: if it’s a different partition, it’s separate.
That doesn’t matter. Snapshots only concern the state of any one filesystem; they do not address separate filesystems in any way.
FAILED] Failed to mount /boot.
Something you did made your boot partition disappear.
Then it’s asking to give root password or press control-D, which I’ve dealt with before but this time my keyboard just doesn’t work
It dropped you into an emergency console. Which makes sense because something has gotten terribly messed up.
It would be helpful if you have some extra details like system specs. Partition layout (is boot, root, and home all on the same drive?). Which FS are you using, etc.
It’s likely you’re only going to get back to a working system with a live environment. You’ll have to manually mount the important partitions (root and /boot), chroot to those mounts, and then repair the bootloader.
I’ve loaded into a live Mint USB I had laying around, Didn’t notice anything too weird within fstab but I removed anything from it that wasn’t my main NVME
My main drive contains everything system related, root, boot, home etc, they’re all still there in fstab
My other drives are just game drives and a backup HDD for storage.
Have you mounted each partition and checked the contents? That’s the first thing you should do.
I’ve sadly formatted over the drive at this point, I did manage to mount the home and root partitions to a live usb but didn’t have any luck getting the boot to mount to anything.
So, what’s in the
fstab, anyways? Full contents uploaded on pastebin or smth similar would be helpful. Same goes for the bootloader used and the method of installation (the proper way or archinstall)Anyway, you can boot into the arch iso, make mounts and re-
genfstab -Uit.I kinda forgot about pastebin but here’s it is https://pastebin.com/VjighWKV
I haven’t touched fstab since setting up my system and only edited it to mount my extra internal drives, my main drive was automatically configured through Archinstall
OK, I haven’t played with btrfs, but maybe the problem is that
subvolidis used: https://wiki.archlinux.org/title/Btrfs#Mounting_subvolumes (the last sentence of the 1st paragraph), although I’m not sure, since there’s also a regularsubvol. Anyways, mb worth investigating.@fl42v is on the right track. This is a common issue that occurs when restoring snapshots, the subvolid in your fstab might not match the subvolid that’s actually present on the disk.
Run
btrfs subvolume list /and check that the subvolids match. Also runblkidand verify that the UUIDs listed there matches your fstab.
Huh, also, what kind of snapshot, {Btr,z}fs or smth like timeshift?
Timeshift sorry, thought I mentioned it but forgot.
@HouseWolf Maybe try testing the hardware on a known working system.
Come to Manjaro.
Let it do the hard work for you.
🤡
