On 2015-10-28 01:21, Duncan wrote:

Marc Joliet posted on Tue, 27 Oct 2015 21:54:40 +0100 as excerpted:

quoted

quoted

IOW, does it take a full reboot to clear the problem, or is a simple
ro/rw mount cycle enough, or an unmount/remount?

Seems that a full reboot is needed, but I would expect that it would
have the same effect if I were to pivot back into the initramfs, unmount
/ from there,
then boot back into the system.  Because quite frankly, I can't think of
any reason why a power cycle to the SSD should make a difference here.
I vaguely remember that systemd can do that, so I'll see if I can find
out how.

Agree with both the systemd returning to the initr* point (which I
actually had in mind while writing the above but don't remember the
details either, so chose to omit in the interest of limiting the size of
the reply and research necessary to generate it), and the ssd power-cycle
point.

quoted

quoted

Finally, assuming root itself isn't btrfs, if you have btrfs configured
as a module, you could try unmounting all btrfs and then unloading the
module, then reloading and remounting.  That should entirely clear all
in-memory btrfs state, so if that doesn't solve the problem, while
rebooting does, then the problem's very possibly outside of btrfs scope.
Of course if root is btrfs, you can't really check that.

Nope, btrfs is built-in (though it doesn't have to be, what with me
using an initramfs).

Same here, also gentoo as I guess you know from previous exchanges.  But
unfortunately, if your initr* is anything like mine, and your kernel
monolithic as mine, making btrfs a module with a btrfs root isn't the
easy thing it might seem to those who run ordinary distro supplied binary
kernels with pretty much everything modularized, as doing so involves a
whole new set of research on how to get that module properly included in
the initr* and loaded there, as well as installing and building the whole
module-handling infrastructure (modprobe and friends) again, as it's not
actually installed on the system at all at this point, because with the
kernel entirely monolithic, module-handling tools are unnecessary and
thus just another unnecessary package to have to keep building updates
for, if they remain installed.

FWIW, I'm pretty sure that genkernel-next (and possibly genkernel too at 
this point, but that's never had working userland support for BTRFS 
AFAICT) includes btrfs.ko and it's dependencies in any initr* it 
generates when it sees those modules on the system, although I'm not 
100% certain because I always build the driver for my root filesystem 
into the kernel directly.

[ snip ]

What's left in the lib_user list after a dip to emergency mode, whether
you've returned to multi-user mode or not, is often only systemd and
perhaps its journald service, itself.  Journald can be restarted manually
in the usual way (systemctl restart journald.service or whatever, I
usually use tab completion so don't pay all that much attention to the
specific name), if necessary, while systemd itself can be "reexecuted"
using the systemctl daemon-reexec (tab-completion again) command.

Udev might also be listed (for some reason, a lot of distros don't stop 
it when going to emergency mode, I don't know about what Gentoo does in 
this case though because I don't use systemd), and at least the last 
time I checked, dropping to emergency mode on Debian and Fedora testing 
versions also keeps any dhcp clients or other stuff needed for 
maintaining the network connection running as well.