Re: Cannot Boot After Doing system-upgrade
On Sat, 2018-10-13 at 17:34 -0600, Chris Murphy wrote: > On Sat, Oct 13, 2018 at 5:01 PM, Garry T. Williams < > gtwilli...@gmail.com> wrote: > > By the way, from the journal during the dnf system-upgrade reboot: > > > > ... > > Sep 30 10:02:28 vfr dnf[831]: shim-x64.x86_64 15-5 > > > > And now: > > ... > > shim-x64-15-7.x86_64 > > > > Good catch. It's vaguely possible there's a bug in either shim 15-5 There is a known bug in shim 15-5 which caused the same symptoms on my machine. Adam Williamson explains what went wrong in this comment: https://bugzilla.redhat.com/show_bug.cgi?id=1631989#c6 Jon ___ 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 Sat, Oct 13, 2018 at 5:57 PM, Garry T. Williams wrote: > 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'd expect any failure (due to bug or general disagreement between firmware and shim and grub) to result in the firmware using the next boot entry in BootOrder. This fallback behavior is in the UEFI specification for all firmware to follow and supposedly behave consistently, it's not something you're doing. -- Chris Murphy ___ 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
On Sat, Oct 13, 2018 at 5:01 PM, Garry T. Williams wrote: > 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$ 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. One way to find out, that probably isn't worth it, is to manually downgrade to those versions, separately, to see which one (if any) restores the problem. But, it's fixed so I probably wouldn't test it as those versions have been superseded now. -- Chris Murphy ___ 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 Sat, Oct 13, 2018 at 4:44 PM, Garry T. Williams wrote: > 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. That is not evidence the boot record is gone. If this is a UEFI system, it's suggestive that an NVRAM variable has been altered, such as BootOrder, or an entry removed. But NVRAM modification are also something that dnf system upgrade cannot do. > > 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). On UEFI there's NVRAM which contains boot entries that point to bootloader location by device, partition, and path. But yeah you're right, autopsy is difficult now that the system is working again. In any case, there's no single thing that really qualifies as boot record on UEFI. > 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) Entry 0002 is stale; shim.efi is still valid for Fedora 29 but new installations refer to shimx64.efi the same as the entry for Ubuntu. Thing is, dnf system upgrade doesn't change NVRAM menu entries. Anyway, it may be unrelated. It's just a data point for now. But everything you provided looks sane, which is probably why it's booting, and evidence of the unworking state isn't available so we can only guess what happened. - BootOrder shouldn't be changed by anything dnf system upgrade does - Deleting boot entries from NVRAM should be anything dnf system upgrade does - dnf system upgrade should have replaced pretty much all the binary files on the /dev/sdb EFI System partition, same as you reinstalling shim and grub2-efi I suspect a detail is missing that seems innocuous and unintuitive as to it's relationship to the failure; but is actually related. For example, on my HP with Windows 10 and Fedora 29: [chris@flap ~]$ sudo efibootmgr -v [sudo] password for chris: BootCurrent: Timeout: 0 seconds BootOrder: ,3000,0002,2001,2002,2004 Boot* Fedora HD(2,GPT,0273e9d0-2c96-49fc-a046-b67914664deb,0xfa000,0x32000)/File(\EFI\fedora\shimx64.efi) Boot0002* Windows Boot Manager HD(2,GPT,0273e9d0-2c96-49fc-a046-b67914664deb,0xfa000,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...r Boot2001* EFI USB DeviceRC Boot3000* Internal Hard Disk or Solid State DiskRC Boot3002* Internal Hard Disk or Solid State DiskRC [chris@flap ~]$ Fedora should boot first. However, if I enter firmware setup and close, whether I change anything or not? It always boots Windows by default from then on. The BootOrder variable is changed, just by virtue of entering firmware setup (not the firmware's boot manager). That's fakaked! However, I have to change BootOrder with efibootmgr, reinstalling shim and grub2-efi doesn't fix it, because installing those packages doesn't change EFI NVRAM variables. -- Chris Murphy ___ 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,0x2990)..BO Boot0004* Diskette DriveBBS(Floppy,Diskette Drive,0x0)..BO Boot0005* P0: SK hynix SC300 SATA 512GB BBS(HD,P0: SK hynix SC300 SATA 512GB ,0x0)..BO Boot0006* P2: INTEL SSDSC2KF512H6 SATA 5BBS(HD,P2: INTEL SSDSC2KF512H6
Fedora 29-20181013.n.0 compose check report
No missing expected images. Failed openQA tests: 6/133 (x86_64), 1/2 (arm) ID: 295158 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/295158 ID: 295179 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/295179 ID: 295180 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/295180 ID: 295192 Test: x86_64 KDE-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/295192 ID: 295196 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/295196 ID: 295200 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/295200 ID: 295257 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/295257 Soft failed openQA tests: 3/133 (x86_64), 2/24 (i386) (Tests completed, but using a workaround for a known bug) ID: 295162 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/295162 ID: 295163 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/295163 ID: 295218 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/295218 ID: 295246 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/295246 ID: 295271 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/295271 Passed openQA tests: 124/133 (x86_64), 22/24 (i386) Skipped openQA tests: 1 of 159 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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 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? >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. 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' ? > > 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. 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. -- Chris Murphy ___ 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 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
Fedora 29 compose report: 20181013.n.0 changes
OLD: Fedora-29-20181012.n.0 NEW: Fedora-29-20181013.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 3 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 40.39 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 51.95 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: krb5-1.16.1-21.fc29 Old package: krb5-1.16.1-20.fc29 Summary: The Kerberos network authentication system RPMs: krb5-devel krb5-libs krb5-pkinit krb5-server krb5-server-ldap krb5-workstation libkadm5 Size: 18.42 MiB Size change: 4.84 KiB Changelog: * Tue Oct 09 2018 Adam Williamson - 1.16.1-21 - Revert the patch from -20 for now as it seems to make FreeIPA worse Package: nautilus-3.30.2-1.fc29 Old package: nautilus-3.30.1-1.fc29 Summary: File manager for GNOME RPMs: nautilus nautilus-devel nautilus-extensions Size: 16.16 MiB Size change: 24.49 KiB Changelog: * Fri Oct 12 2018 Kalev Lember - 3.30.2-1 - Update to 3.30.2 Package: plymouth-0.9.3-14.fc29 Old package: plymouth-0.9.3-13.fc29 Summary: Graphical Boot Animation and Logger RPMs: plymouth plymouth-core-libs plymouth-devel plymouth-graphics-libs plymouth-plugin-fade-throbber plymouth-plugin-label plymouth-plugin-script plymouth-plugin-space-flares plymouth-plugin-throbgress plymouth-plugin-two-step plymouth-scripts plymouth-system-theme plymouth-theme-charge plymouth-theme-fade-in plymouth-theme-script plymouth-theme-solar plymouth-theme-spinfinity plymouth-theme-spinner Size: 5.81 MiB Size change: 22.62 KiB Changelog: * Thu Oct 04 2018 Hans de Goede - 0.9.3-14 - Add patches from upstream to fix the disk unlock screen sometimes having a very low resolution on UEFI machines: https://gitlab.freedesktop.org/plymouth/plymouth/issues/68 = DOWNGRADED PACKAGES = ___ 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 10/13/18 10:39 AM, Garry T. Williams wrote: 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. Some more details on what the problem is would help. 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. grub2-install is only for non-EFI systems and shouldn't be used otherwise. Nothing to do with secure boot. What am I doing wrong here that I cannot boot after a system-upgrade? "Doesn't boot" is no information. What exactly is happening? ___ 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
Self Introduction: Paul Borchardt
Hi, I am very interested in helping where I can. My interests are mainly in programming and debugging but I'm not so bad at testing either. My experience with Fedora is limited I must admit but my background it pretty extensive in the unix world. I learned the C language in 1986. I began my programming career in the aircraft repair industry. I created numerous database applications as well as many system utilities to facilitate data transfer to the database from different devices. I have been out of the field for quite sometime and use linux to help me re-aquait myself with the commands and how the system works. I've been a real distro hopper but I'd like to settle down and do something useful again. I have very strong abilities in toubleshooting but I'm not sure you have a place for that in this area. I have installed Fedora both in a virtual box and also on one of my drives. I'm in it now as a matter of fact. I also have Windows 10 and Linux Mint 19 installed. I have 3 drives. Two are SSD's which have windows and mint and a third mechanical drive which I now have Fedora. The desktop I'm most used to thanks to Mint is Cinnamon but I am able to use KDE and xfce as well as MATE. Unfortunately I don't like GNOME for a desktop and won't use it. If all is stable with this install I will replace LM with Fedora as my main Linux OS and will have this drive for testing or whatever is needed. As to IRC, I've never really used it and don't have a name yet but am certainly willing to figure it out. I used ICQ for years but haven't in years also. Didn't even know if it's still around. Thanks for hopefully letting me use some of my skills to help make Fedora better. Paul Borchardt ___ 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