Re: Help with TL-WN823N on Fedora
One factor that makes dnf difficult when poor network communication causes downloads to time out is whatever partial file data has been read is discarded. Dnf starts a new download for the failed file from a different server. If that new download times out, whatever has been received is discarded again, and this repeats -- until the download succeeds, or all mirrors have been tried, in which case dnf fails. Fortunately, whatever files have been successfully downloaded remain in local storage after "dnf upgrade" fails. Repeat the dnf command, and only the missing files (unfortunately, these are usually large files, because they are more likely to time out) will be read again. My problems with this were fixed with a different wi-fi access point. A new wi-fi dongle for your computer may be easier than waiting for better support of the device you have. TL-WN823N is almost a decade old; if it does not work well after this time, it is difficult to think all will be well in a short while. ___ 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: problems upgrading from Fedora 33 to Fedora 34
Qiyu Yan wrote on Sat, 01 May 2021 14:40:34 +0800: It not the last installed becomes the dafault, but the one with highest version nummber. And unluckily, there is a kernel downgrade with the upgrade from f33 to f34. That explains it. The recent F34 update to the 5.11.16-300 kernel restored my default boot kernel to F34. ___ 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: problems upgrading from Fedora 33 to Fedora 34
If no F34 kernal is installed, something went awry during the offline upgrade. Perhaps try the upgrade again, to learn whether this is a consistent failure? One of my systems has a /boot filesystem that is too small. Before I can install a new kernel, I have to manually remove an older kernal in order to have sufficient space. With "dnf upgrade" the operation emits a message about not enough space and does not start. Could it be that "dnf system-upgrade" fails to detect insufficient space, at least in some cases? You can check how much space is available in /boot to learn whether this might possibly be a concern in your case. Despite its great convenience compared to a fresh install, upgrade often preserves old, no-longer-used data that sometimes causes problems. Successive system-upgrades makes this worse. If you cannot find a solution to your system-upgrade difficulty, I would do a new install in order to start with a clean slate. ___ 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: problems upgrading from Fedora 33 to Fedora 34
After upgrade from F33 to F34, the newly-installed kernel was not the default to boot. I had to explicitly select the F34 kernel in lieu of an older F33 kernel at boot time. This was a surprise for me (I expected the last kernal installed to become the default), but it may not be germane in your situation. ___ 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: pipewire and high-res audio
Lukas Ruzicka wrote on Tue, 6 Apr 2021 09:44:22 +0200: >what happened when you tried to reload the services (or restarting >computer)? Ah, the Power-On-Reset panacea. Cures many ills, and cured this one nicely. Both prior to pipewire (F33) and with pipewire (F34), it is possible to obtain 192 kHz output with direct use via ALSA of sound cards that support this frequency. With the change to pipewire configuration: default.clock.rate= 192000 I find pipewire will provide data at this rate when the default output sound device supports it. This is a definite advantage of pipewire over Pulseaudio, which (as far as I know) has no such capability for default output. I tried, without success, to reproduce the original problem. I restored /etc/pipewire/pipewire.conf to its original state, logged out, logged in, rebooted, all without any pipewire crash, and observed the original 48 kHz behavior. I changed pipewire.conf again to specify the 192000 rate: no problem, and output is back to 192 kHz. Good news. Abrt is a different issue, but I suppose it will improve in the normal course of events. ___ 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
pipewire and high-res audio
Questions: 1. How can pipewire be configured for 192000 Hz audio output? 2. Are these problems with abrt at this time of Final Freeze a reason for concern, or normal for the release process? 3. Does the message "Can't find packages for 33 debuginfo files"? below signify some process error? (RPM packages were created and distributed, but the related debuginfo packages failed to be prepared.) Details: I have some 192000 Hz 24-bit audio recordings that I tried to play using F34 and a Focusrite Scarlet 2i2 USB audio interface, using the Strawberry music player. This works well when I configure Strawberry to use ALSA with the 2i2 sound card, but I wanted to see what pipewire would do. I configured Strawberry to use the Pulseaudio server (provided in F34 by pipewire) and discovered output was at 48000 Hz. I read in: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Configuration PipeWire currently has one global sample rate used in the processing pipeline. All signals are converted to this sample rate and then converted to the sample rate of the device. You can change the sample rate in /etc/pipewire/pipewire.conf. and therefore I changed the 48000 to 119000. This made no difference, so I thought to logout then try again, thinking this might be just an initialization problem. When I logged out, pipewire crashed. When abrt tried to report the problem: Retrace job failed (In my limited experience with F34, this seems a very frequent problem.) An attempt to generate a local trace also failed... Analyzing coredump 'coredump' Cleaning cache... Cache cleaning has finished Coredump references 24 debuginfo files Initializing package manager Setting up repositories Looking for needed packages in repositories Going to install 11 debuginfo packages Can't find packages for 33 debuginfo files Packages to download: 11 Downloading 5.93Mb, installed size: 19.85Mb. Continue? 'YES' Downloading (1 of 11) lz4-libs-debuginfo-1.9.3-2.fc34.x86_64.rpm: 100% Extracting cpio from /var/tmp/dnf-ryniker-6l_rpqco/fedora-debuginfo-9605faba16ec80df/packages/lz4-libs-debuginfo-1.9.3-2.fc34.x86_64.rpm Caching files from unpacked.cpio made from lz4-libs-debuginfo-1.9.3-2.fc34.x86_64.rpm Can't extract files from '/var/tmp/abrt-tmp-debuginfo.qhUUtE/unpacked.cpio'. For more information see '/tmp/abrt-unpacking-gw66wjbp' Unpacking failed, aborting download... Can't download debuginfos: [Errno 1] Operation not permitted: '/var/cache/abrt-di/usr' /tmp/abrt-unpacking-gw66wjbp contains: cpio: ./usr/lib/debug: Cannot change mode to rwxr-xr-x: Operation not permitted cpio: ./usr/lib/debug/.build-id: Cannot change mode to rwxr-xr-x: Operation not permitted cpio: ./usr/lib/debug/.build-id/a2: Cannot change mode to rwxr-xr-x: Operation not permitted cpio: ./usr/lib/debug/usr: Cannot change mode to rwxr-xr-x: Operation not permitted cpio: ./usr/lib/debug/usr/lib64: Cannot change mode to rwxr-xr-x: Operation not permitted 1758 blocks ___ 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: [Proposal] The dual head set-up criterion
Should multiple displays be a release-blocking criterion? I can imagine a desire to ship a new release on-schedule because of significant, content that works fine, but with multiple display support deferred for an update because upstream problems are likely to take a while to fix. I am uncomfortable with the notion that a release must wait for all desktops to work with multiple displays on erery architecture. It is desirable, yes, but this sounds like a QA attempt to control development. Your criterion should be limited to hardware that works in single display configurations. I think two displays is a reasonable limitation. Even with that, test coverage will be extremely sparse - there are just too many devices to make tests of different combinations practical. (If we cannot test it, we should not claim a release meets a criterion.) If I can install three graphics adapters in a machine, and each supports four displays, would you require that I can run 12 displays on each desktop? Lovely if it works, but too rare a use case to be a blocker, or even to test on a regular basis. Slots capable of driving a graphics adapter are very limited, but what about USB devices? With a few hubs, I could connect scores of displays, and your criterion asserts they will 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: wi-fi question
> Upgrading: grub2-efi-x64-1:2.06~rc1-3.fc35.x86_64 > 159/498 > warning: /boot/grub2/grubenv created as > /boot/grub2/grubenv.rpmnew > > Upgrading: grub2-efi-x64-1:2.06~rc1-3.fc35.x86_64 > 159/498 > warning: /boot/grub2/grubenv created as > /boot/grub2/grubenv.rpmnew I do not think these are errors. I have seen similar warnings in the past, and think this just indicates some file in the new package would replace an earlier file that appears to contain some modifications. Instead of replacing the (possibly modified) file, the new version is stored with the ".rpmnew" suffix. The user can then explore the difference between the old and new files, and decide what should be done. The purpose is surely to prevent an update causing something to break due to loss of local configuration data. This is why we see a modern preference to place local configuration data in small files added to something-or-other-conf.d directories. Because these pieces are new (i.e. not part of a package, but local to a system) and dynamically included by a configuratioin process, they will not produce this warning message when a package update occurs. ___ 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: Is the Fedora 35 repo having troubles?
Adam Williamson wrote on Wed, 24 Mar 2021 13:01:58 -0700: >You may have a bad systemd build with name resolution issues. Try >creating a file /etc/systemd/resolved.conf.d/nocache.conf with this >content: > >[Resolve] >Cache=no > >and restarting systemd-resolved.service, it may help. This worked for my F34 system, but the change had to be made in the file: /etc/systemd/resolved.conf Thank you, Adam. ___ 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: Is the Fedora 35 repo having troubles?
Also happens with F34: Errors during downloading metadata for repository 'fedora-modular': - Curl error (7): Couldn't connect to server for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-34&arch=x86_64 [] Error: Failed to download metadata for repo 'fedora-modular': Cannot prepare internal mirrorlist: Curl error (7): Couldn't connect to server for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-34&arch=x86_64 [] Disable the three "modular" repositories and dnf will succeed. For example: dnf --disablerepo=fedora-modular --disablerepo=updates-modular --disablerepo=updates-testing-modular upgrade ___ 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: newbie question - Fedora 34
>In my opinion, a good review would be to install on hardware and show >actual real-world work being done with Fedora 34, such as a drawing in >FreeCAD, and how the system differs from Manjaro Gnome 40, Gnome OS, >Ubuntu 20.10, etc. Perhaps for the actual release, but this sounds premature for a Beta version, where significant changes are still possible. Of course, one might practice with a Beta in order to make creation of such material easier once the real product is available. ___ 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: F34 problem reporting problem
I filed: https://bugzilla.redhat.com/show_bug.cgi?id=1940944 for gnome-abrt to document the cpio problem during extraction of debuginfo from a downloaded file. ___ 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: F34 problem reporting problem
Tried again after a few hours. Still trouble with the retrace server, but local analysis was able to say I experienced the already-reported https://bugzilla.redhat.com/show_bug.cgi?id=1937073 Temporary unavailability of the server sounds plausible for the original problem. There are still some sharp edges in abrt. A different problem report complains thus: Querying server settings Retrace server is unable to process package 'tracker3-3.1.0~rc-1.fc34.x86_64'. Is it a part of official 'Fedora 34 (Workstation Edition Prerelease)' repositories? Unknown package sent to Retrace server. Do you want to generate a stack trace locally? (It may download a huge amount of data but reporting can't continue without stack trace). 'YES' Analyzing coredump 'coredump' Cleaning cache... Cache cleaning has finished Coredump references 45 debuginfo files Initializing package manager Setting up repositories Looking for needed packages in repositories Going to install 35 debuginfo packages Can't find packages for 45 debuginfo files Packages to download: 35 Downloading 134.08Mb, installed size: 419.17Mb. Continue? 'YES' Downloading (1 of 35) libffi-debuginfo-3.1-28.fc34.x86_64.rpm: 100% Extracting cpio from /var/tmp/dnf-ryniker-6l_rpqco/fedora-debuginfo-9605faba16ec80df/packages/libffi-debuginfo-3.1-28.fc34.x86_64.rpm Caching files from unpacked.cpio made from libffi-debuginfo-3.1-28.fc34.x86_64.rpm Can't extract files from '/var/tmp/abrt-tmp-debuginfo.aazm1A/unpacked.cpio'. For more information see '/tmp/abrt-unpacking-ja455rpl' Unpacking failed, aborting download... Can't download debuginfos: [Errno 1] Operation not permitted: '/var/cache/abrt-di/usr' There appear to be two problems here: The tracker3-3.1.0~rc-1.fc34.x86_64 package was installed from updates-testing. Might the failure to recognize it be an issue with a server not up-to-date? If so, I should welcome a less ambiguous diagnostic. The /tmp/abrt-unpacking-ja455rpl file with details about the second problem contains: cpio: ./usr/lib/debug: Cannot change mode to rwxr-xr-x: Operation not permitted cpio: ./usr/lib/debug/.build-id: Cannot change mode to rwxr-xr-x: Operation not permitted cpio: ./usr/lib/debug/usr: Cannot change mode to rwxr-xr-x: Operation not permitted cpio: ./usr/lib/debug/usr/lib64: Cannot change mode to rwxr-xr-x: Operation not permitted 249 blocks ___ 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
F34 problem reporting problem
Up-to-date F34 (18Mar21) originally installed from
Fedora-Workstation-Live-x86_64-34-20210316.n.0.iso
tries to report error and says:
--- Running report_uReport ---
Failed to upload uReport to the server 'https://retrace.fedoraproject.org/faf'
Error: curl_easy_perform: Couldn't connect to server
('report_uReport' exited with 1)
No network problem is obvious; ping succeeds:
$ ping retrace.fedoraproject.org
PING retrace03.rdu-cc.fedoraproject.org (8.43.85.61) 56(84) bytes of data.
64 bytes from retrace03.rdu-cc.fedoraproject.org (8.43.85.61): icmp_seq=1
ttl=47 time=22.0 ms
64 bytes from retrace03.rdu-cc.fedoraproject.org (8.43.85.61): icmp_seq=2
ttl=47 time=23.3 ms
Suggestions?
___
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: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
The key appears to be: >possible to switch between implementations. This will also allow for an >easy rollback. Provided this works easily (it should be an explicit part of the test activity) it is reasonable to accept some instability or missing function in the PipeWire facility in order to advance its development. It seems PipeWire is available in F33. The proposed change is to make it Fedora's default. ___ 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: ifdown access denied
Root is pretty much allowed to do everything. If root cannot change your network operation, something indeed appears to be awry. If you cannot figure out what, re-install Fedore will probably set things straight. If not, at least you will have found a well-defined starting point that others might use to try to replicate your problem. ___ 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: ifdown access denied
Try: nmcli general permissions I suspect network-scripts is the "old way" and with Network Manager you need something else to specify who may do what with respect to network connections. ___ 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: criterion proposal: prevent services timing out on system shutdown
>When the UPS says the battery is exhausted, must shutdown now, it's more >than just an aggravation. It should not be. Worst case should be similar to abrupt power failure. (Real case: I pull the wrong plug out of my power strip, disconnecting my server instead of the device I intended to move.) Reboot the server, it recovers filesystems from their journals in a few seconds, and life is good again. If this does not work, then there are more serious problems than time-outs during shutdown, and these problems may indeed be blocker candidates. Your UPS should be able to give an earlier warning than "Battery is exhausted." but there is no completely adequate advance warning. For critical activities, one provides a UPS that can say "Power remains for N seconds." where N is sufficient for application-specific shutdown (not system shutdown, though that may also occur). Even this is not proof against catastrophe and user error, but greater durability requires mutiple systems, automatic fall-back, and more exotic strategies. Personally, I should be very happy to have faster shutdown and boot times. I just feel these are quality, not blocker issues. ___ 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: criterion proposal: prevent services timing out on system shutdown
I think failure to shut down promptly should not be a "blocker" event. Is shutdown in three minutes instead of three seconds an aggravation for the user who wants to use a new kernal or another operating system? Yes. Does unreasonable time to shut down indicate lack of quality in Fedora? Of course. However, to call this a blocker looks like an attempt by QA to extort developers to address a defect that has little impact on usability. If you do not want to wait so long for shutdown, pull the plug, or learn how to configure what services run and how long they wait when told to stop. This is not a true blocker. Real blockers must have greater impact: problems like dnf unable to update a system, faults that prevent network access, or inability to start a graphical desktop. ___ 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
Killer Wi-Fi 6 AX1650i
I am happy to see the 5.6.0-0.rc0.git5.1.fc32.x86_64 kernel recently deployed to Rawhide supports the "Killer Wi-Fi 6 AX1650i 160MHz Wireless Network Adapter (201NGW)" in my Dell XPS 13 laptop. The earlier 5.5 kernels did not initialize and use this wireless hardware. ___ 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
Rawhide selinux problem
After an update of my Rawhide system yesterday, it refused to boot. A change to /etc/selinux/config to set SELINUX=permissive avoids the problem. This may be a one-off situation due to my particular sequence of updates, unless others have similar troubles. The system log for the failing boot has the following, which may not be relevant, but is the only selinux data that apears remarkable: Jan 25 22:10:12 xps13 systemd[1]: Reached target Local File Systems (Pre). Jan 25 22:10:12 xps13 systemd[1]: Condition check resulted in Virtual Machine and Container Storage (Compatibility) being skipped. Jan 25 22:10:12 xps13 systemd[1]: Starting File System Check on /dev/disk/by-uuid/543acebd-af86-46a7-9a29-d6cef33a1c95... Jan 25 22:10:12 xps13 systemd[1]: Starting File System Check on /dev/disk/by-uuid/6A06-AE8A... Jan 25 22:10:12 xps13 systemd-fsck[912]: /dev/nvme0n1p7: recovering journal Jan 25 22:10:12 xps13 systemd-fsck[912]: /dev/nvme0n1p7: clean, 105/128016 files, 261937/512000 blocks Jan 25 22:10:12 xps13 systemd[1]: Started File System Check on /dev/disk/by-uuid/543acebd-af86-46a7-9a29-d6cef33a1c95. Jan 25 22:10:12 xps13 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-fsck@dev-disk-by\x2duuid-543acebd\x2daf86\x2d46a7\x2d9a29\x2dd6cef33a1c95 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Jan 25 22:10:12 xps13 systemd[1]: Mounting /boot... Jan 25 22:10:12 xps13 kernel: EXT4-fs (nvme0n1p7): mounted filesystem with ordered data mode. Opts: (null) Jan 25 22:10:12 xps13 kernel: ext4 filesystem being mounted at /boot supports timestamps until 2038 (0x7fff) Jan 25 22:10:12 xps13 systemd[1]: Mounted /boot. Jan 25 22:10:12 xps13 systemd-fsck[913]: fsck.fat 4.1 (2017-01-24) Jan 25 22:10:12 xps13 systemd-fsck[913]: 0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt. Jan 25 22:10:12 xps13 systemd-fsck[913]: Automatically removing dirty bit. Jan 25 22:10:12 xps13 systemd-fsck[913]: Performing changes. Jan 25 22:10:12 xps13 systemd-fsck[913]: /dev/nvme0n1p1: 430 files, 18932/126976 clusters Jan 25 22:10:12 xps13 systemd[1]: Started File System Check on /dev/disk/by-uuid/6A06-AE8A. Jan 25 22:10:12 xps13 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-fsck@dev-disk-by\x2duuid-6A06\x2dAE8A comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Jan 25 22:10:12 xps13 systemd[1]: Mounting /boot/efi... Jan 25 22:10:12 xps13 mount[917]: mount: /boot/efi: unknown filesystem type 'vfat'. Jan 25 22:10:12 xps13 systemd[1]: boot-efi.mount: Mount process exited, code=exited, status=32/n/a Jan 25 22:10:12 xps13 systemd[1]: boot-efi.mount: Failed with result 'exit-code'. Jan 25 22:10:12 xps13 systemd[1]: Failed to mount /boot/efi. Jan 25 22:10:12 xps13 systemd[1]: Dependency failed for Local File Systems. Jan 25 22:10:12 xps13 systemd[1]: Dependency failed for Mark the need to relabel after reboot. Jan 25 22:10:12 xps13 systemd[1]: selinux-autorelabel-mark.service: Job selinux-autorelabel-mark.service/start failed with result 'dependency'. Jan 25 22:10:12 xps13 systemd[1]: local-fs.target: Job local-fs.target/start failed with result 'dependency'. Jan 25 22:10:12 xps13 systemd[1]: local-fs.target: Triggering OnFailure= dependencies. Jan 25 22:10:12 xps13 systemd[1]: Reached target Timers. ___ 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
gsd-power fault in Rawhide
With up-to-date (23 January 2020) Fedora Rawhide on a Dell XPS-13 7390 laptop machine, after resumption from suspend, or switching from an alternate colsole back to the graphical console, I see the expected graphical login screen. After I enter the correct password, I see a dark screen (or sometimes the graphical desktop for a couple of seconds followed by a dark screen). Ctrl-alt-Fn works to switch to an alternate console. A complete log file with multiple occurrences is here: http://ryniker.org/Fedora/log11 The interesting sections look like this: Jan 23 11:00:17 xps13 systemd[7852]: Starting D-Bus User Message Bus... Jan 23 11:00:17 xps13 dbus-broker-launch[8477]: Service file '/usr/share//dbus-1/services/org.gnome.evolution.dataserver.Sources.service' is not named after the D-Bus name 'org.gnome.evolution.dataserver.Sources5'. Jan 23 11:00:17 xps13 dbus-broker-launch[8477]: Service file '/usr/share//dbus-1/services/org.gnome.evolution.dataserver.AddressBook.service' is not named after the D-Bus name 'org.gnome.evolution.dataserver.AddressBook10'. Jan 23 11:00:17 xps13 dbus-broker-launch[8477]: Service file '/usr/share//dbus-1/services/org.gnome.evolution.dataserver.UserPrompter.service' is not named after the D-Bus name 'org.gnome.evolution.dataserver.UserPrompter0'. Jan 23 11:00:17 xps13 dbus-broker-launch[8477]: Service file '/usr/share//dbus-1/services/org.gnome.evolution.dataserver.Calendar.service' is not named after the D-Bus name 'org.gnome.evolution.dataserver.Calendar8'. Jan 23 11:00:17 xps13 dbus-broker-launch[8477]: Policy to allow eavesdropping in /usr/share/dbus-1/session.conf +31: Eavesdropping is deprecated and ignored Jan 23 11:00:17 xps13 dbus-broker-launch[8477]: Policy to allow eavesdropping in /usr/share/dbus-1/session.conf +33: Eavesdropping is deprecated and ignored Jan 23 11:00:17 xps13 systemd[7852]: Started D-Bus User Message Bus. Jan 23 11:00:17 xps13 dbus-broker-lau[8477]: Ready Jan 23 11:00:17 xps13 systemd-coredump[8431]: Process 8082 (gsd-power) of user 42 dumped core. Stack trace of thread 8082: #0 0x7f396b16983e __strcmp_avx2 (libc.so.6 + 0x15d83e) #1 0x7f396b2cf3dd g_str_equal (libglib-2.0.so.0 + 0x403dd) #2 0x7f396b26dca9 on_object_added (libgnome-desktop-3.so.19 + 0x29ca9) #3 0x7f396b3cb872 g_closure_invoke (libgobject-2.0.so.0 + 0x13872) #4 0x7f396b3df8e4 signal_emit_unlocked_R (libgobject-2.0.so.0 + 0x278e4) #5 0x7f396b3eaccd g_signal_emit_valist (libgobject-2.0.so.0 + 0x32ccd) #6 0x7f396b3ebbac g_signal_emit_by_name (libgobject-2.0.so.0 + 0x33bac) #7 0x7f396b540f9e add_interfaces (libgio-2.0.so.0 + 0x129f9e) #8 0x7f396b5413e4 on_control_proxy_g_signal (libgio-2.0.so.0 + 0x12a3e4) #9 0x7f396b3cb872 g_closure_invoke (libgobject-2.0.so.0 + 0x13872) #10 0x7f396b3df8e4 signal_emit_unlocked_R (libgobject-2.0.so.0 + 0x278e4) #11 0x7f396b3eaccd g_signal_emit_valist (libgobject-2.0.so.0 + 0x32ccd) #12 0x7f396b3eb103 g_signal_emit (libgobject-2.0.so.0 + 0x33103) #13 0x7f396b530c18 on_signal_received (libgio-2.0.so.0 + 0x119c18) #14 0x7f396b51f708 emit_signal_instance_in_idle_cb (libgio-2.0.so.0 + 0x108708) #15 0x7f396b2dceab g_idle_dispatch (libglib-2.0.so.0 + 0x4deab) #16 0x7f396b2e0b20 g_main_dispatch (libglib-2.0.so.0 + 0x51b20) #17 0x7f396b2e0eb0 g_main_context_iterate (libglib-2.0.so.0 + 0x51eb0) #18 0x7f396b2e11a3 g_main_loop_run (libglib-2.0.so.0 + 0x521a3) #19 0x7f396b9493bd gtk_main (libgtk-3.so.0 + 0x24f3bd) #20 0x5615d2ba2f90 main (gsd-power + 0x6f90) #21 0x7f396b033042 __libc_start_main (libc.so.6 + 0x27042) #22 0x5615d2ba309e _start (gsd-power + 0x709e) Stack trace of thread 8166:
gimp segfault
Can anyone report success to run gimp in Rawhide? I see its splash screen, a few messages about initialization, then a segfault. Full stack trace at: http://ryniker.org/Fedora/gimp_stack_trace GNU Image Manipulation Program version 2.10.14 git-describe: GIMP_2_10_12-511-ga4f55d6c7e C compiler: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/9/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 9.2.1 20190827 (Red Hat 9.2.1-1) (GCC) using babl version 0.1.72 (compiled against version 0.1.72) using GEGL version 0.4.18 (compiled against version 0.4.18) using GLib version 2.63.3 (compiled against version 2.63.0) using GdkPixbuf version 2.40.0 (compiled against version 2.40.0) using GTK+ version 2.24.32 (compiled against version 2.24.32) using Pango version 1.44.7 (compiled against version 1.44.7) using Fontconfig version 2.13.92 (compiled against version 2.13.92) using Cairo version 1.16.0 (compiled against version 1.16.0) ``` > fatal error: Segmentation fault Stack trace: ``` # Stack traces obtained from PID 6432 - Thread 6432 # [New LWP 6435] [New LWP 6436] [New LWP 6437] [New LWP 6438] [New LWP 6439] [New LWP 6440] [New LWP 6441] [New LWP 6442] [New LWP 6443] [New LWP 6444] [New LWP 6445] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". __libc_read (nbytes=256, buf=0x7ffef7a5b890, fd=14) at ../sysdeps/unix/sysv/linux/read.c:26 26return SYSCALL_CANCEL (read, fd, buf, nbytes); Id Target Id Frame * 1Thread 0x7f7629f8cdc0 (LWP 6432) "gimp-2.10" __libc_read (nbytes=256, buf=0x7ffef7a5b890, fd=14) at ../sysdeps/unix/sysv/linux/read.c:26 2Thread 0x7f761cd60700 (LWP 6435) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 3Thread 0x7f761c55f700 (LWP 6436) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/sysc ___ 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
Dell 7390 laptop.
For the first time, Fedora will boot on my Dell laptop: Fedora-Workstation-Live-x86_64-Rawhide-20200101.n.0.iso The kernel identifies the machine thus: DMI: Dell Inc. XPS 13 7390 2-in-1/06CDVY, BIOS 1.1.3 11/10/2019 and Dell identifies it with Service Tag 8NMBZY2. CPU info: vendor_id : GenuineIntel cpu family: 6 model : 126 model name: Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz stepping : 5 microcode : 0x46 I had to change the BIOS SATA configuration from RAID to ACPI in order to boot Fedora. This caused the delivered Windows system to fail, but it was successfully restored by Dell's recovery utility download. The built-in wifi device is recognized: iwlwifi :00:14.3: Detected Killer(R) Wi-Fi 6 AX1650i 160MHz Wireless Network Adapter (201NGW), REV=0x338 but is not operational. This is a bit peculiar.. The device uses an Intel AX201 chip, and Intel has good history with linux support. This log entry probably indicates the problem: kernel: iwlwifi :00:14.3: Direct firmware load for iwlwifi-Qu-b0-hr-b0-52.ucode failed with error -2 I stuck a small USB wireless adapter in the machine, and this works fine until support for the internal adapter is ready. The only other problem observed (it is still early) is the machine will not reboot or power down. Power off must be forced by pressing the power button for 10-15 seconds. The only clue I have about this was a message that says a watchdog timer will not stop, but this may be a symptom rather than a cause, or not related at all. Windows also has some problems on this machine, but that is not germane to this list. I observed no problems with Ubuntu - wifi worked perfectly, and no problems with power-off/reboot. I could not reboot from Windows to start Fedora Workstation Live using the EFI boot menu invoked by F12. The menu appeared with the USB flash drive listed, but clicking that item did nothing. Power off, then the EFI boot menu would boot the Fedora live USB device. ___ 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: Mystery empty file
>Are either of those using EFI with secure boot? According to the bug >report, that's the trigger. I believe you are right. To my surprise, after inspection of the BIOS displays in the machine that does allow data access, I find no mention at all of secure boot capability. The machine that does not allow access to /sys/kernel/debug/usb/devices supports secure boot, although I think it used to provide access to this data. Some configuration change to the secure boot facility is the likely explanation for this variation. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Mystery empty file
This seems to depend on kernel version. On one F30 system it works: [root@yoga ryniker]# uname -r 5.0.17-300.fc30.x86_64 [root@yoga ryniker]# ls -l /sys/kernel/debug/usb/devices -r--r--r--. 1 root root 0 May 30 09:59 /sys/kernel/debug/usb/devices [root@yoga ryniker]# cat /sys/kernel/debug/usb/devices T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 2 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev= 5.00 S: Manufacturer=Linux 5.0.17-300.fc30.x86_64 ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=:00:1d.0 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 8 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=8087 ProdID=8001 Rev= 0.03 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=256ms ... while on another, with the latest (non-test) kernel, it fails: [root@puget ryniker]# uname -r 5.1.6-300.fc30.x86_64 [root@puget ryniker]# ls -l /sys/kernel/debug/usb/devices -r--r--r--. 1 root root 0 Jun 6 08:11 /sys/kernel/debug/usb/devices [root@puget ryniker]# cat /sys/kernel/debug/usb/devices cat: /sys/kernel/debug/usb/devices: Operation not permitted ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Mystery empty file
I think you will find the file is not truly empty. /sys is not an actual file system, merely an interface to kernel information. There is no directory structure that records the length or other attributes of a file, as is the case for data on real media such as disks. If you read the /sys/kernel/debug/usb/devices file, you should find the data you seek. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: rawhide net install image doesn't work with bios partitions
Chris Murphy wrote on Mon, 27 May 2019 22:27:16 -0600: >Dual Fedora's isn't officially supported. The installer almost always >steps on the previous Fedora's bootloader making it unbootable, in >favor of a new bootloader for the new Fedora installation. This deserves some attention. I expect to be able to install Fedora in some disk space, and still be able to boot an older Fedora previously installed in other disk space. I would like the Fedora Installer to be aggressive when it builds its new boot configuration file, and copy as much as it can from old boot configuration data. Certainly it cannot understand everything, but I would prefer a menu item with some comment that Fedora does not know if this will work but has included it because it was found in the existing system, than to find my old configuration was simply discarded by a new Fedora installation. It may be the best solution is some dual strategy that has the Fedora Installer do what is "easy" (other simple Fedora systems, maybe Windows) and leaves harder cases (unknown systems, unusual configurations, storage volumes that are not accessible during installation) for some utility that can be executed after installation by a user who can quide it to make desired changes to the boot configuration. "Do no harm." applies here, because recovery of boot configuration data lost during Fedora installation requires knowledge and experience beyond what many users have. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: F26 doesn't wake up after updates
I have found some problems with resume from suspended state to be much improved after I switched to "GNOME on xorg". It is too soon to conclude they will not recur, but several days have passed without difficulty. F26 up-to-date on a Lenovo Yoga 3 11-inch laptop, model name 80J8. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
Re: New Blocker Criterion Proposal: Same default packages for all arches
>> In an extreme situation, a release could be nearly impossible due to >> dependency cycles. > >You'd need to provide specific examples for "extreme" as this has not >happened in recent Fedora history (at least back to F-21) I cannot cite an historical example. With more than a thousand packages in the Live edition, and several thousand in the Workstation edition, it seems severe to insist they must all (except hardware-specific) work in the primary architectures or a release is automatically blocked. That may be the right thing to do, and handle any situations that are too awkward on an exception basis. To concoct an extreme situation, suppose the Firefox developers decide that a newer version of GCC is necessary to build for the ARM architecture. I would argue the appropriate choice is to release Fedora without Firefox in the ARM builds, and include Firefox for ARM in a later release. I do not consider this a reason to remove a valuable Firefox from X86 builds. In a general sense, one might argue any time a program works on one architecture but fails on another, this must involve hardware enablement at some level. A compiler enables convenient use of a machine's architecture-specific instruction set and hardware features, therefore any application that uses this compiler is hardware-specific, and enables that hardware in some way. None of this reduces the value of a consistent Fedora experience across architectures. I believe this objective should influence choices about what to include in the default package set, and where to allocate development resources, but not forbid packages that deliver significant value. Most users are likely to quickly augment Fedora with their favorite applications and configuration, and thereby make their Fedora different from the default experience. It is still valuable to strive for consistency across architectures, but wrong to pretermit valuable applications only because they do not, or cannot, support some architecture. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
Re: New Blocker Criterion Proposal: Same default packages for all arches
I agree with you that Firefox is an important resource that Fedora should deliver, but think a criterion that failure to supply the same default package set for all (blocking) architectures will do more harm than good. Release criteria should focus on the quality of what is delivered in a release. They should not be a specification for its content, or a mechanism to allocate developer resources. The "critical path" concept already defines a set of resources considered essential to a usable Fedora release. A Web browser (in workstation builds) is an essential resource - Fedora could specify Firefox for this role, or accept any usable browser to meet this need, even different browsers on different architectures. The major problem with a heavy-handed "same default package set" criterion is the delay that might cause - especially if upstream resources are required. While Fedora waits for the last "default set" package to be fixed for some architecture, everything else in the frozen release ages. Sure, more recent package builds can accumulate in updates repositories, but then, when the release actually happens, users perform their first upgrade and wind up with a system too much different from what was actually tested for that release. In an extreme situation, a release could be nearly impossible due to dependency cycles. I think it better to agree the same default package set is desirable, but not essential, in a release. Judiciously add packages to the "critical path" set when a case is made that they are essential to Fedora. In other situations, argue for an exception to be made to block a release because, though perhaps not critical, some feature is so important to such a large group of users that it causes more damage to release without support on some architecture than to wait until it is fixed. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
Re: again F25 on USB Flash medium - with legacy ok - only problem with EFI -Anaconda
>install F25 Beta in legacy mode on an 64GB flash medium. And surprise it >works. I think this suggests there is some configuration or BIOS problem with EFI and USB in your machine. Both Chris Murphy and I performed successful EFI installations, he with Apple and I with Samsung hardware. It may be impossible to accurately gauge the prevalence of this problem with the limited hardware coverage available for pre-release tests. On the positive side, you have discovered a way to avoid the issue that may help other users who experience similar difficulty. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
Re: Installation validation test change proposal: merge USB tests into 'default boot and install', add more environment columns
>an optical specific Live Workstation spin Sounds like the proper category: will not block a regular Fedora release, will not consume test resources for primary Fedora deliverables, and will provide a focus for those with some stake in optical media. While lack of community to support an "optical spin" may not mean there are few who want it, it would mean there are insufficient people who will invest their talent to create it. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
Re: Fedora on usb connected media
Might this be a clue (from your anaconda log)? 13:10:26,938 INFO anaconda: Running post-installation scripts 13:10:26,938 INFO anaconda: Running kickstart %%post script(s) 13:10:29,210 ERR anaconda: Error code 1 running the kickstart script at line 33 13:10:29,210 INFO anaconda: All kickstart %%post script(s) have been run I checked my installation, and have no "Error code 1" message. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
Re: Fedora on usb connected media
Works for me. I used a Samsung 940X laptop and a Sandisk 80GB USB3 external SSD. This is a UEFI machine, and I installed using manual partitioning to re-use partitions on the external device, which contained an old Fedora 23 system. My purpose here was to preserve an encrypted /home partition. /boot, /boot/efi, /root and a swap partition were reformatted by the installer for the F25 system. In order to boot from the external drive, I must use the EFI boot loader - press F10 during start to display a list of boot devices, then select the SanDisk USB drive. The internal drive for this machine dual boots Fedora 24 and Windows. Only the external drive was used by Anaconda for the F25 installation. It might be possible to update GRUB on the internal drive so it can boot F25 from the external drive, but I rather like the present state where no change was made to the internal storage medium. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
25_Alpha-2 installation to VM: boot loader install failed
The target VM has two virtual IDE drives, sda (8 GB) for / and sdb (0.5GB) for /boot. Installation proceded normally until time to install the bootloader, which failed. Pop-up window said bootloader installation failed, and I chose to continue anyway in order to acquire as much log information as possible. From the anaconda log: 09:27:23,458 INFO anaconda: Installing boot loader 09:27:23,458 INFO anaconda: boot loader stage1 target device is sda 09:27:23,458 INFO anaconda: boot loader stage2 target device is sdb1 09:27:23,473 DEBUG anaconda: new default image: 09:27:23,619 WARN anaconda: /usr/lib64/python3.5/site-packages/pyanaconda/bootloader.py:839: PendingDeprecationWarning: use len(mi) instead setup_args = cfg_obj.dracutSetupArgs() 09:27:24,590 INFO anaconda: bootloader.py: mbr will be updated for grub2 09:27:39,185 INFO anaconda: bootloader.py: used boot args: rhgb quiet 09:27:42,393 ERR anaconda: bootloader.write failed: boot loader install failed 09:27:42,409 WARN anaconda: /usr/lib64/python3.5/site-packages/pyanaconda/ui/gui/__init__.py:929: PyGTKDeprecationWarning: The keyword(s) "message_format" have been deprecated in favor of "text" respectively. See: https://wiki.gnome.org/PyGObject/InitializerDeprecations message_format=message) 09:27:42,411 WARN anaconda: /usr/lib64/python3.5/site-packages/pyanaconda/ui/gui/__init__.py:929: PyGTKDeprecationWarning: The "flags" argument for dialog construction is deprecated. Please use initializer keywords: modal=True and/or destroy_with_parent=True. See: https://wiki.gnome.org/PyGObject/InitializerDeprecations message_format=message) 09:28:15,652 WARN anaconda: /usr/lib64/python3.5/site-packages/gi/overrides/GObject.py:541: Warning: gsignal.c:2635: instance '0x55bc6606e370' has no handler with id '54645' return func(*args, **kwargs) 09:28:15,652 WARN anaconda: /usr/lib64/python3.5/site-packages/gi/overrides/GObject.py:541: Warning: gsignal.c:2635: instance '0x55bc6606e370' has no handler with id '54646' return func(*args, **kwargs) 09:28:15,652 INFO anaconda: Installing boot loader -- DONE 09:28:15,653 INFO anaconda: Performing post-installation setup tasks 09:28:16,490 WARN anaconda: /usr/lib64/python3.5/site-packages/pyanaconda/packaging/__init__.py:662: PendingDeprecationWarning: use len(mi) instead self._setDefaultBootTarget() 09:28:16,492 INFO anaconda: Performing post-installation setup tasks -- DONE Files in the /boot filesystem (mounted at x) look normal... example: [root@puget ryniker]# ls -lR x x: total 88480 -rw---. 1 root root 3585929 Aug 19 10:44 System.map-4.8.0-0.rc2.git3.1.fc25.x86_64 -rw-r--r--. 1 root root 179364 Aug 19 10:44 config-4.8.0-0.rc2.git3.1.fc25.x86_64 drwx--. 4 root root 4096 Aug 24 22:28 efi -rw-r--r--. 1 root root 184380 Apr 5 05:38 elf-memtest86+-5.01 drwxr-xr-x. 2 root root 4096 Aug 24 22:20 extlinux drwxr-xr-x. 6 root root 4096 Sep 12 09:28 grub2 -rw---. 1 root root 54575425 Sep 12 09:27 initramfs-0-rescue-8c18cf8c0b2d481d99d1ec2aa45eb324.img -rw---. 1 root root 16920290 Sep 12 09:28 initramfs-4.8.0-0.rc2.git3.1.fc25.x86_64.img drwx--. 2 root root16384 Sep 12 09:23 lost+found -rw-r--r--. 1 root root 182704 Apr 5 05:38 memtest86+-5.01 -rwxr-xr-x. 1 root root 7466536 Sep 12 09:27 vmlinuz-0-rescue-8c18cf8c0b2d481d99d1ec2aa45eb324 -rwxr-xr-x. 1 root root 7466536 Aug 19 10:45 vmlinuz-4.8.0-0.rc2.git3.1.fc25.x86_64 x/efi: total 12 drwxr-xr-x. 4 root root 4096 Aug 24 22:21 EFI drwxr-xr-x. 3 root root 4096 Aug 24 22:28 System -rw-r--r--. 1 root root 34 Feb 4 2016 mach_kernel x/efi/EFI: total 8 drwxr-xr-x. 2 root root 4096 Aug 24 22:21 BOOT drwxr-xr-x. 4 root root 4096 Sep 12 09:27 fedora x/efi/EFI/BOOT: total 1332 -rw-r--r--. 1 root root 1293304 Feb 17 2015 BOOTX64.EFI -rw-r--r--. 1 root root 66104 Feb 17 2015 fallback.efi x/efi/EFI/fedora: total 5812 -rw-r--r--. 1 root root 102 Feb 17 2015 BOOT.CSV -rw-r--r--. 1 root root 1276224 Feb 17 2015 MokManager.efi drwxr-xr-x. 2 root root4096 Aug 24 22:27 fonts drwxr-xr-x. 2 root root4096 Aug 17 13:31 fw -rwxr-xr-x. 1 root root 70864 Aug 17 13:31 fwupx64.efi -rwxr-xr-x. 1 root root 998216 Jun 10 14:31 gcdx64.efi -rw-r--r--. 1 root root1024 Sep 12 09:28 grubenv -rwxr-xr-x. 1 root root 998216 Jun 10 14:31 grubx64.efi -rw-r--r--. 1 root root 1287032 Feb 17 2015 shim-fedora.efi -rw-r--r--. 1 root root 1293304 Feb 17 2015 shim.efi ... x/grub2: total 36 -rw-r--r--. 1 root root 124 Sep 12 09:27 device.map drwxr-xr-x. 2 root root 4096 Sep 12 09:27 fonts -rw-r--r--. 1 root root 4127 Sep 12 09:28 grub.cfg lrwxrwxrwx. 1 root root28 Jun 10 14:31 grubenv -> /boot/efi/EFI/fedora/grubenv drwxr-xr-x. 2 root root 12288 Sep 12 09:27 i386-pc drwxr-xr-x. 2 root root 4096 Sep 12 09:27 locale drwxr-xr-x. 3 root root 4096 May
Re: 'dnf system-upgrade reboot' doesn't do anything
I seem to have touched a sore spot on Mr. Murphy, and apologize if I have unintentionally irritated him. If he is the designer of the offline update mechanism, and I correctly perceive the implications of his explanation, then I do scold him for failure to mitigate the damage that might occur to a system in the situation reported by the original poster. The smaller problem is that there is no explanation why the offline upgrade is not performed after "dnf system-upgrade reboot". I expect a person with the authority to execute the dnf command knows how to examine the system journal to seek an explanation for why it did not happen. Mr. Miata presumably looked and could find nothing, which is why he created the original post. The larger problem is the offline update remains pending, indefinitely, until the old-style "run-level" number is removed from the "kernel parameters" (or whatever name you prefer to describe this hodgepodge collection of data.) This might happen days, even weeks, after the "dnf system-upgrade reboot" operation. Two bad things then happen: The boot operation, now executing the offline system update, takes a long time: typically one hour with a rotating drive, less with a solid state drive, longer if many extra packages are installed. If this is expected and planned, fine. If it is unexpected, an important service may go missing - an unplanned outage with expensive consequences for users. The offline update has a stale set of package files. These were downloaded days, weeks, perhaps even longer in the past. During this time, newer packages are installed in the system. After the delayed offline update completes, the new system has old packages, not current ones. Perhaps, despite Mr. Murphy's explanation about how offline update works, I misunderstand the process and the problems I describe above cannot occur. I should be pleased to learn this is so. If I am substantially correct, here are some suggestions for improvement. Implement a service to check for a pending offline update and add it to the dependencies for the multi-user and graphical targets. At the least, this service will emit a message to say there is a pending offline update that was not executed. Even better, in my opinion, would be to remove the symlink that triggers an offline update and emit a message that says the pending offline update has been canceled and can be rescheduled with "dnf system-upgrade reboot" Document the interaction between offline update and old style run level numbers. Resources such as https://fedoraproject.org/wiki/DNF_system_upgrade should provide enough information about this operation to avoid the need to tell a user "You're unhappy that you have to know what the fuck you're doing to get it to do what you want it to do." -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: 'dnf system-upgrade reboot' doesn't do anything
I am unhappy with the suggestion that the semantics of kernel parameters may depend on some notion about how "temporary" they are. If a kernel parameter is specified, it is present; if not specified, it is absent. It is proper to design parameter syntax and default values to favor common usage. There also have to be mechanisms to handle different specifications for the same parameter (first or last wins...) and use of incompatible parameters (pick one, ignore both... but always log the choice!) In this case, "dnf system-upgrade reboot" is an explicit command to perform an offline system update. That is what should happen, regardless of the (default) target. Any target specification should apply after the offline update. Are you concerned about the possibility "dnf system-upgrade reboot" was ordered, then immediately decided it was wrong? How many times do you want to ask "Do you really mean this?" Why should specification of boot target 3 as a kernel parameter pretermit the offline update - but possibly leave it waiting to occur unexpectedly during a subsequent boot? Your explanation of how systemd implements offline update using a symlink offers an escape: boot from a different root file system (a live image, if necessary) and remove the offline update symlink. If you think that is too esoteric or awkward, implement a new kernel parameter such as "cancel-offline-update" that does this. What is the relation between run level 1 and offline update? Does run level 1 stop the init process before offline update? If yes, then that is an easy escape: boot to run level 1, remove the offline update symlink, then "systemctl default". -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: fedora-bookmarks prevents installation of curent updates in F24
The following worked for me: dnf erase astronomy-bookmarks (This also erased firefox.) dnf upgrade dnf install firefox (This also installed astronomy-bookmarks) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: criterion proposal: upgrading across 2 releases
>A month is a pretty long time in Fedora development True, but a month is only available if the problem is reported on day 1. If it takes a week or two for a user to report a problem, that interval lessens the remaining time to EOL. On the other hand, there is no prohibition against a fix after EOL. We also do not know there will be serious problems. We know it is impossible to test more than a miniscule fraction of possible upgrade cases. That does not mean there will be lots of bugs, it means we have little confidence the test plan has found most bugs. We might say there is no reason to believe experience with the current release will be any worse than the last. As far as I know, this is the first time "dnf system-upgrade" has been generally available for a release-skip upgrade. It is way too early to have any historical perspective. -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: criterion proposal: upgrading across 2 releases
>It's not like dnf-system-upgrade would magically stop working when N-2 >reaches EOL, so honestly, overall, I just don't really see the problem >you're describing Like most of Fedora, dnf-system-upgrade gets limited testing before release. When N is released, a large number of users who did not install N-1 will think it is time to upgrade before their current N-2 reaches End-of-Life in four weeks. These users will try system-upgrade from a much larger set of initial states than could be tested before release. This is the time the greatest number of (N-2 to N) problems will be found. It is also the time when problems in the brand-new release N are most likely, as users of N-1 eagerly try N. With an abundance of bug reports in the just-released N, and some new reports of problems with N-2 that will be closed by EOL in a handful of days, where do you think maintenance should focus? I admit this view is based on what is probable, not on actual fact. My point is not do this or avoid that, I want the Fedora user to have an accurate understanding of upgrade choices. My reading of the EOL policy says "If it isn't fixed before EOL, it is unlikely to be fixed." If I encounter a problem with release-skipping system-upgrade, too bad. There is probably no time to fix it before EOL. In effect, release-skipping system-upgrade is not supported. Either I upgrade every release (when system-upgrade is supported and bug fixes are likely), I plan to do a new install, or I hope to be lucky with EOL code. That is not a bad set of choices. Bad is a user in trouble because he reasonably thought they were different. "Release-skipping system-upgrade is a release-blocking requirement" sounds likely to obscure the support risks that attend its use. Fedora is certainly better for a robust system-upgrade facility. No point is filing bugs now for my 21-23 failure, though. 21 is EOL, and the failure did not occur with 22. -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: criterion proposal: upgrading across 2 releases
System-upgrade across two releases raises an interesting End-of-Life policy issue. If system-upgrade from N-2 to N is so important it will block release of N until it works, how do we explain why it is no longer important after four weeks when N-2 reaches End of Life? Four weeks is little time to allow users who chose not to upgrade to N-1 to move from N-2 to N. Do we say "After four weeks, the only supported mechanismm is new installation of N"? That is clear and simple, consistent with the EOL schedule, but denies system-upgrade is such a critical facility. Should system-upgrade be formally supported for three releases (18 months?) That would tell users they may count on it for their upgrade plan, but it is a significant change that could involve FESCo. -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: criterion proposal: upgrading across 2 releases
On Tue, 24 Nov 2015 10:46:55 -0800, Adam Williamson wrote:
> We have never really gone to any lengths to test or support N-1 upgrades
> with 3rd party repositories or non-repo software either. That's a
> different question.
>From a user's perspective, the value of system-upgrade depends on its
ability to move his system "as configured" to a new release. All of his
personalization, including any non-fedora software, remains in place.
You are certainly right to except non-Fedora software from QA tests. The
problem I perceive is the vast number of possible combinations of
packages from just the Fedora repositories. There may be no need to test
exhaustively, but any heuristic is likely to miss problems from time to
time. It is likely only enough cases can be tested to distinguish "some
system-upgrades work" from "system-upgrade is often impossible."
This is valuable to know, and I have no quibble with a QA criterion that
says "system-upgrade is never possible" will block a release. I suspect
there is no precise, useful definition that will tell a user whether his
particular system will succeed with system-upgrade. All he can do is try
and hope for the best. There might be documentation that says "these
circumstances are likely to prevent successful system-upgrade" - the
"common bugs" approach.
With any general claim "You can use system-upgrade to advance to the next
(or next+1) release" there will be triage issues (how many users will
experience problem 1; how many will encounter problem 2?) How many
susceptible users must we estimate in order to block a release? I fear
software developers will rightly claim they are busy with new features or
current bugs and they cannot spend time to investigate compatibility
problems from system-upgrade that simply do not appear when their sofware
is newly installed.
I do not want a Fedora user to understand "You can use system-upgrade to
migrate to a newer release" has the same confidence as "The new Fedora
meets all release criteria."
> Why does the situation inevitably 'get worse' for N-2 upgrade?
There are more possible initial conditions. Even a very sparse test plan
requires more effort. Analysis of "How important is this case?" may be
more difficult, and there are more cases. Instead of problems from six
months of software evolution, there will be problems from 12 months, and
the increase in number of problems over time is likely greater than
linear.
I certainly do not want to abandon system-upgrade. I want users to
understand we cannot test it well, probably cannot fix many failures,
and, when it fails, we reccommend they report the problem then undertake
a new installation of Fedora, configure it, and reload applications to
meet their requirements.
"System-upgrade must work before release" is too vague ("work" is too
difficult to define and test), too severe (important new function could
be delayed for reasons no one is willing to fix), and will tell users who
experience problems that Fedora is lower in quality than they hoped.
If users are told up front that system-upgrade is useful but cannot be
tested or guaranteed for all cases, their expectations will be more
realistic, therefore satisfaction with Fedora will be greater.
"dnf system-upgrade" is rather new. Maybe the Fedora organization should
observe user experience for another release or two before it decides this
is a critical, and therefore release-blocking, part of Fedora. I
understand enthusiasm for the new, offline upgrade mechanism. More
history will yield a better understanding of what problems can occur, and
what costs must be borne to fix them.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: criterion proposal: upgrading across 2 releases
On Tue, 24 Nov 2015 07:52:47 -0500, Stephen Gallagher wrote: > I've upgraded several family members directly from Fedora 21 to Fedora 23 > in the last week with no issues whatsoever (of course, I also curate > their repository selection, so they don't end up with incompatible > packages). Aye, there's the rub. It is not just update from an "original" installation of N-2 to N, it is update from N-2 plus whatever additional repository packages were installed plus additional non-repository software and user configuration that you want to upgrade. The starting condition is quite variable, and may include old versions of applications because these are familiar to the user or incompatible with more up-to-date software. When system-upgrade fails (if you are lucky, this will be obvious; if unlucky, it may not be recognized until after the event), the only way back to the starting condition is a full system restore. Many users will back up their own data, and, if upgrade ends badly, plan to recover with a new installation (of N, N-1, or N-2) and necessary software, followed by restoration of their personal data. This is the most reliable upgrade strategy: no exposure to problems with old stuff, and it defines how to get from a well-known initial state to the user's working environment. In this case it may be impossible to fix an upgrade problem, because there is no way to reconstruct the original state and verify successful upgrade is possible. Of course, these considerations also apply to the single-release upgrade. The situation just gets worse the farther back one goes. And sometimes there simply is no upgrade path: the new software is just incompatible with the old. To use the new system, you must adapt to it. (Remember the agony voiced by some GNOME2 users when GNOME3 came along?) Unlike new installation with its well-defined result, system-upgrade (with dependencies on user configuration and possibly incompatible pieces of software) necessarily has some vague result. It is undeniably valuable and extremely convenient, but unavoidably a second-class facility. We may insist system-upgrade of a newly installed N-1 to N works, and further insist system-upgrade of a newly installed N-2 to N works, but this is deceptive. Once a user configures and uses his system, system-upgrade is unpredictable. To add my own to Mr. Gallagher's anecdote, my single attempt at "dnf system-upgrade" from 21 to 23 failed. After upgrade, my userid was not displayed on the login screen. Login in text mode was possible. After an hour or two tinkering with gdm configuration, I gave up, did a new install of 23, and configured it without difficulty. Several times I have used "dnf system-upgrade" from 22 to 23 without problems. Conclusion: release-skipping upgrade is more difficult than single-release upgrade (and probably not worth the effort to fix.) If anyone would like to investigate the problem I experienced, I am willing to install a new 21 system and see if I can reproduce the error. -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: criterion proposal: upgrading across 2 releases
I believe a failure to upgrade from N-2 to N should not block the N release. The reason is limited resources, both for tests and for changes to fix problems. These resources are more valuable applied to the N release than to something two releases in the past. If someone wants to test a release-skipping upgrade, fine. Report problems? Sure. If someone wants to fix these problems, OK; if not, the policy should be "Upgrade one release at a time. Release-skipping upgrades may work, but are not guaranteed." If "upgrade N-2 -> N-1" works, and "upgrade N-1 -> N" works, then "upgrade N-2 -> N" also works, right? Maybe not, and I think it profligate to insist we fix a broken two-release upgrade when two single-release upgrades successfully reach the desired target. Document, do not block. I may hold a minority opinion, but this seems like another call for QA to do somebody else's job. Who should decide that release-skip upgrade is a Fedora imperative? -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: Grub Error in F23 Release? Grub stops in OS selection for Windows for ever.
When you change from the GRUB default boot item, the timer stops and no default boot occurs. You must use a key to tell GRUB to boot the current selection. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: comment to F23 Final RC10 - still card reader problem
I think you may be the victim of GNOME's "Do what you maybe probably want." attitude. This is something you might be able to configure to your taste, given sufficient knowledge about what specifications to change. I have a Lenovo machine with a Realtec card reader: [ryniker@lenovo ~]$ lspci | grep Card 02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5209 PCI Express Card Reader (rev 01) This is known as /dev/mmcblk0, and when I insert a SD card with file systems on a couple of partitions: [root@lenovo ryniker]# blkid | grep mmc /dev/mmcblk0: PTUUID="ba2edfb9" PTTYPE="dos" /dev/mmcblk0p1: SEC_TYPE="msdos" LABEL="boot" UUID="74BD-74CF" TYPE="vfat" PARTUUID="ba2edfb9-01" /dev/mmcblk0p2: UUID="ec2aa3d2-eee7-454e-8260-d145df5ddcba" TYPE="ext4" PARTUUID="ba2edfb9-02" GNOME kindly mounts these under /run/media: [ryniker@lenovo ~]$ mount | grep mmc /dev/mmcblk0p1 on /run/media/ryniker/boot type vfat (rw,nosuid,nodev,relatime,uid=501,gid=501,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2) /dev/mmcblk0p2 on /run/media/ryniker/ec2aa3d2-eee7-454e-8260-d145df5ddcba type ext4 (rw,nosuid,nodev,relatime,seclabel,data=ordered,uhelper=udisks2) which I find sometimes helpful, sometimes not. In any case, these are "user" mounts. I have not explored what happens when multiple users are logged in when a card is loaded. If I do not want these file systems mounted, I can: [ryniker@lenovo ~]$ umount /dev/mmcblk0p1 [ryniker@lenovo ~]$ umount /dev/mmcblk0p2 and then remove the SD card when umount completes (this may take a while if a lot of data must be flushed to the media). Often, I want to write a new image onto a SD card (dd of=/dev/mmcblk0). If I do not first umount these automatically-mounted file systems, dd output is buffered in memory - dd may report a transfer rate of one gigabyte per second - and I am exceedingly careful to wait until I observe activity to the SD card has ended before I remove it (without any umount operations, which I fear may corrupt the image I just wrote.) The automatic behavior may be right for most users. I have enough experience to (usually) avoid the pits, and recognize what has gone wrong when I stumble into one. This Lenovo machine also has a reboot problem similar to one you reported. Windows reboots successfully, but Fedora does not. Fedora shuts down, I see the Lenovo splash screen, but no boot. I must force power off, then wait through a ten-second "Power Saving" countdown displayed on-screen before actual power off, then I can boot successfully. Peculiarity of the Lenovo hardware, I suppose, and I just live with it. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Weird effect of mount command in F23
>> I do not like to sacrifice well-defined, predictable behavior for >> convenience > >Convenience is what users need! > >> but others may argue this default behavior serves the >> greater good. > >What is the *greater good*? I think the perceived "good" is that users can load a disk and have a useful default action occur automatically. A music CD causes a media player such as rhythmbox to start, media with camera images starts shotwell, a disk with a mountable filesystem induces a mount operation over /run/media/... and so on. The casual or inexperienced user does not need to know the name "rhythmbox" or understand the mount command (and have the necessary privilege to execute it). This automatic activity can make different environments similar, and therefore easier for users. For example, KDE might launch amarok instead of rhythmbox (used by GNOME) for a music CD. From the user perspective, load a CD and the application to play it is automatically started; doesn't matter whether he uses GNOME, KDE, mate, cinnamon, whatever. For many users, this may be the most convenient behavior. For you and me, not. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Weird effect of mount command in F23
I suspect you suffer from software that wants to help you and "Do the right thing." If you try to mount a device with no media, mount might simply fail (no media present). Instead, at least for optical drives, it presumes the desired media might be available in the tray and requests the device to load media, then tries again to mount a file system from this device. When the drive status changes from empty to loaded, a udev event occurs that can trigger another piece of software that wants to "Do the right thing." I suspect your initial problem results from conflict between these two programs. The original mount request fails, whatever operation started by udev completes, and when you issue a second mount request (for the now-loaded optical drive) there is no udev event to get in the way and the mount succeeds. I do not like to sacrifice well-defined, predictable behavior for convenience, but others may argue this default behavior serves the greater good. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
"Auto Freeze Exeception" seems too complicated an answer to this question. Either continue to call new background a blocker, or decide it is desirable but not a blocking issue. If lovely new art is not available, some generic "Fnn" background could be used then replaced by an update after release, in order to avoid delay. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Testing request: gdm-on-Wayland on hybrid graphics laptops (esp. Macbooks)
Fedora-Live-Workstation-x86_64-22-TC3.iso installed without problems using an external USB drive on my Macbook Pro with 15-inch Retina Display. I logged on using GNOME with Wayland for the user created during installation - no problem. That said, the system appears fragile, and network configuration looks like it will be a challenge. Some of that may be peculiar Apple hardware; even the wired Ethernet has issues. Still, this is much better than my last attempt with an early F22 Beta, which would not boot after installation. POR was required after USB wi-fi and wired Ethernet (through Lightning connection dongle) plug events, which I suppose might be related to unsupported Apple hardware issues. nm-connection-editor fails to save connection data with complaints like these: [root@localhost rynx]# nm-connection-editor (nm-connection-editor:2395): GLib-GObject-WARNING **: The property GtkButton:use-stock is deprecated and shouldn't be used anymore. It will be removed in a future version. (nm-connection-editor:2395): GLib-GObject-WARNING **: The property GtkSettings:gtk-button-images is deprecated and shouldn't be used anymore. It will be removed in a future version. (nm-connection-editor:2395): GLib-GObject-WARNING **: The property GtkTreeView:rules-hint is deprecated and shouldn't be used anymore. It will be removed in a future version. Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged. (nm-connection-editor:2395): GLib-GObject-WARNING **: The property GtkMisc:yalign is deprecated and shouldn't be used anymore. It will be removed in a future version. (nm-connection-editor:2395): GLib-GObject-WARNING **: The property GtkImage:stock is deprecated and shouldn't be used anymore. It will be removed in a future version. (nm-connection-editor:2395): GLib-GObject-WARNING **: The property GtkButton:xalign is deprecated and shouldn't be used anymore. It will be removed in a future version. (nm-connection-editor:2395): GLib-GObject-WARNING **: The property GtkWidget:margin-left is deprecated and shouldn't be used anymore. It will be removed in a future version. (nm-connection-editor:2395): GLib-GObject-WARNING **: The property GtkAlignment:left-padding is deprecated and shouldn't be used anymore. It will be removed in a future version. Error creating proxy: The connection is closed (g-io-error-quark, 18) Error creating proxy: The connection is closed (g-io-error-quark, 18) Error creating proxy: The connection is closed (g-io-error-quark, 18) Error creating proxy: The connection is closed (g-io-error-quark, 18) Error creating proxy: The connection is closed (g-io-error-quark, 18) ** (nm-connection-editor:2395): WARNING **: Invalid setting Wi-Fi: 802-11-wireless.ssid: property is missing ** (nm-connection-editor:2395): WARNING **: Invalid setting Wi-Fi: 802-11-wireless.ssid: property is missing ** (nm-connection-editor:2395): WARNING **: Invalid setting Wi-Fi: 802-11-wireless.ssid: property is missing ** (nm-connection-editor:2395): WARNING **: Invalid setting Wi-Fi: 802-11-wireless.ssid: property is missing ** (nm-connection-editor:2395): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:2395): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:2395): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security (nm-connection-editor:2395): dconf-WARNING **: failed to commit changes to dconf: The connection is closed (nm-connection-editor:2395): dconf-WARNING **: failed to commit changes to dconf: The connection is closed ** (nm-connection-editor:2395): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:2395): WARNING **: Invalid setting Wi-Fi: 802-11-wireless.ssid: property is missing ** (nm-connection-editor:2395): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:2395): WARNING **: Invalid setting Wi-Fi: 802-11-wireless.ssid: property is missing ** (nm-connection-editor:2395): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:2395): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security (nm-connection-editor:2395): dconf-WARNING **: failed to commit changes to dconf: The connection is closed (nm-connection-editor:2395): dconf-WARNING **: failed to commit changes to dconf: The connection is closed [root@localhost rynx]# nm-connection-editor (nm-connection-editor:2428): GLib-GObject-WARNING **: The property GtkButton:use-stock is deprecated and shouldn't be used anymore. It will be removed in a future version. (nm-connection-editor:2428): GLib-GObject-WARNING **: The property GtkSettings:gtk-button-images is deprecated and shouldn't be used anymore. It will be removed in a future version. (nm-connection-editor:2428): GLib-GObject-WARNING **: The property GtkTreeView:rules-hint is deprecated and
Re: F22 MacBook Pro woe
F10 works just fine to boot an edited item. Thank you, Adam. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F22 MacBook Pro woe
I was pleased to see Fedora-Live-Workstation-x86_64-22_Beta-2 boot on my Apple MacBook Pro 15" with retina display. "Install to disk" completed after some fragility relating to my USB flash drive installation target. Wrote zeros to the first MByte of the flash drive, then Fedora would partition, format, and install. Boot from the new flash drive, and see the expected GRUB menu... except it says "Useandto select..., e to edit, Ctrl-x to boot." No up and down arrows, but the up and down cursor keys work fine to move to different menu lines. More of a problem is that Ctrl-x does not boot an edited item; it just inserts an "x" at the cursor. Boot of the new Fedora system fails with some message about unable to allocate a USB device (the one that contains Fedora, I expect). I discovered the GRUB edit problem when I tried to remove "quiet" and "rhgb" in an attempt to learn more about the USB problem. Obviously, the GRUB menu came from the Fedora drive, and the graphical boot screen gradually filled the droplet icon with white until it was filled, or very nearly so. Alt-d switched to a console where I saw the USB message, and boot entered an emergency shell. I'll tinker with the GRUB files and try to learn more, though I wonder if this is merely some Apple strangeness and there is no Fedora claim to work on this platform. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to install Gnome Desktop on F21 Server ?
Try: yum grouplist hidden ids -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: why are so much gdm processes are running?
It is interesting to note a difference from F21, where the login processes are "true" daemons in the sense they have no controlling terminal. Now, for example, joachim.bac...@rhrk.uni-kl.de reports: ps -u gdm PID TTY TIME CMD 1243 ?00:00:00 systemd 1244 ?00:00:00 (sd-pam) 1246 tty1 00:00:00 gdm-wayland-ses 1248 tty1 00:00:00 dbus-daemon 1249 tty1 00:00:00 gnome-session 1319 tty1 00:00:02 gnome-shell ... Does this make possible new security issues? I do not claim it does, but do not know enough to assert it does not. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 22 Workstation Beta Release Candidate 1
Works OK on my Macbook Pro: i7-4850HQ processor with Intel Iris Pro Graphics 5200 plus Nvidia GT-750M graphics processor. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Heads up - Anaconda 22.17 will enforce 'good' passwords
>we also have no data about the prevalence of weak passwords or attacks >on default-configured Fedora systems On my firewall system, /var/log/secure is larger than 300 megabytes (less than one month of data), most of it reports of failed login attempts to root. I am very careful about passwords on this machine. Some of the security companies operate "honeypot" machines, and may have interesting numbers about ssh attacks. Red Hat probably also has data about unwelcome attempts to access its systems. Like some other security issues, it is as much about psychology as it is about code. However elegant the software technology may be, its value is small if users pretermit its use. Aside from the usual problems with strong passwords, the problem I see is that the user who changes the root password does not think about ssh attacks. If some ssh configuration change is needed to permit root login, at least we have some reason to believe the risk has been evaluated. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Heads up - Anaconda 22.17 will enforce 'good' passwords
Recapitiulation: A security problem was recognized because the ssh daemon is enabled by default on Fedora systems: with a weak root password, a remote attacker might easily obtain unlimited access. The direct solution would seem to be a change to the ssh daemon to prohibit root login in its default configuration, but allow post-installation change to sshd to permit this where it is desirable. An indirect solution was implemented to require a strong root password during Fedora installation. This avoids the default vulnerability, but upset people (especially testers who frequently install Fedora) that consider it makes additional work necessary to configure a system the way they want it. Ultimately, this indirect solution is weak. Users are likely to supply an acceptable root password during installation, then change it to what they desire after installation. This could re-open the vulnerability, which was not understood by a casual user. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Heads up - Anaconda 22.17 will enforce 'good' passwords
>Super simple passwords will no longer be allowed... increased security is >worth it. No, you just made installation more bothersome - the user will then have to set the passwords he wants after installation is complete. It is good to warn about a weak password, but I feel I know better than you the environment in which the machine I install will run. What you think is good I might feel is inadequate, or what you think is poor might be just fine for my purpose. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: i845G - X locks up machine
Might this be an effect caused by removal of an old graphics driver? https://lists.fedoraproject.org/pipermail/devel/2014-May/199459.html -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] naming schemes
>a naming scheme that doesn't suck. Please consider it desirable to implement a scheme with file names that, in lexical order, list oldest version first (or last). Newest version somewhere in the middle is a bad design. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposed generic release criterion: service manipulation
> It must be possible to start, stop, enable and disable system > services using the initialization framework's standard commands. This sounds like any service that fails (will not start, will not stop...) will block a release. Should there be a distinction between "critical" services that must work or block release, and lesser services that may fail and not block release? For example, journald might be deemed critical, while sheepdog is not. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Leaving the project
Thank you for years of work to improve Fedora. All Fedora users benefit to some extent from your efforts. >as WG's slowy turn into tiny little empires fighting amongst themselves >for components directions and maintenance... Fedora (and linux in general) is growing larger. As this happens, management issues require more attention relative to technical issues. Many (including you and me, I think) find management personally less rewarding than technical effort. Fedora has started to address some exciting and challenging issues. You are certainly correct when you forecast difficult times ahead. In the short term, it is hard to imagine no decrease in quality. It will take time to learn how to manage this vision. I think this is valuable to do, but understand your desire to work where you feel your efforts will be most productive. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: swap partition problems - Re: [Bug 1006304] BootLoaderError: failed to set new efi boot target
> And no manpage for blkid. There is a man page for blkid. It is part of: util-linux-2.24-2.fc20.x86_64 If the man page is missing, perhaps other missing pieces contribute to the problem. For example, swapon is also in util-linux. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: xserver fails to resume from suspend (f20)
>So strange as it may seem - it appears that it has to be shut for more than a >short time to fail. Might it be a hibernation issue? After some period of time, perhaps your machine wants to move from suspend to hibernate. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
Kamil Paral wrote on Fri, 20 Dec 2013 05:00:24 -0500 >The bandwidth problem should be solved by a simple program: >a. you run it on computer A (lacking bandwidth) - it gathers the list of >installed packages and exports a file >b. then you run it on computer B (good bandwidth) - feed it the file and tell >what programs you want to download, it fetches all the RPMs and makes a >repository >c. then you bring the files back to computer A, and either using that >file again or GNOME Software it mounts the repository and allows you to >install the programs available Simple program, yes, but operationally complicated. Hope you get all the programs you want the first time, else repeat until you get it right. Were I to perform Fedora installations without Internet connectivity, I should be tempted instead to copy the entire Fedora repositories to a portable disk. That way, anything I did not know I wanted would be right at hand. Job done in one visit. Other people could use my disk to install whatever package sets they wanted. With a world of use cases, no scheme will be best for everyone. I like your idea of a live system with optional repository, but where is Anaconda in this picture? Must everyone who wants a configuration not possible with live install use netinstall? Will F21 be the first Fedora release with three versions (workstation, server, cloud)? Will each project make independent decisions about distribution strategy? >Since there's nothing else than a yum repo, it's trivial to check for >correctness. I beg to differ. Instead of a "frozen" image, with direct management to limit changes, you suggest a plethora of collections that are likely to span a larger part of Fedora's total package set. If you mean to prepare specialized repositories only from packages in the DVD collection, there is no advantage: just keep the DVD. I feel there are many chapters yet to be written in the story of Fedora's distribution mechanism. Partition of the problem may be appropriate. Instead of a search for a globl distribution scheme, direct each project and spin to make choices appropriate for their target audience. The cloud project will see network installation the only thing they want, while SoaS delivers a complete system image with no need for a network. Interesting times ahead. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
>With five Test Managers, become a Test Executive... Sorry, Adam, just an attempt to give you opportunity to smile. I am serious about the scalability issue, however. As you indicated, the typical FOSS activity does not map readily into a classic business hierarchical organization chart. I do not want that. It would likely be difficult, unproductive, and even incite antagonism. This does not mean all strategies will fail. I do not know any sure-fire way to multiply the effectiveness of QA, but your efforts to document what QA can do and what others might do seem headed in a useful direction. Test automation is useful, especially if developers can be engaged in its creation. Abrt and other infrastructure is productive, and can be improved. Documentation - how to test, how to collect and report information about errors - is useful, especially when new testers are sought. Bugzilla is not all that easy or intuitive to use. Some sort of coverage map might help: what pieces are people currently testing or planning to test; what parts have no people active. All depends on cost/benefit estimation. Direct implementation is costly; leverage from work done by others may be key. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On Sat, 14 Dec 2013, at 11:25:40 -0800 Adam Williamson wrote: One thing they've floated as an idea is to have a separate 'installation environment' you could boot into from the live images - so you could either boot into 'try it out' live mode, or 'install it' installer mode, but not run the installer from within the live mode. That is pretty much what I had in mind. There would be no "live installer". The Fedora stand-alone installation medium would be large enough to have a live system that offered "try" mode, "install" mode (full anaconda, with local repository), and maybe "rescue" mode. The same system image would be used: options built into each choice would direct which mode to execute. I think Ubuntu (or one of its variants) uses a scheme like this, but I do not know if it copies the live image or offers multiple installation variations. It is very crude, but I looked at how many models of USB flash drive Amazon sells directly and see: 512MB & Under 4 1GB39 2GB 176 4GB 378 8GB 518 16GBB 407 32GB & Up 465 Two thirds are models with 8GB or larger capacity. That does not mean this many flash drives sold have that capacity, but such capacity is readily available. There still are many machines that do not boot directly from USB, but that is a condition for which GRUB and friends are made. I cannot quantify how much a single installer for Fedora saves over two (live and multiple-environment). If one installer is adequate, it still may not be worth the disruption caused when the other is dropped. The single installer choice could be made either way. The alternative is only a live installer, which becomes the starting point for subsequent installation by yum of the desired environment(s). if you're interested in making [a limited resource Fedora] happen... I think one of my problems is too much hardware, not too little. Somehow, I seem to have acquired the notion a new release of Fedora justifies a new machine on which to run it. I don't really see a lot of evidence that many other groups test their stuff at all in any particularly organized way There are many reasons this is so. One may be a perception there is a QA group that will do this, therefore little need exists to do first what will be done again. This is not the most important factor, I believe, but a consequence is the more QA does, the more this attitude grows. You become a victim of your own success. Greater clarity about what QA will not test may help. I'll note two design choices in storage which make this problem exponentially harder... Yes. Test the untestable. I do not think those choices are caprice; they allow users, most of whom are no more than casually familiar with Fedora installation, to find a more comfortable path through the installation process, one that permits minimal rework (avoids the "Something is wrong - start over" event) as understanding grows and bad choices are improved. Fedora testers, who usually have an abundance of installation experience, likely do not appreciate the value to less experienced users of this flexibility that makes tests so difficult. for upgrading, we only test upgrading a very clean installation of the previous release Upgrade is a can of worms. Yes, I too am beguiled by how much easier upgrade is than a new installation, and have often chosen upgrade, but something (many somethings!) sooner or later bite. There are just too many initial conditions, and too many distinct ways appropriate for different users to handle these conditions, to make possible an accurate understanding of what results from an upgrade. In lucid moments, I know upgrade should be exorcised, but it just is *so* convenient. Has Fedora QA discussed how much effort they should or can invest in organization and facilitation of others' test activities? Direct testing scales (approximately) linearly with number of people, but education, organization, and leadership has the potential to scale at greater multiples. |---| | Great opportunity! Become a Fedora test franchisee. We'll provide | | directions, training, and all the materials you need, so you too can | | participate in this fast-moving field. Gain experience, recruit | | others, become a Test Manager and train new Testers. With 10 or | | more Testers, select your own Test Managers (each of whom will direct | | at least five Testers) and advance to the Test Director level. With | | five Test Managers, become a Test Executive...| |---| -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
The defining characteristic of the Live images is that they run without installation on a user's disks. Beyond that, they have the capability to install a minimal Fedora system to a local disk. Once the size limit for a live image is increased beyond the capacity of a CD (or other common media), there seems no reason to limit the live image size to 1 GB, or any arbitrary value. Rather than struggle to find what can be be discarded from a live image in order to achieve a particular size, why not build the DVD product as a live system, or expand the existing live recipe to include more of the frequently used packages and not build the DVD? The DVD installer program has much more flexibility, but this is due to that arbitrary size limit, I expect: there just is not space for the full Fedora installation program (plus local repository) in today's live images. Others have stated the need for something like the DVD collection of packages. Without this, those who need something like it will have to build their own, obtain it from a third party, or look at another distribution. For this reason, to simplify the Fedora products to (1) network installation and (2) stand-alone installation, I submit the installation DVD could be built as a live image. I do not like the thought that many users might decide they have to copy an entire Fedora repository to a portable hard drive in order to install the Fedora system they want on a machine without a good Internet connection. A sizable group of users may have very limited hardware resources - no network, only a CD drive. This group would be a reasonable target for a "Limited Resources" spin that seeks to tailor Fedora to such an environment. For example, these systems may have too little memory to support anaconda (and many of the applications in Fedora's default configuration). Maybe a new SIG for this target. (Perhaps it already exists and I, with richer hardware resources, never looked for it.) In any case, Adam Williamson's articulate comment about the practical limits to what Quality Assurance can achieve with a six month release cycle and the available resources is very relevant. The release criteria, in part, seek to define what will be tested, but they read more like a prescription for what "should" be tested. Modifications to limit and make more specific the actual test coverage can help Fedora users better understand what they have, and reflect the reality of QA resource limits. To this end, it would be good to have better distinction between what QA tests and what other groups - SIG, upstream, packager, spin creator, architecture group, etc. - are responsible to test. QA test criteria is one place to document this, at least the QA view of it. Adam, your recent work on storage tests reads like a Unit Test Plan for anaconda: something that tries to exercise all the code paths of the program. Is this the proper function of Fedora QA? If it is, what is the proper fraction of the anaconda development budget to be allocated to Fedora QA for this purpose? I use this as an example to support your observation that QA clearly does not have resources to test all it might want to test, and clearer definition is required for what QA will test and what others have to test. Your storage test cases look like something anaconda developers should run before they let a new version loose. Throw away a package because it was not tested, failed a test, or missed a deadline is not a solution, however vexed one might be about what has not been done. It is natural that many changes will occur in Fedora's package roster. I counted 39,500 rpm files in the F20 repository. Lots of changes, for many reasons, are normal, but it is not sensible to expect all these parts to work properly. It is not even reasonable to expect the ten percent of these files on the DVD to all work properly. Fedora QA, as a group, should probably take a pragmatic approach and focus on "critical path" and installation issues that affect large groups of users, and refer more detailed tests to others. Do more, certainly, if resources permit. And try to influence others to be more aware and effective in their test activities. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
ELAN touchpad USB issues
I installed F20 Beta TC4 (KDE) on a Samsung Book 9 plus with no serious difficulty, but touchpad operation is sometimes erratic and I see this in syslog: Oct 16 02:47:18 localhost kernel: [3.407835] usb 2-7: unable to read config index 0 descriptor/start: -71 Oct 16 02:47:18 localhost kernel: [3.407882] usb 2-7: can't read configurations, error -71 Oct 16 02:47:18 localhost kernel: [3.560118] usb 2-7: new full-speed USB device number 5 using xhci_hcd Oct 16 02:47:18 localhost kernel: [5.656458] usb 2-7: unable to read config index 0 descriptor/start: -71 Oct 16 02:47:18 localhost kernel: [5.656506] usb 2-7: can't read configurations, error -71 Oct 16 02:47:18 localhost kernel: [5.963782] usb 2-7: new full-speed USB device number 7 using xhci_hcd Oct 16 02:47:18 localhost kernel: [8.060407] usb 2-7: unable to read config index 0 descriptor/start: -71 Oct 16 02:47:18 localhost kernel: [8.060468] usb 2-7: can't read configurations, error -71 Oct 16 02:47:18 localhost kernel: [8.368442] usb 2-7: new full-speed USB device number 9 using xhci_hcd Oct 16 02:47:18 localhost kernel: [ 10.464875] usb 2-7: unable to read config index 0 descriptor/start: -71 Oct 16 02:47:18 localhost kernel: [ 10.464922] usb 2-7: can't read configurations, error -71 Oct 16 02:47:18 localhost kernel: [ 10.772105] usb 2-7: new full-speed USB device number 11 using xhci_hcd Oct 16 02:47:18 localhost kernel: [ 12.869020] usb 2-7: unable to read config index 0 descriptor/start: -71 Oct 16 02:47:18 localhost kernel: [ 12.869063] usb 2-7: can't read configurations, error -71 Oct 16 02:47:18 localhost kernel: [ 13.021852] usb 2-7: new full-speed USB device number 12 using xhci_hcd Oct 16 02:47:18 localhost kernel: [ 15.118233] usb 2-7: unable to read config index 0 descriptor/start: -71 Oct 16 02:47:18 localhost kernel: [ 15.118281] usb 2-7: can't read configurations, error -71 Oct 16 02:47:18 localhost kernel: [ 15.270600] usb 2-7: new full-speed USB device number 13 using xhci_hcd Oct 16 02:47:18 localhost kernel: [ 17.367835] usb 2-7: unable to read config index 0 descriptor/start: -71 Oct 16 02:47:18 localhost kernel: [ 17.367882] usb 2-7: can't read configurations, error -71 Oct 16 02:47:18 localhost kernel: [ 17.520349] usb 2-7: new full-speed USB device number 14 using xhci_hcd Oct 16 02:47:18 localhost kernel: [ 19.617452] usb 2-7: unable to read config index 0 descriptor/start: -71 Oct 16 02:47:18 localhost kernel: [ 19.617500] usb 2-7: can't read configurations, error -71 Oct 16 02:47:18 localhost kernel: [ 19.617556] hub 2-0:1.0: unable to enumerate USB device on port 7 Oct 16 02:47:18 localhost kernel: [ 19.900025] usb 2-7: new full-speed USB device number 15 using xhci_hcd Oct 16 02:47:18 localhost kernel: [ 19.912781] usb 2-7: New USB device found, idVendor=04f3, idProduct=0089 Oct 16 02:47:18 localhost kernel: [ 19.912825] usb 2-7: New USB device strings: Mfr=4, Product=14, SerialNumber=0 Oct 16 02:47:18 localhost kernel: [ 19.912860] usb 2-7: Product: Touchscreen Oct 16 02:47:18 localhost kernel: [ 19.912881] usb 2-7: Manufacturer: ELAN Oct 16 02:47:18 localhost kernel: [ 19.913069] usb 2-7: ep 0x2 - rounding interval to 64 microframes, ep desc says 80 microframes 2-7 is the touchpad, but the 15 seconds of fuss reported in syslog suggests something is wrong. Here is what the device looks like after I log in (the TC4 system is current with all updates through the current date): [root@localhost ryniker]# lsusb -t /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/9p, 480M |__ Port 4: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M |__ Port 4: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M |__ Port 5: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M |__ Port 5: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M |__ Port 7: Dev 13, If 0, Class=Human Interface Device, Driver=usbhid, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M [root@localhost ryniker]# lsusb -s 2:13 Bus 002 Device 013: ID 04f3:0089 Elan Microelectronics Corp. [root@localhost ryniker]# lsusb -v -s 2:13 Bus 002 Device 013: ID 04f3:0089 Elan Microelectronics Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x04f3 Elan Microelectronics Corp. idProduct 0x0089 bcdDevice0.13 iManufacturer 4 ELAN iProduct 14 Touchscreen iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 41 bNumInterfaces
Re: redhat-lsb-core issues in rawhide
The usbmuxd problems reported by yum in your post are likely unrelated to the lsb issue. I have a similar usbmuxd problem in F20 Beta TC4. After installation, during the first "yum update" I noticed a message about a usbmuxd scriptlet error. This message vanished among messages from hundreds of updates, but I see some problem with yum's installation of usbmuxd persists. I tried to reinstall usbmuxd, which failed, and now I am reluctant to force the issue because it does not seem to causes any actual problem. If there is a recommendation about how to fix this, I am willing to try. I wonder if everyone with F20 TC4 or Rawhide has a similar situation. [root@localhost ryniker]# yum history package usbmuxd Loaded plugins: fastestmirror, langpacks, refresh-packagekit ID | Action(s) | Package --- 6 | Updated| usbmuxd-1.0.8-8.fc20.x86_64## 6 | Update | 1.0.8-10.fc20.x86_64 ## 1 | Dep-Install| usbmuxd-1.0.8-8.fc20.x86_64 [root@localhost ryniker]# yum reinstall usbmuxd Loaded plugins: fastestmirror, langpacks, refresh-packagekit Loading mirror speeds from cached hostfile * fedora: fedora.mirrors.tds.net * updates: fedora.mirrors.tds.net * updates-testing: fedora.mirrors.tds.net Resolving Dependencies --> Running transaction check ---> Package usbmuxd.x86_64 0:1.0.8-10.fc20 will be an update ---> Package usbmuxd.x86_64 0:1.0.8-10.fc20 will be erased --> Finished Dependency Resolution Error: Multilib version problems found. This often means that the root cause is something else and multilib version checking is just pointing out that there is a problem. Eg.: 1. You have an upgrade for usbmuxd which is missing some dependency that another package requires. Yum is trying to solve this by installing an older version of usbmuxd of the different architecture. If you exclude the bad architecture yum will tell you what the root cause is (which package requires what). You can try redoing the upgrade with --exclude usbmuxd.otherarch ... this should give you an error message showing the root cause of the problem. 2. You have multiple architectures of usbmuxd installed, but yum can only see an upgrade for one of those architectures. If you don't want/need both architectures anymore then you can remove the one with the missing update and everything will work. 3. You have duplicate versions of usbmuxd installed already. You can use "yum check" to get yum show these errors. ...you can also use --setopt=protected_multilib=false to remove this checking, however this is almost never the correct thing to do as something else is very likely to go wrong (often causing much more problems). Protected multilib versions: usbmuxd-1.0.8-10.fc20.x86_64 != usbmuxd-1.0.8-8.fc20.x86_64 [root@localhost ryniker]# yum check Loaded plugins: fastestmirror, langpacks, refresh-packagekit usbmuxd-1.0.8-10.fc20.x86_64 is a duplicate with usbmuxd-1.0.8-8.fc20.x86_64 Error: check all [root@localhost ryniker]# -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] 2013-10-16 16:00 UTC - F20 Beta Blocker Bug Review #4
Unnecessary "private" designation for a bug report might be due to https://bugzilla.redhat.com/show_bug.cgi?id=1011916 which complains that a bug reporter has to decide about "private" status before possibly sensitive information in the report can be examined. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Gnome 3.10: Network UI missing from new system status area
Well, a statically configured network interface might be expected to just work. With dynamic configuration, there must be successful contact with a DHCP server, and the server must be willing to assign an IP address and possibly provide other information (gateway, nameserver, host name) to the client host. In this case, a visible indicator of successful network configuration might be useful. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: environment group 'KDE Plasma Workspaces'
>No, they're arch-specific. (geode is 32-bit x86, omap is ARM.) That makes sense. Should yum understand this better? I mean, should the group list specify architecture dependencies: some packages are needed for one architecture, others needed for a different architecture? As things stand, I do not know how to (easily) distinguish cases such as those Rex Dieter fixed, which had missing packages due to incorrect names, from cases where a listed Mandatory Package is not used for the current architecture. From the yum man page: Groups are marked as "installed" if all mandatory packages are installed, or if a group doesn't have any mandatory packages then it is installed if any of the optional or default package are installed (when not in group_command=objects mode). It looks like yum will misunderstand a case like xorg-x11-drv-geode (not applicable for x86_64 architecture) and report that kde-desktop-envorinment is not installed because it requires base-x, for which xorg-x11-drv-geode is a Mandatory Package. This starts to look like my original complaint, where I thought kde-desktop-envorinment (aka 'KDE Plasma Workspaces') had been installed, but yum did not list it as an installed group. Bill, do you think there is a bug here, a documentation error (or words that could be improved), or am I simply barking up the wrong tree? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: environment group 'KDE Plasma Workspaces'
>These packages still exist, and haven't been removed or renamed as far >as I can tell. Yum does not appear able to find them... do you think this is a local problem? [root@lenovo ryniker]# yum list updates Loaded plugins: langpacks, refresh-packagekit [root@lenovo ryniker]# yum repolist Loaded plugins: langpacks, refresh-packagekit repo id repo name status fedora/20/x86_64 Fedora 20 - x86_64 37714 updates/20/x86_64Fedora 20 - x86_64 - Updates 0 *updates-testing/20/x86_64 Fedora 20 - x86_64 - Test Updates 2066 repolist: 39780 [root@lenovo ryniker]# yum info xorg-x11-drv-geode Loaded plugins: langpacks, refresh-packagekit Error: No matching Packages to list [root@lenovo ryniker]# yum info xorg-x11-drv-omap Loaded plugins: langpacks, refresh-packagekit Error: No matching Packages to list [root@lenovo ryniker]# -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: environment group 'KDE Plasma Workspaces'
>just fixed that in comps too, thanks! Interested in others? Group: base-x Mandatory Packages: -xorg-x11-drv-geode -xorg-x11-drv-omap Group-Id: printing Mandatory Packages: -ghostscript-cups -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: environment group 'KDE Plasma Workspaces'
I still find the (maybe my own peculiar) F20 situation confusing. For example: [root@lenovo ryniker]# yum -v group install kde-desktop-environment Not loading "blacklist" plugin, as it is disabled Loading "langpacks" plugin Loading "refresh-packagekit" plugin Not loading "whiteout" plugin, as it is disabled Adding en to language list Config time: 0.419 Yum version: 3.4.3 rpmdb time: 0.000 Setting up Package Sacks pkgsack time: 0.109 group time: 0.266 Skipping group core from environment kde-desktop-environment Skipping group multimedia from environment kde-desktop-environment Skipping group input-methods from environment kde-desktop-environment Skipping group guest-desktop-agents from environment kde-desktop-environment Skipping group base-x from environment kde-desktop-environment Skipping group fonts from environment kde-desktop-environment Skipping group hardware-support from environment kde-desktop-environment Skipping group dial-up from environment kde-desktop-environment Skipping group admin-tools from environment kde-desktop-environment Skipping group printing from environment kde-desktop-environment Skipping group kde-desktop from environment kde-desktop-environment Skipping group standard from environment kde-desktop-environment Warning: environment kde-desktop-environment does not exist. No packages in any requested group available to install or update [root@lenovo ryniker]# Yum is "Skipping group core from environment kde-desktop-environment" perhaps because this group is already installed, but why complain at the end "Warning: environment kde-desktop-environment does not exist."? Yum seems to have found a dozen groups that comprise the environment kde-desktop-environment. I display information about the group kde-desktop and see: [root@lenovo ryniker]# yum -v group info kde-desktop Not loading "blacklist" plugin, as it is disabled Loading "langpacks" plugin Loading "refresh-packagekit" plugin Not loading "whiteout" plugin, as it is disabled Adding en to language list Config time: 0.418 Yum version: 3.4.3 Setting up Package Sacks pkgsack time: 0.109 group time: 0.264 Group: KDE Group-Id: kde-desktop rpmdb time: 0.000 Description: The KDE Plasma Workspaces, a highly-configurable graphical user interface which includes a panel, desktop, system icons and desktop widgets, and many powerful KDE applications. Mandatory Packages: =akonadi-1.10.2-1.fc20.i686 fedora =akonadi-1.10.2-1.fc20.x86_64@fedora =akonadi-mysql-1.10.2-1.fc20.x86_64 @fedora =apper-0.8.1-1.fc20.x86_64 @fedora =appmenu-qt-0.2.6-4.fc20.i686fedora =appmenu-qt-0.2.6-4.fc20.x86_64 @fedora =ark-4.11.0-1.fc20.x86_64@fedora =bluedevil-2.0.0-0.1.20130621.fc20.i686 fedora =bluedevil-2.0.0-0.1.20130621.fc20.x86_64@fedora =cagibi-0.2.0-6.fc20.x86_64 @fedora cups-pk-helper-0.2.5-2.fc20.x86_64 @anaconda firewall-config-0.3.4-1.fc20.noarch @anaconda =gwenview-4.11.0-1.fc20.x86_64 @fedora =initial-setup-0.3.8-1.fc20.noarch @updates-testing =kamera-4.11.0-1.fc20.x86_64 @fedora =kamoso-2.0.2-12.fc20.x86_64 @fedora =kcalc-4.11.0-1.fc20.x86_64 @fedora =kcharselect-4.11.0-1.fc20.x86_64@fedora =kcm-gtk-0.5.3-14.fc20.x86_64@fedora =kcm_touchpad-0.3.1-10.fc20.x86_64 @fedora =kcolorchooser-4.11.0-1.fc20.x86_64 @fedora =kde-baseapps-4.11.0-1.fc20.x86_64 @fedora =kde-plasma-nm-0.9.3.0-6.fc20.i686 updates-testing =kde-plasma-nm-0.9.3.0-6.fc20.x86_64 @updates-testing =kde-plasma-nm-l2tp-0.9.3.0-6.fc20.x86_64 @updates-testing =kde-plasma-nm-openconnect-0.9.3.0-6.fc20.x86_64 @updates-testing =kde-plasma-nm-openswan-0.9.3.0-6.fc20.x86_64 @updates-testing =kde-plasma-nm-openvpn-0.9.3.0-6.fc20.x86_64 @updates-testing =kde-plasma-nm-pptp-0.9.3.0-6.fc20.x86_64 @updates-testing =kde-plasma-nm-vpnc-0.9.3.0-6.fc20.x86_64 @updates-testing
Re: environment group 'KDE Plasma Workspaces'
>There is both a group and environment with: > KDE Plasma Workspaces I presume you mean this is a repository problem. I tried "yum clean all" and that did not help, even though I understand this will reload all metadata (like group information) from the repository. Or do you mean I may have created this state by an attempt to install kde-desktop-environment when it was already installed? I think at worst that would tell me there is nothing to do; it should not create duplicate name problems. I looked at http://fedoraproject.org/wiki/Features/YumGroupsAsObjects but do not think that is relevant. I thought about an attempt to remove the kde-desktop-environment then re-install it, but this is not something I need to fix: whether that made the situation better or worse, it probably becomes more difficult to learn just what happened to create this state. If someone thinks remove/re-install could provide useful information, I should be happy to try it. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: environment group 'KDE Plasma Workspaces'
Still bizarre; works for you, not for me. Today: [root@lenovo ryniker]# yum distro-sync full Loaded plugins: langpacks, refresh-packagekit No packages marked for distribution synchronization [root@lenovo ryniker]# yum groupinstall "KDE Plasma Workspaces" Loaded plugins: langpacks, refresh-packagekit Warning: environment KDE Plasma Workspaces does not exist. No packages in any requested group available to install or update [root@lenovo ryniker]# yum repolist Loaded plugins: langpacks, refresh-packagekit repo id repo name status fedora/20/x86_64 Fedora 20 - x86_64 37718 updates/20/x86_64Fedora 20 - x86_64 - Updates 0 updates-testing/20/x86_64Fedora 20 - x86_64 - Test Updates 1513 repolist: 39231 [root@lenovo ryniker]# I'll leave this alone for a while, in case somebody has a suggestion about how to learn more about why this occurs. When Alpha is released, I will re-install. Thank you for your data; it seems only I see this effect. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
environment group 'KDE Plasma Workspaces'
I believe the KDE environment is installed on my up-to-date F20 machine, but "yum group list" does not show it is installed. Suspecting it might not be *completely* installed, I tried to install it and yum complained: Warning: environment KDE Plasma Workspaces does not exist. Is this merely personal confusion, or is something truly wrong? If an environment group is installed, should it be listed as "Installed"? The 'GNOME Desktop' was installed as the default environment, but is not listed as "Installed". Because I think KDE Plasma Workspaces is installed, I expected some output from yum to tell me there are no packages to install. I do see this expected output from an explicit request to install 'GNOME desktop'. Details... [root@lenovo ryniker]# uname -a Linux lenovo 3.11.0-300.fc20.x86_64 #1 SMP Thu Sep 5 18:52:54 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux [root@lenovo ryniker]# yum group list Loaded plugins: langpacks, refresh-packagekit Available environment groups: GNOME Desktop KDE Plasma Workspaces Xfce Desktop LXDE Desktop Cinnamon Desktop MATE Desktop Sugar Desktop Environment Development and Creative Workstation Web Server Infrastructure Server Basic Desktop Minimal Install Installed groups: Administration Tools Available Groups: 3D Printing Authoring and Publishing Books and Guides C Development Tools and Libraries Cloud Infrastructure Design Suite Development Tools Editors Educational Software Electronic Lab Engineering and Scientific Fedora Eclipse FreeIPA Server Games and Entertainment LibreOffice Medical Applications Milkymist Network Servers Office/Productivity RPM Development Tools Robotics Security Lab Sound and Video System Tools Text-based Internet Window Managers Done [root@lenovo ryniker]# yum list updates Loaded plugins: langpacks, refresh-packagekit [root@lenovo ryniker]# yum group install 'KDE Plasma Workspaces' Loaded plugins: langpacks, refresh-packagekit Warning: environment KDE Plasma Workspaces does not exist. No packages in any requested group available to install or update [root@lenovo ryniker]# yum install '@^KDE Plasma Workspaces' Loaded plugins: langpacks, refresh-packagekit Warning: Environment Group KDE Plasma Workspaces does not exist. Nothing to do [root@lenovo ryniker]# yum group install 'GNOME Desktop' Loaded plugins: langpacks, refresh-packagekit Warning: Group gnome-desktop does not have any packages to install. Warning: Group firefox does not have any packages to install. No packages in any requested group available to install or update [root@lenovo ryniker]# -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F20 anaconda progress bar
On my last installation (TC4) anaconda's blue progress bar stalled at approximately 40% while thousands of packages were installed. I suspect this is "Working as Designed". There is a continuing display of package names as they are installed, as well as counts of installed packages and total number of packages to be installed, therefore a user is not likely to think the installation process is stuck just because there is no movement of the progress bar. The little slide show below the progress bar also continues. This does, however, give an impression the installer is a bit crude: during the longest part of the installation process, there is no movement of the progress bar. If someone does see better behavior of the anaconda progress indicator, please post to say it is my experience that is wacky. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F20 alpha TC1 problems
Makes sense... the kernel is "tainted" after an oops. I was distracted by thoughts about software with dubious provenance. The first kernel oops (that taints the kernel) is documented here: https://bugzilla.redhat.com/show_bug.cgi?id=1001806 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F20 alpha TC1 problems
This is recorded in my system journal (booting the iso install image from a USB flash drive): Aug 26 16:11:38 localhost kernel: ACPI Warning: \_SB_.PCI0.P0P1.PEGP._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95) Aug 26 16:11:38 localhost kernel: ACPI Warning: \_SB_.PCI0.P0P1.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130517/nsarguments-95) Full journal file is available here: http://ryniker.ods.org/errors/F20/lenovo/ There was a kernel problem logged earlier in the journal, but that is not obviously related (I'll file a bug for it): Aug 26 16:11:36 localhost kernel: WARNING: CPU: 0 PID: 54 at lib/dma-debug.c:950 check_for_stack+0xa0/0x100() Aug 26 16:11:36 localhost kernel: ehci-pci :00:1a.0: DMA-API: device driver maps memory fromstack [addr=880427629376] Aug 26 16:11:36 localhost kernel: Modules linked in: floppy(+) scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi squashfs cramfs edd dm_multipath Aug 26 16:11:36 localhost kernel: CPU: 0 PID: 54 Comm: khubd Not tainted 3.11.0-0.rc6.git4.1.fc20.x86_64 #1 Aug 26 16:11:36 localhost kernel: Hardware name: LENOVO 7745/7745, BIOS DUKT31AUS 05/23/2011 There is another kernel problem logged later: Aug 26 16:11:41 localhost kernel: WARNING: CPU: 0 PID: 54 at fs/sysfs/dir.c:530 sysfs_add_one+0xa5/0xd0() Aug 26 16:11:41 localhost kernel: sysfs: cannot create duplicate filename '/class/power_supply/hid--battery' Aug 26 16:11:41 localhost kernel: Modules linked in: nouveau mxm_wmi wmi video i2c_algo_bit drm_kms_helper ttm e1000e drm ptp i2c_core pps_core usb_storage sunrpc sha256_ssse3 dm_crypt dm_round_robin linear raid10 raid456 async_raid6_recov async_memcpy async_pq raid6_pq async_xor xor async_tx raid1 raid0 iscsi_ibft iscsi_boot_sysfs scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi squashfs cramfs edd dm_multipath Aug 26 16:11:41 localhost kernel: CPU: 0 PID: 54 Comm: khubd Tainted: G W3.11.0-0.rc6.git4.1.fc20.x86_64 #1 Aug 26 16:11:41 localhost kernel: Hardware name: LENOVO 7745/7745, BIOS DUKT31AUS 05/23/2011 What does "Tainted" mean two lines above? That sounds a bit strange for a regular Fedora image. Finally, the wheels fall off a few seconds later: Aug 26 16:11:46 localhost kernel: general protection fault: [#1] SMP Aug 26 16:11:46 localhost kernel: Modules linked in: crc32_pclmul crc32c_intel ghash_clmulni_intel nouveau mxm_wmi wmi video i2c_algo_bit drm_kms_helper ttm e1000e drm ptp i2c_core pps_core usb_storage sunrpc sha256_ssse3 dm_crypt dm_round_robin linear raid10 raid456 async_raid6_recov async_memcpy async_pq raid6_pq async_xor xor async_tx raid1 raid0 iscsi_ibft iscsi_boot_sysfs scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi squashfs cramfs edd dm_multipath Aug 26 16:11:46 localhost kernel: CPU: 1 PID: 54 Comm: khubd Tainted: G W3.11.0-0.rc6.git4.1.fc20.x86_64 #1 Aug 26 16:11:46 localhost kernel: Hardware name: LENOVO 7745/7745, BIOS DUKT31AUS 05/23/2011 -- 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
Sounds like an unfortunate situation that should be addressed by use of a Live system, which can repair or salvage data from the afflicted file systems. If repair is possible, job done. If not possible, solution is to re-install the operating system. Rather than invest serious effort to make systemd (or other components) tolerate various types of severe damage to the operating system, it seems better to learn how such damage happens, then devise ways to prevent this occurrence in the first place. If something is wrong, I much prefer to see an obvious symptom, even if there is no clear indication of the nature of the failure. I have too often had to clean up damage when a "robust" application found some way to continue, with unexpected semantics, after it decided it could "tolerate" some failure. Programs can be designed to detect certain failures and cope with them in reasonable ways. In your case with systemd, it is simply impossible to continue in a responsible way without the configuration data systemd requires, but lost when your file system was corrupted. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: No mail received from redhat (fedora)
Yeah, you have some sort of problem (configuration issue?) with your MTA: 2013-06-22 14:52:17 1UqSv3-0001aS-Kb <= ryni...@ryniker.ods.org U=ryniker P=local S=863 2013-06-22 14:52:18 1UqSv3-0001aS-Kb ** c...@omen.com R=dnslookup T=remote_smtp: SMTP error from remote mail server after RCPT TO:: host omen.com [70.89.176.169]: 550 5.7.1 ... Relaying denied -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: bootloader "very slow installation" --Fedora 19 Final Test Compose 2 (TC2)
>Might it be possible to defer construction of the yum database until >Firstboot? Just want to make it clear this is something to consider for F20. I think it is too late to make this sort of change in F19. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: bootloader "very slow installation" --Fedora 19 Final Test Compose 2 (TC2)
John Reiser wrote on Sat, 08 Jun 2013 07:37:56 -0700: >The database consists of a directory for each installed package, and >each directory contains 8 symlinks for the attributes of that package. >So if 1000 packages are installed then 9000 new files are created. I can imagine a superior data base system that would support thousands of transactions before a commit, instead of one transaction per commit. However, I have zero enthusiasm for serious changes to yum without real conviction they are necessary. Nevertheless, 10 minutes times tens of thousands of Fedora installations yields enough time for serious amounts of thumb-twiddling. Might it be possible to defer construction of the yum database until Firstboot? At that time, yum (or some yum helper) could run concurrently with useful activity to build the database. If yum were invoked before its database existed, it would have to build it. Yum already has a mechanism to keep two yum instances from simultaneous operation. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: su starts behaving oddly sometimes on F19
Does SELinux affect the problem? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Dealing with critical bugs in final releases
I think new builds is a bad idea, a response to a worst-case event that hopefully never happens. If the quality assurance process that generated multiple alpha, beta, and release candidate builds has failed, another try to fix one more bug will have less complete testing: it is too likely to add new problems while it fixes others. Instead, users unable to install a new release should continue with an older Fedora release. It will only be six months until the next regular release. The truly adventurous (desperate) may experiment with Rawhide. For problems that impact more than very rare installations, someone is likely to create an ad hoc Fedora build for that group. This may be helpful, but it should not be described or distributed as a normal Fedora release. If problems with a new release are unusually severe, some of the effort that normally would focus solely on that release (upstream maintenance, new applications, kernels) may spread into earlier Fedora releases to help affected users wait for the next regular Fedora cycle. Only if these alternatives appear inadequate to a group of testers and developers obviously large enough to insure production-quality tests of a post-final new build should we attempt such an extraordinary measure. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 partitioning LVM Question....
True, a usage scenario can often be devised to manifest the worst aspects of any allocation scheme. There are many other factors that can have so much influence that I suspect the number of partitions and volume groups may have little to do with actual performance. Disk device caching and operating system memory buffer management may greatly reduce the actual time penalty due to long seeks. The actual physical extents allocated to a logical volume may be far from contiguous, therefore long seeks may be needed even for what appears to be logically contiguous data. It has to be technically possible, but I have not heard about any utility to defragment a logical volume... to modify the mapping of logical extents to physical extents (simultaneously, for all the logical volumes in a volume group) in order to optimize physical contiguity of logical data. This is a very scary thing, because optimum results would require understanding and possible adjustment of individual files' allocations within the file systems in logical volumes. Disk drives contribute their own distortions into the performance picture by mapping bad disk blocks to replacement blocks that may be far from the original block's location. Conclusion: this is an interesting topic for discussion, but so many factors may affect actual results that only careful instrumentation and measurement of a specific application is likely to show what factors are significant for that case. Solid state drives may make these questions of little concern, but raise some new issues of interest. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Help needed in F18: firefox disappears from the gnome3 favorites bar each time when logging out
I do not see this behavior; F18 updated to current level (without updates-testing). The firefox icon remains in my Favorites bar through logout-login, and through reboot. Default Gnome desktop. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 partitioning LVM Question....
>How does having two PVs on the same spindle increase latency? Longer seeks - from one PV to the other - instead of two writes into the same PV. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Configure Mount Point doesn't appear to work
>> Swap is a bit odd. > >I don't see it as being any more or less odd than any other mount point. It's >either manual partitioning or not. Swap is indeed odd. An unusual swap partition on an F18 target installation disk can scuttle anaconda... https://bugzilla.redhat.com/show_bug.cgi?id=886243 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: dracut whines...
It has been reported... https://bugzilla.redhat.com/show_bug.cgi?id=849476 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
dracut whines...
F18 TC1 x86-64 install DVD displays some complaints (the following indented lines appeared on the console, but I copied them later from /var/log/boot.log): [[1;32m OK [0m] Started Show Plymouth Boot Screen. [[1;32m OK [0m] Reached target Basic System. dracut-pre-pivot[457]: cp: cannot stat '/etc/cmdline': No such file or directory dracut-pre-pivot[457]: mount: wrong fs type, bad option, bad superblock on /var/lib/nfs/rpc_pipefs, dracut-pre-pivot[457]: missing codepage or helper program, or other error dracut-pre-pivot[457]: In some cases useful info is found in syslog - try dracut-pre-pivot[457]: dmesg | tail or so Welcome to [1mLinux[0m! I did not observe any problem that I can attribute to the condition reported by these messages, but they appear to say something unexpected has occurred. There was no line in /tmp/syslog that contained "dracut" but I can supply this file if anyone has an interest in it. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Anaconda crashes trying to install Inkscape
Mateusz Marzantowicz wrote on Tue, 11 Dec 2012 07:15:57 +0100 >Maybe there should be two groups of packages: important (core or >whatever) that must be installed and other (not important) that might >fail to install? I think it better to start over with a "minimal install" (where all "important" packages are successfully loaded), then move forward from that point, than to try to use a just-installed system that is known to be broken in some ill-defined way. Certainly it asks too much from the installer to discern what package installation failures will be acceptable to one user but not for another. If the Inkscape failure results from selection of additional software to be included in the original installation, a default installation without additional software may succeed. Then, it will not be necessary to drop back all the way to a minimal installation. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Reclaim disk space doesn't reuse existing swap, should it?
John Reiser wrote on Fri, 07 Dec 2012 07:30:50 -0800 >NO! NO! NO! Do NOT format any partition, including swap partitions, >except when explicitly requested. I want to share _some_ swap partitions, >but running mkswap destroys the UUID and/or label which other /etc/fstab >depend on. I still think it is better to arrange shared swap spaces after installation of a new system. Yes, the installer could offer the option to format or not format a swap space. Certainly, if the installer creates a new swap space, it must be formatted. For an existing swap space... it's more complicated. Must the installer ascertain whether an existing swap space is correctly formatted? Should the installer offer a facility to set priority values for swap spaces used by the new system? What about page size? I am no expert (well, maybe a modest expert), but I think linux supports four page sizes on Intel processors: 4, 8, 16, and 64 KBytes [see: arch/ia64/include/asm/page.h]. Swap spaces must be formatted for the appropriate page size. Rather than ask the installer to handle an issue this complex, which can readily be arranged after installation, I prefer the installer be limited to things that cannot reasonably be done later. If the installer permits a request to include a swap space without formatting it, it should refuse if this existing swap space cannot be used by the kernel it will install. Without this check, it seems all to easy for a user to think he has a swap space when it actually will not be used. I must admit I have never tested how astute the Fedora installer is about swap spaces. Maybe it is terribly clever, and everything always comes out right. I'll try a test the next time I install. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Reclaim disk space doesn't reuse existing swap, should it?
Probably not. There are too many possibilities to make reasonable any default except "do what the user explicitly says is desired". The usual problems are hot-swap devices (USB, ESATA, etc.) that may be present during installation but not later, and swap spaces intended for other operating systems than the one currently being installed. It seems prudent to have the installer perform mkswap on any spaces the user identifies for use by this installed system, but mkswap will destroy data in a swap space in use by another (perhaps hibernating) system. Swapon will not activate any swap space it perceives as in use. With several operating systems "sharing" a swap space, it is easy to imagine one system does not shut down cleanly, and this swap space is then not used for months, even years, until someone fixes the problem or a new installation performs mkswap. There are cases where shared swap spaces may make sense. I think these are more appropriate to set up after installation, with edits to /etc/fstab, than with additional complexity in the system installer. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: TC7 bootloader installation
>we should make this possible via a command line parameter rather than a UI >option; it's an 'advanced' option that's only of use to multiboot >pokemoners (you know...gotta catch 'em all) and is a 'dangerous' option >for anyone who doesn't understand it - if you pick it when you don't know >what you're doing, you get a non-bootable install. It seems ugly to implement an esoteric command line parameter that changes the behavior of the Fedora installer. If the capability is valuable, it should be part of the new user interface, and the installer should make a "best effort" attempt to keep the user from shooting himself in the foot - at least warn that this option is dangerous, and demand confirmation this is what the user really wants to do. >you get a non-bootable install. Actually, one reason a user might choose to put the Fedora bootloader elsewhere than the MBR is to insure his existing boot process remains intact, in the event the new Fedora installation fails to boot, or fails to find and successfully boot his other operating systems already installed. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 at-spi* deps
Frank Murphy wrote on Fri, 26 Oct 2012 08:33:25 +0100: >So you agree, it's unneccessary. >For me to need at-spi*. Point made. I think the point was at-spi is part of GTK, but this part is not something it is reasonable to package separately, such as a language package or some esoteric locale. The default GTK configuration does not activate Assistive Technology features, therefore they do not intrude on a user like you. Indeed, you do not need at-spi. However, some other users can benefit from AT capabilities, and they are available to those users with appropriate GTK configuration. I am confident it is technically possible to create two GTK versions - one with AT and one without. This would make possible all of the usual additional complications and costs two versions of a large application can create, compared to a single version. Bad idea. It should also be possible to make at-spi a separately installed package, but I expect the GTK developers decided the cost of tests to determine whether at-spi was installed was significantly larger than the cost to include at-spi in the GTK core. Why, then, is at-spi a separate package at all? If it were quietly incorporated into other GTK packages, you might be more comfortable. I suggest the separate at-spi package makes it easier to enhance and test these Assistive Technologies, without a need to rebuild/replace the entire GTK system. If you want GTK, I think your only reasonable course is to accept AT (and not enable it - the default condition that most users prefer). If you really have no interest in GTK (and any of the applications that require it) - I think there are a good number of server or dedicated system instances that meet this condition - you can consider some minimal, focused Fedora installation optimized for your situation. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
