On 2015-10-28 01:21, Duncan wrote:
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.Marc Joliet posted on Tue, 27 Oct 2015 21:54:40 +0100 as excerpted: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.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.
[ snip ]
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.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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
