Begin forwarded message:
I forwarded this to test since F26 is still not released, and they are
deciding whether to release this week. You are much more likely to get
an answer to your question there.
Date: Mon, 29 May 2017 16:46:05 +0200
From: Andrej Podzimek <andrej(a)podzimek.org>
To: users(a)lists.fedoraproject.org
Subject: Systemd keeps trying to re-open an already active LUKS volume
Hi,
I need a piece of advice concerning an encrypted root partition on
Fedora 26. I'm running a custom manual setup created using dnf.
Further context:
* The installation procedure is outlined in this tread -- and quite
likely irrelevant to this question anyway:
https://lists.fedorahosted.org/archives/list/users@lists.fedoraproject.org/…
* The disk layout is described in this comment:
https://bugzilla.redhat.com/show_bug.cgi?id=1297188#c2
Unlike Fedora 23 and 24, both of which booted just fine, Fedora 26 has
two glitches related to my encrypted LUKS root partition:
1. Dracut fails to automatically add the crypt module. It doesn't seem
to care about LUKS-related settings in /etc/default/grub and/or about
the fact that the system runs off an encrypted volume. I had to
manually add add_dracutmodules+="crypt" into /etc/dracut.conf, or else
I wouldn't get a password prompt on boot and the early systemd would
freeze waiting for the root partition to appear. It works normally with
add_dracutmodules+="crypt".
2. Possibly as a consequence of (1), systemd doesn't realize that the
root partition has been already activated and luksOpen'ed at boot time
and keeps trying to unlock it over and over. The consoles are spammed
by messages like this one, basically on every sudo invocation: Password
entry required for 'Please enter passphrase for disk cryptprdell-luks
(plainprdell)!' (PID 5492). Please enter password with the
systemd-tty-ask-password-agent tool!
Of course I tried to run the systemd-tty-ask-password-agent tool and
type in the password. But then systemctl --failed showed a failure in
systemd-cryptsetup(a)plainprdell.service, the auto-generated unit for the
LUKS volume. Presumably, journalctl revealed that the error message had
been "Failed to activate: Device or resource busy". Well, that's indeed
what happens when you try to open a LUKS volume that's already opened.
If I don't use systemd-tty-ask-password-agent at all, systemctl status
permanently shows "starting" and never reaches "running", because of
the LUKS volume it thinks it needs to activate. (I tried systemctl
disable, but nope, that had no effect.)
This appears to have something in common with an ancient bug from 2013:
https://bugzilla.redhat.com/show_bug.cgi?id=924581
Has anything changed (1) in the way Dracut finds out whether the crypt
module is needed (which worked at least up to Fedora 24) or (2) in the
way systemd generates its automatic units for encrypted volumes?
Something must have changed, but I have no idea what it is and how to
get the old behavior back. :-/
My /etc/default/grub and /etc/crypttab are attached. The current kernel
version is 4.11.0-2.fc26.x86_64.
Cheers,
Andrej
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
I asked on AskFedora and got no response. Hoping this list is more active.
https://ask.fedoraproject.org/en/question/104010/nfs-showing-bad-data-f24/
I have a f24 workstation (nfs client). It is updated regularly.
The server is f19, so no updates there.
A problem started in the last few weeks. When I examine a file on the server it
looks OK. The file is updated every minute (collecting some stats) and 'tail' shows
the added lines as they arrive.
Examining the same file from the workstation is initially OK, but then, as the file
grows, I get binary zeroes at the end of the file. The same with tail, less, vi, etc.
The amount of zeroes seems to be the size of the extra data appended to the file.
'ls' shows the actual (full) size of the file. It looks like the utilities see the
correct size but bad data is delivered at the tail.
After a few minutes the full data is showing but then, as the file grows, again I get
zeroes for a few minutes.
Where do I look next?
TIA
--
Eyal Lebedinsky (eyal(a)eyal.emu.id.au)
Hi,all.
I meet this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1445817
When I run dnf upgrade, it faild:
Cannot download 'https://codecs.fedoraproject.org/openh264/26/x86_64/':
repomd.xml GPG signature verification error: Bad GPG signature.
Error: Failed to synchronize cache for repo 'fedora-cisco-openh264'
So, I tried to verify repomd.xml manually, the result is:
$gpg --list-keys
$gpg --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-26-x86_64
gpg: key 64DAB85D: public key "Fedora 26 Primary (26) <fedora-26-primary@
fedoraproject.org>" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
$gpg --list-keys
/home/rlu/.gnupg/pubring.gpg
----------------------------
pub 4096R/64DAB85D 2016-09-09
uid Fedora 26 Primary (26) <fedora-26-primary@
fedoraproject.org>
$gpg --verify repomd.xml.asc repomd.xml
gpg: Signature made Sat 25 Mar 2017 02:41:50 AM CST using RSA key ID
64DAB85D
gpg: Good signature from "Fedora 26 Primary (26) <fedora-26-primary@
fedoraproject.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the
owner.
Primary key fingerprint: E641 850B 77DF 4353 78D1 D7E2 812A 6B4B 64DA B85D
I think this is a success result.
But why dnf is failed?
--
Robert Lu <robberphex(a)gmail.com>
About me: http://about.me/RobberPhex