Help migrating from CentOS 7.3.1611, Dracut-initqueue timeout on installation or live boot

I’m hoping someone can offer some advice on this please — the problem isn’t limited to Rockly Linux as the below explains. I note that in various forums for CentOS, Rocky and Alma Linux, folks are reporting the same problem that I have, but as far as I can find, no solution is given. I’ve been running CentOS 7.3.1611 for a long time on the below hardware, without problems. I have now started installing Rocky 8.8 on a new disc in the same server.

After beginning a full installation of 8.8 from DVD, or after booting a live DVD (such as Rocky-8.8-Workstation-Lite-x86_64-20230517.0.iso), the screen remains blank for 2 - 3 minutes and then displays a series of repeating messages, “localhost dracut-initqueue[539]: Warning: dracut-initqueue timeout - starting timeout scripts”.

This finally stops and I can view the system log. It’s difficult to see what has caused it, but I’ve copied the output partially, just prior to these warnings. Apologies for the quality of the captured images.

I have also tried Alma Linux 8 and 9 which exhibit the same problem, together with various later CentOS versions such as 8 and these also exhibit the same problem. CentOS 7.x is fine.

My hardware is as follows :

AMD Athlon™ II X2 245
Asrock G960GC main board
Radeon HD3000 on-board video
16GB RAM (8GB Kingston KVR1333D3N9/8G x 2)
2TB latest Seagate Ironwolf hard drive

If possible, I’d like to try and fix the problem before giving up and moving to another distro. I’ve already found that other non-CentOS distros are fine with this machine. It appears to be something upstream that happened after CentOS 7, but I don’t know how to go about solving this. I do not intend to replace my server because of this, as it would make more sense to just switch to another distro. Thanks for any advice on this.

EDIT: Just to correct the earlier claim, “I have also tried Alma Linux 8 and 9 which exhibit the same problem”. It seems my memory was fuzzy about that. This is the trouble with coming back to a job which was first carried out many days ago :blush: EL9 did not in fact give the same result. It failed with kernel crash, due to the fact that this processor does not support x86_64-v2

The second image (right section of the first image), again my apologies for the qualtity.

Did the actual installation process start? Or you didn’t get that far? Reason I ask, it seems your disks already have partitions on them, including LVM, and the error messages are complaining about various things with them.

Have you tried erasing the disks in the machine, so that you can try a clean install without it searching and finding existing partitions and LVM volume groups and volumes? Maybe that would help?

Also EL9 based distros are unlikely to work unless that CPU is x86_64-v2 - which based on it’s age it might not be.

Specs of AMD Athlon™ II X2 245 do clearly lack some x86_64-v2 features and first AMD CPU with all x86_64-v2 features is said to have been released in 2014. EL8 should be “fine” on the hardware though. (There would be no sight of LVM, if the SATA controller had no support.)

In other words, boot with el8 kernel fails (be it install media or other).

How is the Ironwolf “partitioned”?
lsblk -o name,size,type,fstype,mountpoint in CentOS should tell that.

The default would be two partitions, first with /boot and other a LVM PV that has LVs for
/, /home, and swap and whole disk allocated for these partitions/volumes.
Furthermore, default filesystem is XFS and one cannot shrink XFS volume.

One would have to boot with, for example, the CentOS 7 install media in order to erase. (I’d remove entries from partition table with fdisk and then write from /dev/zero to couple first megabytes with dd.)

If one wants to keep data, then one must have a backup first.

Presuming that the issue is with LVM detection, does the kernel have command-line parameter that would disable LVM detection on boot? The man dracut.cmdline says “yes”: rd.lvm=0

One can append that in bootloader, before the installer’s kernel boots.

Plan B could be to purchase a SSD drive, disconnect the HDD for the duration of the install, and install on SSD. There could still be the boot issue after HDD is reconnected (to act as data drive).

Thanks for the reply @iwalker , I would guess that the installation hasn’t started. The LVM partitions were those of CentOS 7.3. I have now disconnected the discs and booted with Rocky Live 8.8. It goes through roughly the same process as yesterday, blank screen and disc activity for a minute, followed by no disc activity for a couple of minutes, then finally the dracut timeouts.

It mentions at the end, ‘Warning: /dev/disk/by-label/Rocky-8-8-Workstation-Lite does not exist’, then on the next line…
‘Warning: /dev/root does not exist’

The contents of the log no longer include the LVM — shown below. Thanks for pointing out the x86_64-v2 requirement in EL9. It seems the processor supports SSE to SSE4A, but anyway if I can run on Rocky 8 for a while, that would be great.

Thanks for the reply @jlehtone , the subject of the existing CentOS installation is a distraction from this. When I first attempted to install Rocky 8.8, that disc was brand new and unused, therefore without any partitions. When I got into difficulty, I then ran for a few days on CentOS 7.3 on that new disc, now I’ve come back to this again, with that same disc.

I’ve just now put another brand new disc in the machine and it doesn’t show the LVM messages, but the boot process still fails.

A red herring. :woozy_face:

Devices are listed by many means:

$ ls /dev/disk/
by-diskseq  by-id  by-label  by-partlabel  by-partuuid  by-path  by-uuid

The by-label subdir exists only when some filesystems have label in them.

Sounds like the Rocky install media does not have label Rocky-8-8-Workstation-Lite
in it, but something (like /etc/fstab) refers to that LABEL.

How about the Live image, does it boot when you have no “herrings”?

Do the images boot on other machines?

1 Like

As @jlehtone said, I would try different ISO’s or make sure that when you downloaded them that the md5/sha sums match - it could be a corrupted download, or problem with that specific ISO. Try the standard DVD image, or minimal ISO would be good too since it’s small to download, and will give you a basic console install without graphical environment. If they can boot, then that would clarify that as a potential issue.

Many thanks @jlehtone All the tests I’m doing are with the Live image. Just now I have a new 3TB Seagate drive installed, no partitions yet, as it’s unused. The logs show the drive having been found and identified as ST3000 but otherwise the same timeout and the same messages at the end, with regard to ‘Rocky-8-8-Workstation-Lite’ etc.

From the emergency boot, now that I’ve tried this with a brand new 3TB disc, I can see that /dev/disk contains by-id, by-path and by-uuid, which corresponds with what you say, about by-label being present only if there is a filesystem.

I’ll try booting from another machine and report back. Bear in mind that I have tried several installations here, all with the same outcome, which are as follows.

Rocky 8.8 Live
Rocky 8.8 Install
Alma Linux 8.7 Live
Alma Linux 8.8 Live
Alma Linux 8.7 Install (KDE)
Alma Linux 8.7 Install (Gnome)
CentOS 8 (some weeks ago, so can’t recall the exact version, but newly downloaded at the time)

Commands blkid and lsblk -f do show detected labels, etc. (Whether they get data from /dev/disk or elsewhere, the format is more “humane”.)

Same issue with no disk on the system → issue is not about disks.

The images that you have, are they on DVDs (drive is a SATA device) or on USB?
(The latter could rule out SATA-controller related shortcomings.)

1 Like

They are all DVDs, simply because there are so many ISOs to try :slight_smile: Also has the advantage that they are easily labelled. I’ll create a USB and see how I get on with this. Please bear with me and thanks very much to both, for your helpful replies.

I’m pleased to say, we have success :slight_smile: Rocky 8.8 Live runs successfully from USB. The server has an IDE interface for the DVD drive, so it may be the cause of incompatibility with EL8 onwards.

I think this is probably why the following appears …

Warning: /dev/disk/by-label/Rocky-8-8-Workstation-Lite does not exist
Warning: /dev/root does not exist

Update : Rocky 9 does not run and generates a kernel panic early in the boot process, presumbly related to the absence of x86_64-v2 support. Though the Athlon II X2 245 suggests it supports SSE to SSE4A, it perhaps isn’t sufficient.

Again, thanks to you both for your replies, they’ve given me a better way forward with this server.


Good old PATA cable. Yes, IDE interface is separate device from SATA controller and might lack driver support even though SATA has driver. (The BIOS can load and run bootloader from it, and bootloader loads kernel, but kernel does not know how to read …)

You can run lspci -nn. It will show devices, with device ID (in brackets []). An example from Intel system:

00:1f.1 IDE interface [0101]: Intel Corporation 82801CA Ultra ATA Storage Controller [8086:248b] (rev 02)

That has device ID 8086:248b (8086 is Intel, this particular device is 248b). If kernel lacks support for device, then one does search with the device ID, whether some third party has driver (kernel module). ELRepo is the best source for drivers that RHEL chose not to support.

I hadn’t even noticed that the DVD was connected through an IDE interface until I happened to turn the machine towards the light, to see what I was doing.

I think historically, the IDE interface was retained for the DVD, in order to provide four SATA hard drives, which is the mainboard’s limit. I don’t think it really matters now, as the USB installation is better.

Incidentally, I just ran lspci via the current CentOS 7.3.

lspci -nn | grep IDE
00:14.1 IDE interface [0101]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 IDE Controller [1002:439c]

On CentOS 7 the driver is atiixp and that is not on later distros:

[el9]# modprobe -c | grep 1002.*439C
[el8]# modprobe -c | grep 1002.*439C
[el7]# modprobe -c | grep 1002.*439C
alias pci:v00001002d0000439Csv*sd*bc*sc*i* pata_atiixp
[el7]# modinfo pata_atiixp | grep -E "^version|description"
version:        0.4.6
description:    low-level driver for ATI IXP200/300/400

ELRepo has package kmod-pata_atiixp for both el8 and el9. It provides same version (0.4.6) of pata_atiixp.
(You get access to ELRepo with dnf install elrepo-release )

1 Like

Thanks @jlehtone this is very useful information. After I have completed this Rocky installation, I could I suppose install kmod-pata_atiixp and retain support for that IDE drive (not that it gets much use these days :wink: )

To get this right, I’d run dnf install elrepo-release followed likewise by kmod-pata_atiixp ?

Yes. the package elrepo-release provides the definition for ELRepo’s repository. That package is in Rocky’s extras repo, so readily available (just like epel-release).

Once installed, dnf sees additional repo elrepo and hence packages within. E.g. the kmod-pata_atiixp.
What it can see, it can install (unless something goes wrong).

The ELRepo has also some driver update disk (dud) images. One can specify such for the installer’s kernel with inst.dd=URL parameter, where the URL points to such image (provided that network is supported). The installer will load kernel module(s) from the image and also install the corresponding package. If network is not an option, then the image can be on additional USB drive.

I have used that feature to be able to install on system, where the disk (RAID) controller was not supported.

Thanks again @jlehtone — this is exactly the sort of detail that helps those of us who still have a lack of knowledge about updates and package installation. I’m a software developer who usually concentrates on application design, which often comes at a high cost of never getting to fully know the host environment we work within, simply because of the lack of time and the fact that Linux normally just works and keeps on working.

I’ve been running two CentOS servers and also another distro. on my laptop, for the past eight years. The first time I installed and used Linux was in 1998, with a copy of Red Hat CDs that came bundled with a book, entitled “Red Hat Linux”. I still have those CDs and the book, though they were damaged in one of the occasional floods we have here in Thailand. Times have changed of course, and now, despite its humble beginnings, Red Hat’s actions are regarded rather questionably.

I have promoted Linux commercially in Thailand and installed it countless times but despite this history, I wish I knew more. Thanks again for the help.

1 Like