Created attachment 910883 [details] screenshot of hang Description of problem: At the main hub I get an unrecoverable hang of the installer. Date & Time says Restoring hardware time, and Installation Destination shows probing storage... Version-Release number of selected component (if applicable): anaconda-21.24-1.fc21.x86_64 Fedora-Live-Workstation-x86_64-rawhide-20140619.iso How reproducible: Always with this particular pre-existing configuration. Steps to Reproduce: 1. Install Fedora 20 using Btrfs preset with custom install to leave free space. 2. Boot Fedora 21 installer Fedora-Live-Workstation-x86_64-rawhide-20140619.iso 3. Choose English as language. Actual results: Hang at the hub. Expected results: No hang. Additional info: This is on UEFI in VirtualBox, previous Fedora 20 is a default (preset) Btrfs installation.
Created attachment 910884 [details] storage.log
Created attachment 910885 [details] program.log
Created attachment 910886 [details] anaconda.log
Created attachment 910887 [details] ifcfg.log
Created attachment 910888 [details] journal journalctl -b -l -o short-monotonic
Not reproducible with Fedora-Live-KDE-x86_64-rawhide-20140523.iso yum updated to anaconda-21.43-1 and python-blivet-0.57-1. Does happen still with Fedora-Live-Workstation-x86_64-rawhide-20140619.iso with yum update anaconda-21.43-1 and python-blivet-0.57-1. Must be something different in the environment? I'll get a dmesg with sysrq w and t.
Created attachment 910897 [details] kernel messages with sysrq w and t There is a Btrfs lock bug in 3.16rc1, but I'm not seeing kernel messages that indicate that's what's going on. The system is completely responsive, it's only anaconda that's hung... BUT it's hung probing storage, and the existing Fedora 20 install is a Btrfs install. Maybe just wait for 3.16rc2 and see if this reproduces.
This bug looks like it might be related to bug 1110322.
As in bug 1110322 the issue is that the "arch" command is never returning
Adding Lukas Czerner to CC so he can comment on it from btrfs point of view. As in the previous one, reproducer without anaconda would be great.
Lukas, can you please suggest how we can get more debug information about this (likely btrfs) issue? Adding comment from Vrata Podzimek from the above mentioned bugzilla about his investigation: "Vratislav Podzimek 2014-06-18 09:31:01 EDT The issue is that Anaconda tries to determine the architecture of the installed RHEL 7 system by running the 'arch' utility in the /mnt/sysimage chroot (the installed RHEL 7 system root). However, that hangs which hangs the whole Anaconda's storage-probing thread. Further investigation reveals that 'chroot /mnt/sysimage' doesn't work at all. Running 'strace chroot /mnt/sysimage' ends with access("/etc/ld.so.preload", R_OK) returning -1." Having some reproducer outside the anaconda would be great...
It seems that the anaconda is the one that is stuck right ? We can not know whether it's a kernel issue or not unless we know where is it stuck. What is it doing when getting stuck, what system call is stuck if any ? I can see that chroot fails, because read access to /etc/ld.so.preload fails. This is not a reason to get stuck is it ? I have no idea why it fails (access privileges? selinux ?), more investigation on anaconda part needs to be done before we can blame kernel (note that there no no kernel/btrfs related error mentioned anywhere in this bz). -Lukas
Is this still reproducible? In "duplicate bz" https://bugzilla.redhat.com/show_bug.cgi?id=1110322 it was mentioned that the issue didn't occur with older kernel/glibc . I'm afraid we will not get further without some reproducer outside the anaconda (or debugging from anaconda team).
Created attachment 961414 [details] dmesg output From shell per Chris's instructions echo 1 >/proc/sys/kernel/sysrq echo w > /proc/sysrq-trigger echo t > /proc/sysrq-trigger dmesg > dmesg.txt
I'm also not seeing anything obviously Btfs related in the new dmesg attached; but I do see AVC denials, but they don't seem to be a reason for the hang. Robert, is the previous system you're attempting to install over contain any Btrfs volumes?
No. No btrfs volumes. / and /home are both ext4. If you want, I can boot it up and do a parted .... print to show, or whatever else you want on the drive. This is a duplicate of the F20 system I am running right now where you had to help me get past the nvram failure last year. So this time F21 produced a warning and with an OK went on with the install, but I suspect the nvram is wrong and that could be the source of the hang.
NVRAM isn't polled pre-install, that only happens post-install. Plus, I'm not seeing anything related to efivars in this dmesg.
Here is the history of this system and its current state: The system is a Lenovo x120e with an 240Gb SSD. The system was purchased from ebay and I pulled the Win7 HDD to install the new SSD drive; this was back in May '14 and I tried the F20 x86_64 install whiched failed with bug 1006304. The install got far enough to set up the EXT4 partitions I normally use before the nvram failure; this is the same partitioning you will see below. The system has sat unused until yesterday when I did a F21-TC4 x86_64 netinst. The install was successful; I had selected the Xfce workstation option; the system boots up fine. During the install, I had manually deleted the F20 partitions and did a 'standard' partitioning to get the EXT4 option. I shrunk /, expanded swap, and had /home take all that was left. I have done this a couple times with F20 installs. Oh, the netinst was against a local repo I have here. During this install I got a message about a failure that I attribute to the nvram write problem; I did not write down the content of the dialog, nor do I see anything in any logs on the system that would point to this message. I seleted OK to continue install which it did, resulting in the bootable system. So I went to go through the installation again, to try out some repo and disk setup options discussed on the testing list. The hang occured when I tried to get into the installation. Given that the condition is that anaconda is stuck searching for the drives I shelled out and did: #parted /dev/sda print Model: ATA KINGSTON SV300S3 (scsi) Disk /dev/sda: 240GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 211MB 210MB fat16 EFI System Partition boot, esp 2 211MB 735MB 524MB ext4 3 735MB 32.9GB 32.2GB ext4 4 32.9GB 41.7GB 8791MB linux-swap(v1) 5 41.7GB 240GB 198GB ext4 So shell is seeing the partitions. Further a mount /dev/sda3 /mnt allows me to see the content of the / partition. And I can access files with no problem.
Roberts dmesg with sysrqw suggests dosfsck may be hung, so his may be this other bug recently reported 1167959. Mine doesn't seem to have hung on dosfsck as it's not running in my case.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Likely duplicate of bug #1167959. Feel free to reopen if still reproducible. *** This bug has been marked as a duplicate of bug 1167959 ***
I just encountered this problem installing Fedora 32. I have a HD with Btrfs and an empty drive that I intend to install Fedora 32 on. Anaconda hangs on "Probing storage...". I deleted the disk with Btrfs with "echo 1 > /sys/block/sda/device/delete", restarted Anaconda, and installation continued with no issues.