Kickstart failure

Support
1

VMware Workstation 17.0.2, AlmaLinux 9.2 kickstart install.

Experimenting with NVMe drive configuration. When I do a manual install with a 30GB drive, anaconda-ks.cfg shows the following:
ignoredisk --only-use=nvme0n1

Partition clearing information

clearpart --none --initlabel

Disk partitioning information

part /boot --fstype=“xfs” --ondisk=nvme0n1 --size=1024
part swap --fstype=“swap” --ondisk=nvme0n1 --size=2048
part / --fstype=“xfs” --ondisk=nvme0n1 --size=27647

However when I put those exact lines in my kickstart file the GUI chokes with: “Installation Destination: Kickstart insufficient”

But no way to find out why it is whining. Don’t have this problem using the old --ondisk=sda method

Must be missing something very basic.

Suggesstion?

2

Are you sure about this?
I’m not an expert, but I have clearpart --all --initlabel in all my kickstart files.

3

Yes. I’m sure. Been using this for over 15 years. There are 3 issues:

  1. Why would anaconda have values that aren’t accurate?
  2. Why would changing from sda to nvme drive type fail when all other values are identical?
  3. Why isn’t there any documentation for calculating values?

Yes, I realize LVM would prevent all this, but for this exercise it’s not an option.

4

And ksvalidator doesn’t give any hints? I know that it’s not considered as being very serious - but it’s good for catching silly typos.

5

If I’m understanding correctly, since you reinstalled after an initial installation – are you re-using the same nvme0n1, or a cleared one? A typical problem I have is pre-existing partitions that don’t get erased even when I ask Anaconda to do so, and it looks like you’re explicitly asking it not to.

The text installer has a pane you can switch to using tmux commands that’ll show you logged errors from Blivet and such, which are generally more informative than the error given in the main pane. There’s also a pane with a shell you can go look at the log files yourself, though I don’t remember off of the top of my head where, /tmp maybe, or /mnt/sysimage something.

6

i suspect its too close to 30gb, try:

part / --fstype=“xfs” --ondisk=nvme0n1 --size=1 --grow
7

Actually, I’m creating a brand new VM from scratch each time. And ksvalidator doesn’t report any issue. The ONLY change to the kickstart file is changing sda to nvme.

8

Not really the issue. The issue is: after a successful install, the parameters in the anaconda kickstart file DO NOT WORK in a kickstart file

9

ksvalidator is useless.

i wouldn’t really expect /root/anaconda-ks.cfg to work 100% for new installs, you need to put some work into it usually, as they’re parsed and rearranged and all sorts. even if you do a kickstart install, the anaconda version ends up different to the original.

did you try my suggestion of not specifying the size of / ? i’m thinking the disk sizes aren’t identical even if they are virtual ssd vs nvme (probably 512b vs 4kb sector size issue).

10

If you open a shell in the installer environment, what are the full errors in the .log files in /tmp, particularly in storage.log?

11

Here’s mine:

For legacy bios:
clearpart --all --initlabel
partition /boot --asprimary --fstype ext4 --size=512 --maxsize=512
partition / --asprimary --fstype=ext4 --size=1024 --grow

For EFI:
clearpart --all --initlabel
partition /boot/efi --asprimary --fstype=efi --size=512 --maxsize=512
partition / --asprimary --fstype=ext4 --size=1024 --grow

For xfs I think you only have to modify “fstype”.
512 for /boot for me is sufficient, because I don’t have more than 3 kernels, but you can increase it as you need.

12

yeah could be as simple as /boot/efi is missing, which has to be vfat, can’t be xfs

part /boot      --fstype xfs  --size=512  --fsoptions="nodev,nosuid,noexec"
part /boot/efi  --fstype vfat --size=512  --fsoptions="umask=0077,fmask=0077,uid=0,gid=0,shortname=winnt"

you could use reqpart, see docs: