Re: Access a Virtual disk without the VM running
On 2023-10-14 15:04, George R Goffe via test wrote: Ideally, I would mount the VDI on the host and just copy the file. Is there a way to do this easily? https://rwmj.wordpress.com/2010/10/04/tip-open-virtualbox-vdi-file-using-libguestfs/ guestfish tools should work... ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: systemd TPM2 support seems to be broken in F36 beta
On 3/29/22 11:41, Gordon Messmer wrote: In Fedora 35, I am able to use the tpm2 device to automatically unlock a LUKS volume on boot. Dracut 055 has a bug in the tpm2-tss module, requiring either applying https://github.com/dracutdevs/dracut/commit/8b17105bed69ed90582a13d97d95ee19e6581365 and then including the tpm2-tss module in dracut.conf, or including the library files directly. First problem: systemd added cryptsetup modules, so in addition to that commit, you'd need both of these: https://github.com/dracutdevs/dracut/commit/c656b612b101e4834e01f9841162e2629a7272f7 https://github.com/dracutdevs/dracut/commit/4753738b62d958955f50fb077ea21c56a8d23dc3 (I see dracut 056 in rawhide... I'm *real* sad that it didn't make it into F36, for this reason) Second problem: when I was testing earlier, the cryptsetup modules appear to have been incorrectly packaged in the "systemd-devel" package. That problem was fixed in 250.3-7. device=/dev/nvme0n1p3 systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7+8 $device sed -ie '/^luks-/s/$/,tpm2-device=auto/' /etc/crypttab echo 'install_optional_items+=" /usr/lib64/libtss2* /usr/lib64/libfido2.so.* /usr/lib64/cryptsetup/libcryptsetup-token-systemd-tpm2.so "' > /etc/dracut.conf.d/tss2.conf dracut -f Since dracut 055 requires several patches, the easiest way to restore working tpm2 support seems to be just bundling the libraries manually, as above. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd TPM2 support seems to be broken in F36 beta
On 3/29/22 11:41, Gordon Messmer wrote: Does anyone have suggestions for debugging this issue? I've booted into a dracut shell and confirmed that the tpm device nodes are present... Trying to manually attach the LUKS volume prints no error messages, but prompts for a passphrase rather than attaching using the TPM2 device. # /usr/lib/systemd/systemd-cryptsetup attach luks-testvol /dev/disk/by-uuid/ - tpm2-device=auto ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
systemd TPM2 support seems to be broken in F36 beta
In Fedora 35, I am able to use the tpm2 device to automatically unlock a LUKS volume on boot. Dracut 055 has a bug in the tpm2-tss module, requiring either applying https://github.com/dracutdevs/dracut/commit/8b17105bed69ed90582a13d97d95ee19e6581365 and then including the tpm2-tss module in dracut.conf, or including the library files directly. device=/dev/nvme0n1p3 systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7+8 $device sed -ie '/^luks-/s/$/,tpm2-device=auto/' /etc/crypttab # Either this: echo 'install_optional_items+=" /usr/lib64/libtss2* /usr/lib64/libfido2.so.* "' > /etc/dracut.conf.d/tss2.conf # Or apply the commit mentioned above and: echo 'add_dracutmodules+=" tpm2-tss "' > /etc/dracut.conf.d/tss2.conf dracut -f However, this doesn't work in F36 beta, and there isn't much information logged to indicate why that is. The F36 beta initramfs generated by dracut appears to have all of the necessary components, but a passphrase is required to unlock the root LUKS volume. On a F35 system, the journal will contain a couple of log entries like: Mar 12 12:11:32 vagabond systemd-cryptsetup[542]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/888c26a9-936b-4377-97f9-612300cc2a8e. Mar 12 12:11:32 vagabond systemd-cryptsetup[542]: Automatically discovered security TPM2 token unlocks volume. However, a F36 system will contain only the first of those two log entries, and no error. Does anyone have suggestions for debugging this issue? ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: bug report https://bugzilla.redhat.com/show_bug.cgi?id=2037703
On 1/25/22 16:09, George R Goffe via test wrote: Could I get someone from this list to take a peek at the above named bug report please? I'm STILL seeing this issue with the "latest" Fedora upgrade. The extra text does NOT appear in the dmesg output. Could it be something with console support in VirtualBox? Yes, it's probably a bug in the VirtualBox console, similar to this one (https://forums.virtualbox.org/viewtopic.php?f=11=96739), which would explain why there is corruption on all lines, and why the garbled text doesn't appear in any of your logs. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: ssh to gnu fails after F33 update
On 10/21/20 5:51 PM, Per Bothner wrote: I was able to get things working again by adding this line to the Host *.gnu.org section of ~/.ssh/config PubkeyAcceptedKeyTypes +rsa-sha2-256,rsa-sha2-512 "rsa-sha2-256,rsa-sha2-51" are already part of the Fedora 33 crypto policy. This configuration works (as I understand it) because the '+' value adds key types to the default set, rather than the local policy. The effect is that the configuration above downgrades the crypto policy so that it includes 'ssh-rsa' again, and that's the key type that ends up used with OpenSSH 7.4 servers. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: ssh to gnu fails after F33 update
On 10/21/20 1:37 PM, Per Bothner wrote: I don't know if this is expected or a Fedora issue, but after I updated to Fedora 33 (in-place) I can no longer do ssh operations with cvs.savannah.gnu.org. This is a bug in the OpenSSH 7.4 server they're using. I provided a patch to work around it in the client, here: https://bugzilla.redhat.com/show_bug.cgi?id=1881301 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Firefox/GNOME crash
I'm noticing that Firefox has been disappearing on Fedora 33 beta, and from the messages recorded in the journal, it looks like it might be a bug in GNOME shell. Is anyone else seeing this? Oct 18 12:49:18 vagabond.private.dragonsdawn.net gnome-shell[2098]: libinput error: event4 - AT Translated Set 2 keyboard: client bug: event processing lagging behind by 130ms, your system is too slow Oct 18 12:49:18 vagabond.private.dragonsdawn.net gnome-shell[2098]: Can't update stage views actor StLabel is on because it needs an allocation. Oct 18 12:49:18 vagabond.private.dragonsdawn.net gnome-shell[2098]: Can't update stage views actor ClutterText is on because it needs an allocation. ... (the above repeats a lot) Oct 18 12:49:20 vagabond.private.dragonsdawn.net gdm-password][98791]: pam_sss(gdm-password:auth): authentication success; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=gordon Oct 18 12:49:21 vagabond.private.dragonsdawn.net gnome-shell[2098]: Can't update stage views actor StLabel is on because it needs an allocation. Oct 18 12:49:21 vagabond.private.dragonsdawn.net gnome-shell[2098]: Can't update stage views actor ClutterText is on because it needs an allocation. ... (the above repeats a lot) Oct 18 12:49:21 vagabond.private.dragonsdawn.net gsd-usb-protect[2342]: Error calling USBGuard DBus to change the protection after a screensaver event: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable Oct 18 12:49:27 vagabond.private.dragonsdawn.net gnome-shell[2098]: WL: error in client communication (pid 91153) Oct 18 12:49:27 vagabond.private.dragonsdawn.net MainThread[91153]: Error reading events from display: Broken pipe Oct 18 12:49:27 vagabond.private.dragonsdawn.net firefox.desktop[98330]: Exiting due to channel error. Oct 18 12:49:27 vagabond.private.dragonsdawn.net firefox.desktop[91733]: [GFX1-]: Receive IPC close with reason=AbnormalShutdown ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Thunderbird - Unpleasant Surprise
On 10/6/20 10:17 AM, Gordon Messmer wrote: One way or another, I need to roll back until SOGo has time to finish porting their extension to the new API. Well, I rolled back, but now the Lightning extension isn't enabled or even visible in Add-ons, so I have to figure out how to fix that. Given that downgrading is not trivial, can this update be backed out ASAP? ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Thunderbird - Unpleasant Surprise
On 10/6/20 4:29 AM, Ankur Sinha wrote: Thunderbird 78 seems to be a major "breaking" upgrade: https://www.thunderbird.net/en-US/thunderbird/78.2.1/releasenotes/#changes I definitely think this should be rolled back. We're past the beta freeze, and IMO, this violates the updates policy which states "Package maintainers MUST: Avoid Major version updates, ABI breakage, or API changes if at all possible." Personally, I think this change warrants its own self-contained change proposal in the next release of Fedora, even though Thunderbird 68 will not receive updates after Sep 2020: https://blog.thunderbird.net/2020/09/openpgp-in-thunderbird-78/ One way or another, I need to roll back until SOGo has time to finish porting their extension to the new API. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: F33 install minimum memory requirements?
On 8/25/20 8:57 AM, Adam Williamson wrote: So the 'official' doc on this, AFAIK, is https://docs.fedoraproject.org/en-US/fedora/rawhide/release-notes/welcome/Hardware_Overview/ which still cites 1GB as the minimum for "the default installation" (which is of course a fairly vague term). 1GB hasn't been enough to run an install for quite a while. https://bugzilla.redhat.com/show_bug.cgi?id=1278260 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Umask in Fedora 26 ?
On 05/01/2017 09:42 AM, Peter Gueckel wrote: For some reason, my setting in .bash_profile is no longer being honoured in Fedora 26! Why? Are you talking about ssh or terminal login sessions, or graphical logins under Wayland? I suspect the latter, as Wayland sessions don't (or didn't) run the shell profile like X11 sessions did. This was reported "fixed" but I wonder if it has returned: https://fedoraproject.org/wiki/Common_F25_bugs#GNOME_Wayland_session_does_not_start_a_login_shell.2C_so_does_not_process_.bash_profile_or_.bashrc_etc. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
Re: Congratulations for F24ß
On 05/11/2016 08:01 AM, Peter G. wrote: How do you type the Greek beta from the keyboard (I use US dead keys—always and exclusively)? One way is C-S-u 0 3 b 2 Space Not entirely convenient or memorable. -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: Congratulations for F24ß
https://en.wikipedia.org/wiki/%C3%9F Why eszett? -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: DNF and https
On 04/09/2016 07:35 AM, Russel Winder wrote: I have experimental evidence that dnf fails using https if the repository site certificate is a Let's Encrypt one. Is this a bug or a feature? Have you correctly included the certificate chain? If not, your browser might have the required intermediate certs, so you won't get a warning there. Clients that don't have a similarly complete certificate store would fail. -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: logins and ssh-agent
On 01/07/2016 06:54 AM, Russel Winder wrote: Some moons ago, ssh-agent, was started automatically on login. Which desktop environment? GNOME shell replaced ssh-agent with the GNOME keyring daemon some time ago, though I don't know when. Seems like ages. It's a bit sad, since the keyring daemon doesn't support newer key types. Anyway, is the problem that you don't see the ssh-agent process (which is normal) or that there isn't any agent available? -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: Weird effect of mount command in F23
On Tue, Oct 20, 2015 at 4:53 AM, Joachim Backes < joachim.bac...@rhrk.uni-kl.de> wrote: > 2. sudo mount /dev/sr0 /mnt > then the CD will be inserted, but immeditaly after it inserted, an error > message appears: > mount: no medium found on /dev/sr0 > https://github.com/torvalds/linux/blob/master/drivers/cdrom/cdrom.c When you try to mount the drive, "open_for_data" is called. If the tray is open, the kernel will try to close it. It will then check to see if there is a disc in the drive. What happens at that point varies from drive to drive. Most drive, I believe, and certainly the ones I have access to, will not respond to the status request until they finish checking for media. On those drives, a single mount command will succeed. If your drive responds to the status request before it finishes scanning for media, then the mount command will fail. It's not a kernel bug, it's your drive. You can work around that by calling "eject -t " before mounting the drive. You might also need a delay after calling that command, since your drive seems to respond before it finishes scanning for media. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Password policy not consistent
On 10/19/2015 06:02 AM, Kevin Fenzi wrote: What did it show the reason for not allowing it as? I don't know. I ran the install again, today, and that password is now "Good" instead of "Weak". I guess someone changed the pwquality configuration in the install images? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Is NetworkManager-wifi not installed by default?
My test installation of Fedora 23, with packages selected by a kickstart file, did not include NetworkManager-wifi. I don't see that package listed in comps.xml. Is this a bug? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Password policy not consistent
https://fedoraproject.org/wiki/Changes/Standardized_passphrase_policy I wanted to note that the policy doesn't seem to be standardized, as intended. On 10/16, I installed Fedora using the pxeboot images from: http://mirror.pnl.gov/fedora/linux/development/23/ During installation, I created a new user account, which would not accept the password that I intended to use. That password is nine characters long, contains numbers and capital letters, was generated randomly by "mkpasswd", does not repeat any letters, and does not resemble any words that I'm aware of. After installation, that user was able to use "passwd" to set the same password that Anaconda would not accept. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Is NetworkManager-wifi not installed by default?
On 10/17/2015 01:40 PM, Samuel Sieb wrote: If you're making your own kickstart, you need to include the @networkmanager-submodules group. Thanks. I must have mistyped it when I searched comps.xml, because I see it now. *sigh* -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: openssh linked against old openssl
On 01/09/2015 05:58 PM, Rick Stevens wrote:
It appears that fedup installed openssl-1.0.1j-1.fc21.x86_64 (which
I saw one fedup failure, but didn't have enough information to file a
bug report. It's likely that your upgrade was interrupted somehow and
is incomplete. See if yum-complete-transaction can fix it? Or use
the rpm files that are still in the fedup cache to fix anything that's
broken.
I don't remember all of the details about the broken upgrade that I saw,
but I think the rpm db still recorded both the new and old package
installed, so if you rpm -q openssl you'll probably see two versions
installed. If that's the case, then you can see which other packages
are currently broken with:
rpm -qa --qf '%{NAME}\n' | sort | uniq -d
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd depends so heavily on a files it can not reboot
On 07/08/2013 09:39 AM, John Reiser wrote: 1. Install a userid whose login shell is /usr/bin/sync (or a script which does sync; sync) 2. Login as the sync user (twice, perhaps.) Running sync multiple times doesn't have any particular purpose on Linux. http://utcc.utoronto.ca/~cks/space/blog/unix/TheLegendOfSync -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd depends so heavily on a files it can not reboot
On 07/09/2013 06:17 AM, John Reiser wrote: Yes it does, because the rest of the system might not be quiescent during the first sync. While that is certainly true, sync doesn't make the rest of the system quiescent. The first sync disturbs the system with an impulse of activity. This may cause the rest of the processes to react in strange an wonderful ways, including creating many changed-and-unwritten blocks. Now I can't tell if you're joking. The second sync cleans many of these. Of course this is a classic race condition which might never get resolved, but the probabilities are much more favorable after the second sync than after only the first. That's just silly. The only thing that would make a second sync flush any more blocks than the first one is continued system activity, or in other words, time. Syncing a second time may flush additional blocks, but no more blocks than if you's simply skipped the first. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd depends so heavily on a files it can not reboot
On 07/09/2013 01:42 AM, Gavin Flower wrote: I sync I know what youmean! :) Seriously, thanks for the short history lesson, puts it all into perspective. To be clear, I didn't write it. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Virtually impossible to keep load under 0.5 on idle desktop with F14+kms
On 11/09/2010 01:42 PM, Fabian A. Scherschel wrote: This about cuts the battery life of my laptop in half if I'm not mistaken I understand it's not a blocker, but I can't believe the kernel people don't consider this a bigger problem. Oo That depends on whether there is actually something runnable 50% of the time, or if the kernel is merely measuring things incorrectly. There have been cases of the latter before. If it's a measurement error, you aren't going to see battery life suffer. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
