I figured it out, i needed some new command line arguments I had added from the wiki, but it had appeared to not be working because as part of my troubleshooting i had installed the normal arch Linux lts instead of my custom one, made the edit to my custom one, and it was still trying to boot the non custom one. But I will make the same changes on my other systems and I expect they will work too. Sent from my iPhone > On Mar 16, 2023, at 03:03, Óscar García Amor <ogarcia@xxxxxxxxx> wrote: > > El jue, 16-03-2023 a las 02:47 -0700, nihilistzsche escribió: >> Yes when I mount them while in the rescue environment they are >> writable and data persists so I don’t see any corruption. >> > In that case the only thing I can think of is that for some reason the > disk identifier has changed. When you boot the kernel you are passing > it as a parameter which is the root partition, something like this: > > vmlinuz-linux root=UUID=fa043186-0fbf-4c8d-a17a-a190813b9d1f rw > rootflags=subvol=@ > > Check that this value has not changed and that it is still the same, > because if it has been modified then it may be that it stays "thinking" > eternally waiting to find it (although it seems strange to me because > it should give an error, but well, who knows). > >> As for btrfs on lvm i understand it’s unnecessary but I’ll just say >> it’s personal preference and I don’t normally need to ask for help >> but as i can’t get my systems to boot I have no choice. Been running >> these systems are almost nine years now and this is the first time >> I’ve run into an issue that wasn’t obviously caused by myself or >> easily fixed. >> > No, if you are happy with that setup, nothing to object to. I was > simply commenting because using btrfs you can simplify it and eliminate > possible points of failure. > > Greetings. > > -- > Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
