I've been using Fedora with a "simple" LVM setup with no problems for the least 3 years. Recently I've decided to set up my laptop with LVM on top of LUKS in F23. While migration from the previous setup was relatively painless, I've been noting issues with shutdown: I consistently observe logs stating failure to properly deactivate the logical volumes and the LUKS device (as reported by others in bug 1097322 , which unfortunately has been closed due to EOL). I don't know if they are spurious, which led me to investigate a bit about how things work, and I'm failing to make sense of it.
I've noticed the existence of `blk-availability.service` in systemd. It's a service that does nothing on start, and calls the `blkdeactivate` executable on system shutdown, after the "special block-device" services (LVM, iSCSI, etc) have stopped. `blkdeactivate` is called with the option to umount devices in use. But I don't see how it can ever succeed for the system root: other services will still be shutting down, and systemd's unmounting phase will not have been reached yet. The same might hold true for non-system-root mounts as well, if services that depend on them are in the same situation.
My understanding was that special block-device handling was a task performed by dracut in the initramfs. It does have a shutdown hook called `dm-shutdown.sh` that uses the `dmsetup` executable to remove any device-mapper devices still enabled. I don't see any shutdown hooks for the LVM module, so I assume the DM module also takes care of them. Is my understanding correct?
Wouldn't it be possible to replace the custom DM hook with a call to `blkdeactivate`, and remove the `blk-availability` service from the "normal root" shutdown? Could that possibly work better than the current setup, since `blkdeactivate` claims to be capable to handle nested device-mapper setups, and to be able to use LVM commands in a more intelligent way (for example, deactivating whole volume groups at once)? Shouldn't `blkactivate` at least be told not to unmount the root, as it will always fail?
Apologies if I said anything egregiously wrong, and I'd be glad to be corrected in that case.
Thanks and happy holidays,
koschei it reporting build failures for octave with new nss/libsecret on i386
(works on x86_64):
scripts/statistics/distributions/unidcdf.m ..................X I/O error
*** Error in `/builddir/build/BUILD/octave-4.0.0/src/.libs/lt-octave-gui':
corrupted double-linked list: 0xecd3bf58 ***
seems a weird error, so perhaps just a coincidence but I'm curious if there
are other issues.
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
Release notes for FF 43.0.2 say that a security issue was fixed (MD5
signatures accepted within TLS 1.2 ServerKeyExchange in server
signature). Does this not affect Fedora builds?
PS. The link to that security issue is broken (https://www.mozilla.org/
en-US/security/advisories/mfsa2015-150/), so not quite sure any more
what is real and what's not on Mozilla site.
A new version of arb has been released with a new soname. As far as I
can tell, sagemath is the only consumer. I will build the new arb in
Rawhide and rebuild sagemath as well.
I recently added the package python-rpdb to F22/23/rawhide. The build
failed in Koji due to having a BuildRequires on python3-devel. It seems
that it is called python34-devel in EL 7. This leads me to wonder on a
0) Should I call my package python34-rpdb in EL 7 for consistency? There
don't seem to be very many Python 3 packages for EL 7 at all (yum search
only found a handful) but it seemed that there are a few doing this.
Alternatively, I could just build the python2 package.
1) What is the recommended strategy for handling my spec file if I
attempt to do different things in EL 7 than I do in F22+? I had
considered just making this change to the spec file in that branch, but
since this would require raising the release it could make upgrade from
EL 7 to EL 8 tricky if the package version doesn't change upstream. Is
it better to use if statements in the spec file? I like the idea of very
clean spec files that work on one specific release, but on the other
hand I do see the potential for upgrading to be disrupted. I found this
Is that saying that it is OK for me to avoid the if statements and just
make the epel7 branch's spec file provide and require the 34 packages
and the .1 will make the upgrade path OK?
I'm new to Fedora packaging, so apologies if I've missed the answer to
this question in an obvious place.
irc: bowlofeggs on Freenode