On Fri, 15 Jul 2022 14:41:09 -0400 Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: Caveat: Running rawhide since it was F35 > The Fedora Workstation working group is curious if there's any pattern > or categorization how Fedora installations typically break. i.e. the > installation is successful, the system has been updated multiple times > successfully, and then for whatever reason it breaks. I don't use Workstation, though I have it installed, so I'm not sure how meaningful my answers will be. > > Are most failures hardware related? This could be broken down into > hard failure (drive or logic board failed) and soft failure (some > hardware configuration change and reverting the change resolves the > problem). The last failure I had was a power supply. Very rare. > > What portion of the failures are early boot failures? (Defined as > bootloader, kernel, or early initramfs failures. But excludes being > landed at a dracut prompt.) Don't have these, but I use custom compiled kernels tuned to my hardware. Spoke too soon, just compiled the latest 5.19 rc6 kernel, and it doesn't boot, hangs. Previous rc4 boots and runs normally. The only difference in the configuration is a new automatic timing remediation that they had default Y, and I turned off. I'll be mentioning this on the kernel list. > > What portion of the failures land the user at a dracut shell? Only when install fail. I usually use the small netinstall image to do fresh minimal installs, and once they boot, do the rest of the install. The failures are in the fresh install, not the rest. > > What portion of the failures does the user get to a graphical shell > but can't login? NA I always boot to runlevel 3, and start X from there. > > What portion of the failures can the user login but there's some sort > of anomalous behavior? NA > What portion of all failures are fixable without reinstalling? NA > Is the GRUB "rescue" menu entry ever useful in resolving problems? It has helped me precisely once. I cloned an existing fedora install to a new partition, but for new hardware. It would not boot until I used the rescue image, because it needed drivers that weren't available on the cloned image. I do keep it up to date by deleting the rescue kernel and initramfs, and then running /usr/lib/kernel/install.d/51-dracut-rescue.install add $(uname -r) "" /lib/modules/$(uname -r)/vmlinuz in the /boot directory. > Could everyone reading this try booting the "rescue" menu entry and > describe what happens? How does the actual behavior compare to what > you thought would happen? I tried booting the rescue entry described above, and it failed. It looked like it was going to start, then the drive clunked, and the system hung. I checked permissions and mode, it was 700 vs 755 for regular kernels and unconfined vs system_u for regular kernels. Still had the issue on a reboot. The one I successfully use before used a different command to generate, since it was years ago. > The questions list is not complete, feel free to add your own > categorizations / failure patterns that you tend to see. By far the most common error for me is packaging conflicts. New packages will be blocked because packages that depend on their old version are installed, and not being updated. Right now there are thousands of packages in rawhide affected by this. I'm not investigating because I see from the chatter that there are some issues being worked on. The other problem is that packages get orphaned, and bit rot sets in, causing issues with older packages that are no longer supported, but are installed. The above two paragraph aren't a criticism of package maintainers, rather the package system. I think the build system should have automatic checks to determine that all dependent packages are being rebuilt as part of a package build. Can that be done automatically? Look at the binary to determine what it uses? I'm not sure how difficult that would be, but that's what computers are for, to remove repetitive, routine work that is error prone. A couple of databases, every package has all of its dependencies in one, and every package has all of the packages it depends on in another. These are redundant, but it makes lookup simpler. A program runs periodically and updates them to the current situation. _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
