Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1111722 - hang at main menu, restoring hardware time and probing storage
Summary: hang at main menu, restoring hardware time and probing storage
Status: CLOSED DUPLICATE of bug 1167959
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils
Version: 22
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Kamil Dudka
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2014-06-20 20:15 UTC by Chris Murphy
Modified: 2020-05-04 03:30 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-06-13 12:17:59 UTC
Type: Bug

Attachments (Terms of Use)
screenshot of hang (25.90 KB, image/png)
2014-06-20 20:15 UTC, Chris Murphy
no flags Details
storage.log (132.01 KB, text/plain)
2014-06-20 20:19 UTC, Chris Murphy
no flags Details
program.log (26.76 KB, text/plain)
2014-06-20 20:19 UTC, Chris Murphy
no flags Details
anaconda.log (6.69 KB, text/plain)
2014-06-20 20:19 UTC, Chris Murphy
no flags Details
ifcfg.log (2.73 KB, text/plain)
2014-06-20 20:19 UTC, Chris Murphy
no flags Details
journal (304.71 KB, text/plain)
2014-06-20 20:20 UTC, Chris Murphy
no flags Details
kernel messages with sysrq w and t (495.22 KB, text/plain)
2014-06-20 20:56 UTC, Chris Murphy
no flags Details
dmesg output (244.33 KB, text/plain)
2014-11-25 23:12 UTC, Robert Moskowitz
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1167959 0 unspecified CLOSED Anaconda on Server DVD put on the usb by livecd-iso-to-disk --efi hangs in hub due to "probing storage" 2022-05-16 11:32:56 UTC

Internal Links: 1167959

Description Chris Murphy 2014-06-20 20:15:45 UTC
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):

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.

Comment 1 Chris Murphy 2014-06-20 20:19:07 UTC
Created attachment 910884 [details]

Comment 2 Chris Murphy 2014-06-20 20:19:32 UTC
Created attachment 910885 [details]

Comment 3 Chris Murphy 2014-06-20 20:19:45 UTC
Created attachment 910886 [details]

Comment 4 Chris Murphy 2014-06-20 20:19:58 UTC
Created attachment 910887 [details]

Comment 5 Chris Murphy 2014-06-20 20:20:30 UTC
Created attachment 910888 [details]

journalctl -b -l -o short-monotonic

Comment 6 Chris Murphy 2014-06-20 20:53:50 UTC
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.

Comment 7 Chris Murphy 2014-06-20 20:56:15 UTC
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.

Comment 8 Martin Kolman 2014-06-23 07:37:06 UTC
This bug looks like it might be related to bug 1110322.

Comment 9 David Shea 2014-10-23 18:40:10 UTC
As in bug 1110322 the issue is that the "arch" command is never returning

Comment 10 Ondrej Vasik 2014-10-23 18:59:18 UTC
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.

Comment 11 Ondrej Vasik 2014-10-27 08:06:09 UTC
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/", R_OK) returning -1."

Having some reproducer outside the anaconda would be great...

Comment 12 Lukáš Czerner 2014-11-18 12:35:58 UTC
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/ 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).


Comment 13 Ondrej Vasik 2014-11-18 20:36:51 UTC
Is this still reproducible? In "duplicate bz" 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).

Comment 14 Robert Moskowitz 2014-11-25 23:12:33 UTC
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

Comment 15 Chris Murphy 2014-11-25 23:30:31 UTC
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?

Comment 16 Robert Moskowitz 2014-11-25 23:44:46 UTC
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.

Comment 17 Chris Murphy 2014-11-26 01:07:36 UTC
NVRAM isn't polled pre-install, that only happens post-install. Plus, I'm not seeing anything related to efivars in this dmesg.

Comment 18 Robert Moskowitz 2014-11-26 15:27:12 UTC
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.

Comment 19 Chris Murphy 2014-11-27 06:05:36 UTC
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.

Comment 20 Jaroslav Reznik 2015-03-03 16:03:08 UTC
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:

Comment 21 Fedora Admin XMLRPC Client 2016-06-13 09:05:18 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 22 Kamil Dudka 2016-06-13 12:17:59 UTC
Likely duplicate of bug #1167959.  Feel free to reopen if still reproducible.

*** This bug has been marked as a duplicate of bug 1167959 ***

Comment 23 Zachary Smith 2020-05-04 03:30:29 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.