Re: Upgrade upgrade-testing Of kf5-akonadi-mime Fails
On Saturday, May 21, 2022 2:34:53 AM EDT Samuel Sieb wrote: > On 2022-05-20 15:23, Garry T. Williams wrote: > > Anyone know what I managed to mess up here? > > > > Update using updates-testing gives this error: > > > > Error: Transaction test error: > >file /usr/share/config.kcfg/specialmailcollections.kcfg from install of > > kf5-akonadi-mime-22.04.1-1.fc36.x86_64 conflicts with file from package > > kdepimlibs-4.14.10-39.fc36.x86_64 > > > > Update is successful when I exclude kf5-akonadi-mime. > > > > Should I delete /usr/share/config.kcfg/specialmailcollections.kcfg and > > run an update? > > That won't do any good since the problem is in the packages. Yeah, I should have known. > It looks like a packaging error. Both packages are trying to provide > the same filename with different contents (or permissions). I don't > want to install a pile of kde packages, so I can't test it myself. > > I suggest contacting the kde mailing list or filing a bug on one of the > packages. I gave -1 karma to the update and reported the error. Someone else noted that simply removing kdepimlibs solved the problem. I'm not sure how I ended up with that package on this machine (it's not on my other f36 machines), but that looks like a good fix. -- Garry T. Williams ___ 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
Upgrade upgrade-testing Of kf5-akonadi-mime Fails
Anyone know what I managed to mess up here? Update using updates-testing gives this error: Error: Transaction test error: file /usr/share/config.kcfg/specialmailcollections.kcfg from install of kf5-akonadi-mime-22.04.1-1.fc36.x86_64 conflicts with file from package kdepimlibs-4.14.10-39.fc36.x86_64 Update is successful when I exclude kf5-akonadi-mime. Should I delete /usr/share/config.kcfg/specialmailcollections.kcfg and run an update? Any idea how I got here? (I did have _copr:copr.fedorainfracloud.org:marcdeop:frameworks.repo and _copr:copr.fedorainfracloud.org:marcdeop:plasma.repo enabled, but I downgraded everything from there and downgraded back to original repos and then upgraded before enabling updates-testing.) -- Garry T. Williams ___ 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: F36 Upgraded, But Now: Failed to resolve allow statement
On Tuesday, May 3, 2022 6:55:45 AM EDT Kamil Paral wrote: > On Tue, May 3, 2022 at 12:58 AM Garry T. Williams > wrote: > > Thanks, Adam. But reinstalling already failed to fix the problem for > > me. > > Gary, have you tried reinstalling just selinux-policy, or have you tried > the exact command as suggested by Adam? Because the problem was most > probably in flatpak-selinux, according to your error message. We're nearing > F36 release and this issue is quite important - please tell us what exactly > you tried before restorting to 'semodule -r', it will help us a lot. Thanks! From my shell history: sudo dnf erase selinux-policy selinux-policy-targeted swtpm swtpm-libs swtpm-tools sudo dnf install selinux-policy selinux-policy-targeted swtpm swtpm-libs swtpm-tools sudo dnf reinstall selinux-policy-targeted swtpm sudo dnf reinstall selinux-policy-targeted swtpm snapd-selinux flatpak-selinux container-selinux osbuild-selinux Incidentally, I only have selinux-policy-targeted and swtpm installed on this system: $ rpm -q selinux-policy-targeted swtpm snapd-selinux flatpak-selinux container-selinux osbuild-selinux selinux-policy-targeted-36.6-1.fc36.noarch swtpm-0.7.2-1.20220307git21c90c1.fc36.x86_64 package snapd-selinux is not installed package flatpak-selinux is not installed package container-selinux is not installed package osbuild-selinux is not installed $ -- Garry T. Williams ___ 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: F36 Upgraded, But Now: Failed to resolve allow statement
On Monday, May 2, 2022 6:17:46 PM EDT Adam Williamson wrote: > On Mon, 2022-05-02 at 16:51 -0400, Garry T. Williams wrote: > > How do I fix an F36 system that gets this error: > > > > $ sudo setsebool -PV rsync_export_all_ro true > > Failed to resolve allow statement at > > /var/lib/selinux/targeted/tmp/modules/200/flatpak/cil:122 > > Failed to resolve AST > > Failed to commit changes to booleans: Success > > $ > > > > I believe the error was created when I upgraded. This bug report was > > identified and a duplicate of mine at that time (about a month ago): > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2075651 > > > > I have tried uninstalling and reinstalling selinux-policy to no avail. > > See https://bugzilla.redhat.com/show_bug.cgi?id=2056303 for quite a lot > of discussion about this kinda thing. You can try: > > dnf reinstall selinux-policy-targeted swtpm snapd-selinux flatpak-selinux > container-selinux osbuild-selinux > > as suggested in comment #93. Thanks, Adam. But reinstalling already failed to fix the problem for me. But I tried comment #13, sudo semodule -X 200 -r snappy -r container -r flatpak -X 400 -r pcpupstream -r pcpupstream-container -X 100 -r pcp and that did the trick for me (flatpak and pcp were the only modules installed here). My policy is no longer broken. -- Garry T. Williams ___ 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
F36 Upgraded, But Now: Failed to resolve allow statement
How do I fix an F36 system that gets this error: $ sudo setsebool -PV rsync_export_all_ro true Failed to resolve allow statement at /var/lib/selinux/targeted/tmp/modules/200/flatpak/cil:122 Failed to resolve AST Failed to commit changes to booleans: Success $ I believe the error was created when I upgraded. This bug report was identified and a duplicate of mine at that time (about a month ago): https://bugzilla.redhat.com/show_bug.cgi?id=2075651 I have tried uninstalling and reinstalling selinux-policy to no avail. -- Garry T. Williams ___ 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: Priority test request: jpegxl (F34)
On Wednesday, June 16, 2021 1:50:57 PM EDT Samuel Sieb wrote: > On 2021-06-16 10:08 a.m., Garry T. Williams wrote: > > On Wednesday, June 16, 2021 12:46:06 PM EDT Adam Williamson wrote: > >> Hi folks! Just wanted to flag an F34 update to get tested so we can > >> push it stable ASAP: > >> > >> https://bodhi.fedoraproject.org/updates/FEDORA-2021-d7b1dc57fe > >> > >> The above update removes the recommends from jpegxl-libs to break this > >> chain, so updating libaom will no longer pull in GIMP. Obviously I want > >> to get it pushed stable ASAP so the issue happens to as few people as > >> possible. Thanks! > > > > I just did an update and this is what got done. Pretty sure that this > > wasn't intended from your explanation above: > > > > Installing dependencies: > > jpegxl-libs x86_64 0.3.7-2.fc34 updates > > 932 k > > The update version is jpegxl-0.3.7-3.fc34, which doesn't appear to be in > the updates-testing repo yet. Oops. Sorry for the noise. -- Garry T. Williams ___ 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: Priority test request: jpegxl (F34)
4 0.63-4.fc34 updates-testing 382 k libvmaf x86_64 2.1.1-1.fc34 updates 171 k openldapx86_64 2.4.57-5.fc34 updates-testing 256 k pipewirex86_64 0.3.30-4.fc34 updates-testing 134 k pipewire-alsa x86_64 0.3.30-4.fc34 updates-testing 57 k pipewire-jack-audio-connection-kit x86_64 0.3.30-4.fc34 updates-testing 110 k pipewire-libs x86_64 0.3.30-4.fc34 updates-testing 1.2 M pipewire-pulseaudio x86_64 0.3.30-4.fc34 updates-testing 24 k python3-dnf noarch 4.8.0-1.fc34 updates-testing 415 k python3-dnf-plugin-system-upgrade noarch 4.0.15-1.fc34 updates-testing 31 k python3-dnf-plugins-corenoarch 4.0.22-1.fc34 updates-testing 210 k python3-dnf-plugins-extras-common noarch 4.0.15-1.fc34 updates-testing 61 k python3-hawkey x86_64 0.63.1-1.fc34 updates-testing 114 k python3-libcompsx86_64 0.1.17-1.fc34 updates-testing 48 k python3-libdnf x86_64 0.63.1-1.fc34 updates-testing 783 k python3-librepo x86_64 1.14.1-1.fc34 updates-testing 50 k qemu-guest-agentx86_64 2:5.2.0-8.fc34updates-testing 184 k vim-X11 x86_64 2:8.2.2956-2.fc34 updates 1.9 M vim-common x86_64 2:8.2.2956-2.fc34 updates 6.6 M vim-enhancedx86_64 2:8.2.2956-2.fc34 updates 1.8 M vim-filesystem noarch 2:8.2.2956-2.fc34 updates 23 k vim-minimal x86_64 2:8.2.2956-2.fc34 updates 697 k vlc x86_64 1:3.0.15-2.fc34 rpmfusion-free-updates 1.5 M vlc-corex86_64 1:3.0.15-2.fc34 rpmfusion-free-updates 9.6 M xxhash-libs x86_64 0.8.0-3.fc34 updates-testing 40 k yum noarch 4.8.0-1.fc34 updates-testing 45 k Installing dependencies: bablx86_64 0.1.86-1.fc34 fedora 370 k flexiblas x86_64 3.0.4-3.fc34 fedora 31 k flexiblas-netlibx86_64 3.0.4-3.fc34 fedora 3.0 M flexiblas-openblas-openmp x86_64 3.0.4-3.fc34 fedora 18 k gegl04 x86_64 0.4.30-1.fc34 fedora 2.1 M gimpx86_64 2:2.10.24-1.fc34 fedora 21 M gimp-libs x86_64 2:2.10.24-1.fc34 fedora 545 k gperftools-libs x86_64 2.9.1-1.fc34 fedora 318 k jpegxl-libs x86_64 0.3.7-2.fc34 updates 932 k libgexiv2 x86_64 0.12.2-2.fc34 fedora 83 k libgfortran x86_64 11.1.1-3.fc34 updates 804 k libmypaint x86_64 1.6.1-3.fc34 fedora 222 k libquadmath x86_64 11.1.1-3.fc34 updates 205 k libwmf x86_64 0.2.12-5.fc34 fedora 118 k openblasx86_64 0.3.15-1.fc34 updates 32 k openblas-openmp x86_64 0.3.15-1.fc34 updates 4.6 M poppler-glibx86_64 21.01.0-7.fc34updates 154 k pygobject2 x86_64 2.28.7-12.fc34fedora 241 k pygtk2 x86_64 2.24.0-34.fc34fedora 972 k suitesparse x86_64 5.4.0-6.fc34 fedora 1.0 M tbb x86_64 2020.3-7.fc34 updates-testing 170 k Installing weak dependencies: gimp-jxl-plugin x86_64 0.3.7-2.fc34 updates 922 k jxl-pixbuf-loader x86_64 0.3.7-2.fc34 updates 414 k mypaint-brushes noarch 1.3.1-3.fc34 fedora 1.3 M -- Garry T. Williams ___ 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 issues with <= 0.3.24
On Monday, April 19, 2021 10:22:38 AM EDT Garrett LeSage wrote: > Several weeks ago, while running Fedora 34 pre-beta, I had a bunch > of PipeWire issues preventing me from successfully doing video > conferences and listening to music. I reported the issues upstream. > The problems included using Bluetooth headphones (at all), codecs > for the headphones, switching outputs, and issues when doing video > calls. It was a mess, multiple times a day. > > I'm happy to say they were all fixed with the latest release of > pipewire-0.3.25-1.fc34 and my system has been mostly problem-free > with audio since upgrading. > > However, after two weeks, this bugfix version is still in testing... > and doesn't like it will make it for Fedora 34 at this moment: > https://bodhi.fedoraproject.org/updates/FEDORA-2021-46a2394c6d I just gave karma for this update (pipewire-0.3.25-1.fc34.x86_64), so maybe that will help. I am pleased to report that it eliminated a very annoying latency with bluetooth and pulseaudio that I have had for years. -- Garry T. Williams ___ 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: How To Test pipewire On F33?
On Sunday, January 24, 2021 12:27:38 PM EST Qiyu Yan wrote: > My procedure: > > 1. sudo swap pulseaudio pipewire-pulseaudio --allowerasing > --enablerepo=updates-testing > > If you lost sound: > > 2. sudo systemctl enable --global pipewire-pulse.socket > > The second step should be done automatically, but it's not the case for > me... OK, that's what I have been doing. But... I get these errors repeated every one second after reboot: Jan 24 12:44:25 gtw pipewire-pulse[2136]: pulse-server 0x55fea9939530: failed to connect client: Host is down Jan 24 12:44:25 gtw pipewire-pulse[2136]: pulse-server 0x55fea994e880: [QPulse] ERROR command:9 (SET_CLIENT_NAME) tag:1 error:6 (Host is down) I repeated the procedure right after reading your message. Sound continued to work fine. But after reboot, thos errors came back. The time before trying this, sound was immediately gone and the log showed those errors. -- Garry T. Williams ___ 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
How To Test pipewire On F33?
What is the procedure for testing pipewire on a F33 system? (I'm obviously doing something wrong since the bug seems to not make sense to anyone: https://bugzilla.redhat.com/show_bug.cgi?id=1912150 and yet my system will not function at all for audio after I swap in pipewire for pulseaudio.) -- Garry T. Williams ___ 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: Fedora Audio Test Cases for Test Day (a proposal)
On Wednesday, January 20, 2021 11:01:59 AM EST Brandon Nielsen wrote: > Would some kind of device switching test case be feasible? In my > experience that's where a lot of weird behavior creeps in. For example, > plugging in a USB interface, using it, and unplugging it. https://bugzilla.redhat.com/show_bug.cgi?id=1912150 -- Garry T. Williams ___ 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: F30 Testing request: "basic graphics mode" in Workstation
On Wednesday, March 6, 2019 3:46:22 PM EST Adam Williamson wrote: > It'd be very helpful if folks with a test box can boot a Fedora 30 > Workstation live image on it, using the 'Start > Fedora-Workstation-Live 30 in basic graphics mode' option from the > 'Troubleshooting' menu, and see if it successfully reaches the > desktop. Here's an image you can use: > > https://kojipkgs.fedoraproject.org/compose/branched/ Fedora-30-20190301.n.0/compose/Workstation/x86_64/iso/Fedora- Workstation-Live-x86_64-30-20190301.n.0.iso Dell XPS-13 laptop i7-8550U: No joy -- hangs without desktop. -- Garry T. Williams ___ 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: Cannot Boot After Doing system-upgrade
On Saturday, October 13, 2018 7:34:44 PM EDT Chris Murphy wrote: > Good catch. It's vaguely possible there's a bug in either shim 15-5 > or grub2-efi 2.02-58 as it relates to your firmware, that caused > it to silently fail, and the firmware did a fallback to the 2nd > BootOrder, which is the Ubuntu entry. I want to emphasize that it was *not* boot order that changed. I manually attempted to boot Fedora, but it failed (oh how I wish I had paid attention to the details). Anyway, I can manually change the boot order to either OS and it respects my change. My problem was something else entirely since a manual change didn't boot Fedora. I may try the manual downgrade, if I get time. I am usually physically away from this system so I will retrieve the old versions and be ready when I can get the time. Again, thank you for your thoughtful follow-ups. -- Garry T. Williams ___ 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: Cannot Boot After Doing system-upgrade
By the way, from the journal during the dnf system-upgrade reboot: Sep 30 10:02:27 vfr dnf[831]: grub2-common.noarch 1:2.02-58.fc29 Sep 30 10:02:27 vfr dnf[831]: grub2-efi-x64.x86_64 1:2.02-58.fc29 Sep 30 10:02:27 vfr dnf[831]: grub2-pc.x86_64 1:2.02-58.fc29 Sep 30 10:02:27 vfr dnf[831]: grub2-pc-modules.noarch 1:2.02-58.fc29 Sep 30 10:02:27 vfr dnf[831]: grub2-tools.x86_64 1:2.02-58.fc29 Sep 30 10:02:27 vfr dnf[831]: grub2-tools-efi.x86_64 1:2.02-58.fc29 Sep 30 10:02:27 vfr dnf[831]: grub2-tools-extra.x86_64 1:2.02-58.fc29 Sep 30 10:02:27 vfr dnf[831]: grub2-tools-minimal.x86_64 1:2.02-58.fc29 Sep 30 10:02:28 vfr dnf[831]: shim-x64.x86_64 15-5 And now: garry@vfr$ rpm -q grub2-common grub2-efi-x64 grub2-pc grub2-pc-modules grub2-tools grub2-tools-efi grub2-tools-extra grub2-tools-minimal shim-x64 grub2-common-2.02-62.fc29.noarch grub2-efi-x64-2.02-62.fc29.x86_64 grub2-pc-2.02-62.fc29.x86_64 grub2-pc-modules-2.02-62.fc29.noarch grub2-tools-2.02-62.fc29.x86_64 grub2-tools-efi-2.02-62.fc29.x86_64 grub2-tools-extra-2.02-62.fc29.x86_64 grub2-tools-minimal-2.02-62.fc29.x86_64 shim-x64-15-7.x86_64 garry@vfr$ -- Garry T. Williams ___ 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: Cannot Boot After Doing system-upgrade
On Saturday, October 13, 2018 5:42:15 PM EDT Chris Murphy wrote: > On Sat, Oct 13, 2018 at 1:30 PM, Garry T. Williams > wrote: > > On Saturday, October 13, 2018 3:12:44 PM EDT Samuel Sieb wrote: > >> On 10/13/18 10:39 AM, Garry T. Williams wrote: > >> > >> > What am I doing wrong here that I cannot boot after a > >> > system-upgrade? > >> > >> "Doesn't boot" is no information. What exactly is happening? > > > > Sorry, the boot record is gone. > > You determined this how? The machine did not boot the Fedora OS. Instead, it booted the OS on /dev/sda. Of course, I attempted to boot from the Fedora disk by using the boot device configuration screen by hitting F12 during reboot. This failed. (A photograph of the error would have been a good idea.) I assumed that the reason was the boot record was missing. > >I happen to have another system on > > > > the same machine and that system boots instead of the Fedora > > system before my recovery actions. When I forced a boot from > > the fedora system using the machine's boot selection screen, it > > fails. (No diagnostic information in the BIOS setup screen -- > > just won't boot. I was forced to specify the USB Live system to > > start a recovery.) > > Screen shots or cell photo of the failure might be useful because > failure/won't boot doesn't tell us what is happening. And what is > happening is a hint as to what the source of the problem is, how to > prevent it, and how to fix it. But "won't boot" is not much to go > on. Understood. > Is this BIOS or UEFI? From any other Linux, what do you get for > 'parted -l u s p' or "fdisk -l" ? And what do you get for > 'efibootmgr -v' ? This is useful. I will try to document these results when I upgrade to F30, if the same happens again. The fdisk -l did show what I expected it to show: Disk /dev/sda: 477 GiB, 512110190592 bytes, 1000215216 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 4B21E327-DFE8-4105-AA9B-FEFF8AE8439F Device StartEnd Sectors Size Type /dev/sda1 20481026047 1024000 500M EFI System /dev/sda210260487317503 6291456 3G Microsoft basic data /dev/sda37317504 933572607 926255104 441.7G Linux filesystem /dev/sda4 933572608 1000214527 66641920 31.8G Linux swap Disk /dev/sdb: 477 GiB, 512110190592 bytes, 1000215216 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 9114D615-2FD0-4CF1-A601-DAD4507F6254 Device StartEnd Sectors Size Type /dev/sdb1 2048 411647409600 200M EFI System /dev/sdb2 4116482508799 2097152 1G Linux filesystem /dev/sdb3 2508800 1000214527 997705728 475.8G Linux LVM Admittedly, this is output from the now-recovered system, but I can attest that the same was displayed when the command was done using the Ubuntu system that loaded from /dev/sda. > > The system-upgrade somehow wiped out my boot record on /dev/sdb. > > "boot record" is a BIOS term, so this could mean the code on LBA 0 > or in the MBR gap or BIOS Boot partition has been stepped on; but > dnf system upgrade doesn't have such an ability. In fact it's a bit > of a security and bug endurance problem that 'grub2-install' isn't > run on BIOS upgrades. Whereas on UEFI the bootloader binaries on > the EFI System partition are replaced during updates, so what > you're describing might be a GRUB bug. OK, the system was able to boot from /dev/sdb only after I reinstalled grub2-efi and shim. I assumed that was what restored the boot record (or whatever it's called). (I was able to boot normally from Fedora immediately before doing the dnf system-upgrade. A reinstall was not accepted by dnf, so I used update instead.) > But the details you're giving only lead to speculation so you need > to provide specifics, just won't boot is identical to what happens > to a computer without a drive at all. Well, I will not be so fast to restore, if it occurs again (f30). Thank you for your suggestions. I am sorry for the assumptions I made. For what it's worth now: garry@vfr$ efibootmgr -v BootCurrent: 0002 Timeout: 1 seconds BootOrder: 0002,,0003,0004,0005,0006,0007,0008,0009 Boot ubuntuHD(1,GPT,3252a9ab-23eb-4fd4-9d11-6dc13c6f50ec, 0x800,0xfa000)/File(\EFI\ubuntu\shimx64.efi) Boot0002* FedoraHD(1,GPT,0534ef43-afb9-409c-8dc8-a1eff1e396ef, 0x800,0x64000)/File(\EFI\fedora\shim.efi) Boot0003* UEFI: SanDisk Extreme 0001PciRoot(0x0)/Pci(0x14,0x0)/ USB(17,0)/HD(1,MBR,0x3cb5dbe1,0x16960,0x
Re: Cannot Boot After Doing system-upgrade
On Saturday, October 13, 2018 3:12:44 PM EDT Samuel Sieb wrote: > On 10/13/18 10:39 AM, Garry T. Williams wrote: > > What am I doing wrong here that I cannot boot after a system-upgrade? > > "Doesn't boot" is no information. What exactly is happening? Sorry, the boot record is gone. I happen to have another system on the same machine and that system boots instead of the Fedora system before my recovery actions. When I forced a boot from the fedora system using the machine's boot selection screen, it fails. (No diagnostic information in the BIOS setup screen -- just won't boot. I was forced to specify the USB Live system to start a recovery.) The system-upgrade somehow wiped out my boot record on /dev/sdb. -- Garry T. Williams ___ 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
Cannot Boot After Doing system-upgrade
I recently did this on an up-to-date F28 system: $ sudo dnf system-upgrade download --refresh \ --releasever=29 --allowerasing --best $ sudo dnf system-upgrade reboot Now system will not boot. I had to boot from a live usb stick and do: $ sudo su - # vgdisplay # vgchange -ay fedora # mount /dev/fedora/root /mnt # mount /dev/sdb2 /mnt/boot # mount /dev/sdb1 /mnt/boot/efi # mount --bind /proc /mnt/proc # mount --bind /tmp /mnt/tmp # chroot /mnt # dnf --disablerepo=updates-testing upgrade grub2-efi shim None of this was obvious to me at first. I got here only after a lot of searching the Web for answers. It seems that grub2-install won't work on my setup, even after disabling secure boot on this machine. What am I doing wrong here that I cannot boot after a system-upgrade? $ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 7.8G 0 7.8G 0% /dev tmpfs7.8G 91M 7.7G 2% /dev/shm tmpfs7.8G 1.2M 7.8G 1% /run tmpfs7.8G 0 7.8G 0% /sys/fs/cgroup /dev/mapper/fedora-root 50G 11G 36G 24% / tmpfs7.8G 64K 7.8G 1% /tmp /dev/sdb2976M 287M 623M 32% /boot /dev/sdb1200M 7.9M 192M 4% /boot/efi /dev/mapper/fedora-home 412G 12G 379G 3% /home tmpfs1.6G 44K 1.6G 1% /run/user/1000 -- Garry T. Williams ___ 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: Update of apcupsd
On 2-11-14 17:57:01 Lawrence E Graves wrote: I have tried to install apcupsd 3.14.10-14* and it says the network is busy. Does anyone have a explanation for this. Your question is ambiguous. it says? Anyway, I decided to try an upgrade to this version myself and the restart of the daemon failed with SELinux is preventing /usr/sbin/apcupsd from create access on the file LCK... immediately after the upgrade was done. This looks like a serial port lock file. I have no idea why the daemon messes with that since my APC unit is USB. A downgrade to the -13 version restored normal operation. I gave negative karma[*]. It's usually best to copy and paste error messages. _ [*] https://bugzilla.redhat.com/show_bug.cgi?id=1064099 -- Garry T. Williams -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: top using full cpu core session/process management weirdness
On Tuesday, August 02, 2011 10:12:54 Dennis Jacobfeuerborn wrote: Hi, I just stumbled over a strange phenomenon that makes top go bananas. To reproduce open one shell window (and only one), switch to root and run top. Now close the shell window (without quitting top first). top will now suddenly start to use 100% of one cpu core. I can't reproduce this. I suspect that because I'm using KDE and konsole. $ konsole --version Qt: 4.7.3 KDE Development Platform: 4.6.5 (4.6.5) Konsole: 2.6.4 $ -- Garry Williams -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: DVD F14 - F15 Problems
On Sunday, May 29, 2011 13:44:56 Garry T. Williams wrote: I think the rpm database gets into a state that needs attention. This fixed it: sudo rm -f /var/lib/rpm/__db.001 /var/lib/rpm/__db.002 \ /var/lib/rpm/__db.003 /var/lib/rpm/__db.004 sudo rpm --rebuilddb After that, yum operations sped up an order of magnitude. This is not a problem with rpm. The work-around above seemed to have fixed the poor performance, but it was back again after any update. The system was grinding away on lots of I/O. Upon further investigation, I think this was a btrfs bug. The problem does not reproduce since I updated to kernel-2.6.38.7-30.fc15.x86_64 from updates-testing. -- Garry Williams -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: DVD F14 - F15 Problems
On Monday, May 30, 2011 06:44:39 He Rui wrote: On Sun, 2011-05-29 at 13:44 -0400, Garry T. Williams wrote: I upgraded to F15 from F14 using the DVD yeterday. I experienced a few glitches: 3. The first boot ended at multiuser.target instead of graphical.target. I don't know why this happened with the DVD upgrade and not with the preupgrade upgrade. Was your default init level on Fedora-14 3? No. It was 5 on both systems. Then if you changed the default runlevel by modifying the file /etc/inittab, those changes wouldn't affect the configured systemd default target. No, I never touched inittab on either system. The DVD upgrade just installed with multiuser.target as the default for some reason. Although strange, it was no problem correcting it. -- Garry Williams -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
DVD F14 - F15 Problems
I upgraded to F15 from F14 using the DVD yeterday. I experienced a few glitches: 1. I was not asked to include the updates repository during the update process. Sad. Now I will have to do an update after first boot. 2. This is apparently a general problem not really related to the specific upgrade. I noticed that the upgrade process was slow. The disk just churned forever. After booting for the first time, I ran yum erase on my debuginfos so that the subsequent yum update would not pull those in. This erase command took way too long. I think the rpm database gets into a state that needs attention. This fixed it: sudo rm -f /var/lib/rpm/__db.001 /var/lib/rpm/__db.002 \ /var/lib/rpm/__db.003 /var/lib/rpm/__db.004 sudo rpm --rebuilddb After that, yum operations sped up an order of magnitude. 3. The first boot ended at multiuser.target instead of graphical.target. When I entered the command sudo systemctl isolate graphical.target kdm came up and allowed a normal desktop login. Hmmm. I compared another system that I upgraded using preupgrade and that one had the correct graphical.target file linked in /etc/systemd/system . So I had to do this to correct the problem: sudo rm /etc/systemd/system/default.target sudo ln -s /lib/systemd/system/runlevel5.target \ /etc/systemd/system/default.target I don't know why this happened with the DVD upgrade and not with the preupgrade upgrade. 4. I then did a yum update and waited a few hours while over 500 packages were downloaded and updated/installed. This was almost 1GB of downloads. Most packages did not have delta rpms. 5. I run KDE and after logging in and starting Kmail, it refused to start, complaining about akonadi not being available: Test 5: ERROR ... InnoDB: Unable to lock ./ibdata1, error: 11 InnoDB: Check that you do not already have another mysqld process InnoDB: using the same InnoDB data or log files. repeated many times Test 10: ERROR ... Akonadi control process not registered at D-Bus. Test 15: ERROR ... No resource agents found. (Wow, this is a fragile piece in kdepim.) The fix for this ended up being: sudo yum --enablerepo=kde-testing update Now the system is operating as expected and all looks good. I'd be happy to open any bugs any of you think should be reported, but I think others have already encountered most of this stuff. Thank you for another excellent Fedora release. -- Garry Williams -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: DVD F14 - F15 Problems
On Sunday, May 29, 2011 13:44:56 Garry T. Williams wrote: I upgraded to F15 from F14 using the DVD yeterday. I experienced a few glitches: 6. Oh, I forgot to mention that there was no operating system log after the upgrade. That one was fixed with this: sudo systemctl enable rsyslog.service -- Garry Williams -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
