Since I updated a few days ago with kernels 6.2.6 and lts 6.1.19 all of my systems (a pc acting as a headless server with normal kernel, a server with lts kernel, and a laptop with normal kernel) refuse to boot. While trying to diagnose the server, it gets stuck on “Attempting to mount root”, which is a btrfs partition on an lvm volume. If I boot into a rescue usb, all of my partitions mount successfully. I’ve tried downgrading the kernel inside the rescue environment with no change, so I don’t believe it to be a kernel problem. Journalctl holds no answers. I can’t boot into rescuemode without usb either as it gets stuck trying to mount the root. Any clue what could possibly be causing this? It’s not a problem with impatience I left the server running for thirteen hours a day or so ago with it being unable to mount root. Sent from my iPhone
Hi, If it can help, I got a similar issue a few months ago, the culprit was a corrupted btrfs log and the solution was to clear this log with a rescue USB: btrfs rescue zero-log <device> I think it was a dmesg message that helped me Le jeudi 16 mars 2023 à 01:45 -0700, nihilistzsche a écrit :
El jue, 16-03-2023 a las 01:45 -0700, nihilistzsche escribió:
Hi, First of all, putting a btrfs partition in lvm I don't quite get it, what for? btrfs already incorporates dynamic volumes so lvm is completely unnecessary in this context (and is adding a layer of difficulty / possible failure). In any case, once you boot the system in rescue mode are you able to access the data on the partition, can you write into it? Greetings. -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
Yes when I mount them while in the rescue environment they are writable and data persists so I don’t see any corruption. 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. Zeroing the log also did not help. Sent from my iPhone
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).
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
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
participants (3)
-
jl.lecorre＠gmail.com
-
nihilistzsche
-
Óscar García Amor