On Wednesday 28 October 2015 05:21:13 Duncan wrote:
>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.

I haven't found any single command that lets you do that, but I can try one of 
the special targets as detailed in bootup(7) (e.g., initrd.target) when I have 
a chance.

>>>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.

My kernel is fairly modular, and I use dracut to make my initramfs, so I 
wouldn't be surprised if it works.  For me, personally, I just don't see any 
point in making btrfs a module.

(And yes, of course I know you run Gentoo ;-) .)

>So I definitely sympathize with the feeling that such a stone is better
>left unturned, if overturning it is at all a possibility that can be
>avoided, as it is here, this whole exercise being simply one of better
>pinning the bug down, not yet actually trying to solve it.  And given
>that unturned stone, there are certainly easier ways.
>
>And one of those easier ways is investigating that whole systemd return
>to initr* idea, since we both remember reading something about it, but
>aren't familiar with the details.  In addition to addressing the problem
>headon if anyone offers a way to do so, that's the path I'd be looking at
>right now.

Like I said above, I'll try it out when I have a moment where I have a more 
"steady hand" so-to-speak.

[snip deleted files stuff]
>app-admin/lib_users
[snip the rest of the deleted files stuff]

I use that to find processes that need restarting after upgrades, though I'll 
sometimes check to see if it's really a library that's causing it to show up, 
since often a process is listed because of stuff like the font cache, or, in 
the case of the FISH shell, it's own history file.

But yeah, didn't think of running that, but in rescue mode there were at most 
a dozen processes running, so there's not much to choose from, anyway.  I did 
have to kill two remaining user processes first (pulseaudio and... I forgot 
the other one).  I didn't try the same with / and /var because I was eager to 
get back to a normally running system ;-) .

>Of course, if lib_users reports nothing further still holding references
>to deleted files, and a remount read-only STILL fails, that's a major
>note of trouble and an important finding in itself.

I don't expect that, but I'll make note of it if I encounter it.

>Meanwhile, as explained in the systemd docs (specifically the systemd for
>administrators series, IIRC), systemd dropping back to the initr* is
>actually its way of automatically doing effectively the same thing we
>were using lib_users and all those restarts to do, getting rid of all
>possible still running on root executables, including systemd itself, by
>reexecing systemd itself back in the initr*, as a way to help eliminate
>*everything* running on root, so it can not only be remounted read-only,
>but actually unmounted the same as any other filesystem, as userspace is
>now actually running from the initr* once again.  That's a far *FAR*
>safer reboot after upgrade than traditional sysvinit solutions were able
>to do. =:^)

Yeah, the ability to do that is a nice plus of using an initramfs.  Although 
I've never been clear on why it's *safer*.  Is it because the remount might 
fail?  Or are there other reasons, too?

[...]

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup