Kickstart loooonnnggg delay "Probing storage..."

Latest response

I have several kickstarts for various server roles. One has started giving me very long (like ten minutes!) delay on the "Installation Summary" screen. "Installation Source" has a yellow exclamation and "Probing storage..." and "Software Selection has a yellow exclamation and "Downloading package metadata" After a long time, it moves forward. I'm not seeing anything in the logs, either in / or /mnt/sysimage After it gets going again, all is well.

I've looked at this kickstart and a working one side-by-side, and I'm just not seeing anything. Everything about storage and package sources is identical. %packages and %post are different, as it network config, but I can't see how that could explain this.

I can't post the kickstarts as the network in question is not connected to the Internet. Looking for any ideas about other logs to check, experiments to try, etc.

Responses

Does the system you're having problems with have a large and/or complicated storage configuration?

What kind of storage controllers does it have?

Does it have lots of disks/LUNs?

How does the lsscsi/lsblk listing look like on that system, vs. a problem-free system?

Perhaps a SAN configuration error that causes some LUNs/paths to be presented but to not actually work?

Or some storage device that is detected as existing, but has failed disk(s) or is otherwise not responding properly?

If there are NICs with hardware-level iSCSI/FCoE support, those might have some obsolete configuration items at the hardware/BIOS level, which might cause them to attempt connect to some now-unreachable device when probed for installation.

None of the above. It's a simple VM with one attached virtual disk. And, another kickstart runs just fine on the same machine. I think it's just showing "Probing storage" but is actually stuck on something else.

John,

go to the other screens within anaconda (ctrl-alt-f2, f3 f4) and examine the logs under /tmp/ while the system is in it's hung state.

Look to see if you have a URL for a specific repo that's not available.

Examine the storage to see if the storage is over-committing total size, and use "--grow" directives and a smaller allocation (size=100 --grow) which would consume the remainder of the disk. I've had kickstarts fail due to over-committing total storage of all LVM logical volumes, and then after scrutiny, and adjustment with the directives earlier in this paragraph, it resolved it.

Post back with how this goes.

One of my longstanding issues is that I can't switch between virtual consoles... I'm dealing with virtual machines running on VMware and am accessing the console via the web UI on Firefox on a Red Hat laptop... every attempt to change the virtual console on the VM actually changes it on my host. VMware says Ctrl-Alt-Space then Fx, but that doesn't work, and nobody aat VMware or in their forum has ever even tried to come up with a working combo.

That said, I can ssh into the systems... adding 'inst.sshd' lets you ssh in even before the installer does anything! So I can review logs (which don't say a thing), and the virtual hardware works perfectly well with another kickstart that's effectively the same. Right now, I'm not doing any goofy partitioning... 'clearpart --all', 'zerombr', 'autopart --type=lvm' is it. I'm not trying to preserve anything, there is no FC / FCoE / iSCSI, no LUNs, no HBAs, just a plain-Jane VMware SCSI controller and one disk that's more than big enough :-)

One of my longstanding issues is that I can't switch between virtual consoles... I'm dealing with virtual machines running on VMware and am accessing the console via the web UI on Firefox on a Red Hat laptop... every attempt to change the virtual console on the VM actually changes it on my host. VMware says Ctrl-Alt-Space then Fx, but that doesn't work, and nobody aat VMware or in their forum has ever even tried to come up with a working combo.

That said, I can ssh into the systems... adding 'inst.sshd' lets you ssh in even before the installer does anything! So I can review logs (which don't say a thing), and the virtual hardware works perfectly well with another kickstart that's effectively the same. Right now, I'm not doing any goofy partitioning... 'clearpart --all', 'zerombr', 'autopart --type=lvm' is it. I'm not trying to preserve anything, there is no FC / FCoE / iSCSI, no LUNs, no HBAs, just a plain-Jane VMware SCSI controller and one disk that's more than big enough :-)

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.