Re: first it froze, now the (btrfs) root fs won't mount ...

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3398 bytes --]



On 2019/10/24 下午6:41, Christian Pernegger wrote:
> I must admit, this discussion is going (technical) places I don't know
> anything about, and much as I enjoy learning things, I'd rather not
> waste your time (go make btrfs better! :-p). When all is said and done
> I'm just a user. I still don't understand how (barring creatively
> defective hardware, which is of course always in the cards) a crash
> that looked comparatively benign could lead to an fs that's not only
> unmountable but unfixable; how metadata that's effectively a single
> point of failure could not have backup copies designed in that are
> neither stale nor left to the elements, seems awfully fragile -- but I
> can accept it. Repair is out.
> 
> Recovery it is, then. I'd like to try and build this rescue branch of
> yours. Does it have to be the whole thing, or can btrfs alone be built
> against the headers of the distro kernel somehow, or can the distro
> kernel source be patched with the rescue stuff? Git wasn't a thing the
> last time I played with kernels, a shove in the right direction would
> be appreciated.

Since you're using v5.0 kernel, it's pretty hard to just compile the
btrfs module.
As there are 3 kernel updates between them.

Before compiling the kernel, you need a working toolchain.
Please refer to your distro (you'll see this line for a lot of times)

For Archlinux example, you need:
# pacman -S base-devel bc ncurse

I'd recommend to the following ways to compile the kernel:
$ cd kernel-src/
$ make localmodeconfig
$ make -j12

This would  compile the kernel, with all your current loaded kernel
compiled as module.
Then you need to copy the kernel, install the modules, and the most
important part, generate initramfs, then guide your boot loader to the
new kernel.

# cp arch/x86/boot/bzImage /boot/vmlinuz-new
# make modules_install

For initramfs creation, you need to refer to your distro.
I can only give you an example about Archlinux:

# cat > /etc/mkinitcpio.d/custom.preset <<EOF
ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/vmlinuz-custom"

PRESETS=('default')

#default_config="/etc/mkinitcpio.conf"
default_image="/boot/initramfs-custom.img"
EOF

# mkinitcpio -p custom

For bootloader, also please refer to your distro.
But I guess it's less a problem than compiling the kernel.

Then you can boot into the new kernel, then try mount it with -o
"resuce=skip_bg,ro".

And record the dmesg, if anything went wrong.

> 
> Relapse prevention. "Update everything and pray it's either been fixed
> or at least isn't triggered any more" isn't all to
> confidence-inspiring. Desktop computers running remotely current
> software will crash from time to time, after all, if not amdgpu then
> something else. At which point we're back at "a crash shouldn't have
> caused this". If excerpts from the damaged image are any help in
> finding the actual issue, I can keep it around for a while.
> 
> Disaster recovery. What do people use to quickly get back up and
> running from bare metal that integrates well with btrfs (and is
> suitable just for a handful of machines)?
> 
> Cheers,
> C.
> 
> P.S.: MemTest86 hasn't found anything in (as yet) 6 passes, nothing
> glaringly wrong with the RAM.

This doesn't look like a RAM corruption at all. So don't bother that.

Thanks,
Qu
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]