Description of Problem: After adding a kickstart file to an ISO, burning that ISO to a USB flash drive, and booting from that flash drive, the installer will not find the local "Installation Source" on the USB flash drive unless the kickstart file has a minimum `network --activate` command in it. This is in opposition to the Kickstart documentation at https://docs.centos.org/en-US/8-docs/advanced-install/assembly_kickstart-commands-and-options-reference/#kickstart-commands-for-network-configuration_kickstart-commands-and-options-reference which says the `network` command is optional. Version Release number of selected component (if applicable): CentOS-8.3.2011-x86_64-dvd1.iso and whatever installer version is included in that ISO. How reproducable: Every time. Steps to reproduce: 1. Start with an existing kickstart file. Remove all external `repo` commands. Comment out the `network` command or set the command to `network --no-activate`. 2. Create a custom ISO with that kickstart included. 3. Boot from the resulting USB flash drive into the installer. 4. Note that the INSTALLATION SOURCE page of the INSTALLATION SUMMARY does not show an auto-detected local Installation Source. Actual Results: The installer fails to find the installation media on the USB flash drive. Expected results: If cdrom is specified in the kickstart file, the installer should find the installation media on the boot device in all cases, with no other dependencies. Additional info: For context, this process started when I got tired of the tedium of creating a custom filesystem layout for my systems. I'm fine with using the graphical installer to do installations; I just want to preload my preferred filesystem layout. And if I was going to use a kickstart file, I'll go to the effort to pre-configure the timezone, root password, create an admin user, etc. I didn't want to preconfigure the network settings because those would be different for each host. I just wanted to preconfigure the settings that would be common to every installation, and use the graphical installer for the system-specific items. Similarly, I didn't care about adding external repositories because the first thing I do once I have a system up and running is a `dnf update`, so I can watch the update go by. My working notes are at https://github.com/dafydd2277/systemAdmin/issues/1 You can find an ISO build automation script in https://github.com/dafydd2277/systemAdmin/kickstart/centos8 because I've been doing this over and over.
Created attachment 1771191 [details] The ks file where I first noticed the problem.
Created attachment 1771192 [details] The ks file where I started with a minimum command set and worked up.
I got a reply on the kickstart-list that caused me to try replicating the problem from the bottom up. That is, start with a minimum kickstart command set and see if I still saw the problem. I started with this command set. ``` cdrom graphical logging --level=info ``` I worked up to the attached `ks.cfg.bottomUp` and couldn't recreate the problem. So, my starting/failing kickstart file and the bottomUp kickstart file are attached, and I'm still trying to narrow the parameters of my problem.
Turns out the `network` command is covering for the `ignoredisk` command. My second attachment is `ks.cfg.bottomUp`. Here are some diffs. This failed. Note the `ignoredisk`. ``` [root@bravo ~]# diff ks.cfg.bottomUp ks.cfg 2d1 < #install # Deprecated 7d5 < logging --level=info 19a18,21 > # Partition clearing information > zerombr > ignoredisk --only-use=sda > clearpart --initlabel --drives=sda --all ``` This succeeds. Note the `ignoredisk` is commented. ``` [root@bravo ~]# diff ks.cfg.bottomUp ks.cfg 2d1 < #install # Deprecated 7d5 < logging --level=info 19a18,21 > # Partition clearing information > zerombr > #ignoredisk --only-use=sda > clearpart --initlabel --drives=sda --all ``` This succeeds with the `ignoredisk` uncommented and a `network` command added. ``` [root@bravo ~]# diff ks.cfg.bottomUp ks.cfg 2d1 < #install # Deprecated 7d5 < logging --level=info 14a13 > network --bootproto=dhcp --device=link --onboot=off --noipv6 19a19,22 > # Partition clearing information > zerombr > ignoredisk --only-use=sda > clearpart --initlabel --drives=sda --all ```
Please, attach all files with installation logs, especially the file named syslog. You can find them during the installation in /tmp or on the installed system in /var/log/anaconda/.
Created attachment 1771495 [details] TGZ of all log files.
Uncompressed, the syslog file was 2.2MB and timed out the uploader twice. So, I compressed all of the logs to 1.2MB and sent the TGZ.
The installer fails to find the USB CD-ROM drive, because the `ignoredisk --only-use=` kickstart command hides it. As a workaround, you can use the `harddrive` command instead of the `cdrom` command. For example: harddrive --partition=sdb --dir=/ where sdb is the name of the USB device, or specify the USB device with a label: harddrive --partition=LABEL=CentOS-8-3-2011-x86_64-dvd --dir=/ It is a known issue that we would like to fix soon.
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.