securityonion
securityonion copied to clipboard
Improve error messaging on kickstart when no drives are present.
When I boot the ISO, the media check runs successfully and then I see brief text saying 'starting installer, one moment' after this there is some text that flashes on the screen too quickly to see, and then I see a blinking cursor....forever.
When I hit Alt+F1, I see:
anaconda x.y.z for CentOS 7 started.
...
...
The following problem occurred on line 0 of the kickstart file:
Unable to open input kickstart file: curl#37 - "Couldn't open file /tmp/part-include"
Please let me know if there are particular logs I can grab that would be helpful. I noticed that I can hit Alt+Tab to get to a prompt and poke around on the fileystem.
I've flashed another USB flash drive with the ISO and get the exact same result. I'm using Balena Etcher for flashing if that's relevant. Can anyone else reproduce this problem with the 2.3.2 ISO?
I just successfully ran the install inside a Virtualbox VM so my next guess is that the installation distro isn't compatible with my server hardware. It's a Thinkmate (re-branded supermicro) RAX XS4-11E2-SH which appears to have this motherboard.
/etc/centos-release tells me: CentOS Linux release 7.8.2003 (Core)
...which looks like the second to last CentOS release.
Does anyone have suggestions on the best route forward here? Is there a way to provide a newer kernel/drivers to the install? If it is indeed a problem w/ too new hardware, then falling back to the previous security onion release probably isn't going to help the situation.
Here are some of the logs in /tmp:
Perhaps the most notable item in there is the syntax error in the ks-script:
line 63: /3: syntax error: operand expected (error token is "/3")
which is this line:
ROOTSIZE=$(($GB/3))
...perhaps GB
wasn't properly given a value and is empty?
OK, I think I've gotten to the bottom of this. It looks like the script is assuming that any NVMe drives will have a symlink in /sys/block
named nvme
but in my hardware case, the kernel has named the symlink /sys/block/nvme0n1
.
Since the for
loop right after # Ask some basic questions
never evaluates true since it never matches nvme
, NUMDRIVES
is never incremented, but the script proceeds with the assumption that it's been incremented at least once, the logic that populates GB
and SIZE
never runs because there are no DEV
values it ever matches on, and then it finally crashes when it tries to set a value for ROOTSIZE
since GB has no value.
As near as I can tell, that's more or less what's happening.
Could this issue get some love from the developers? It would be great to get this fixed so we can get Security Onion up and running.
@TOoSmOotH this appears to be a case where the ks script isn't properly handling NVMe storage device names; do you know who on your team would be best suited to look into this?
I can confirm I'm receiving the same error.
There there a quick workaround? I wanted to install SO on a Laptop I have kicking around.
Receiving the same error on a xenserver box.
I have the same problem on Odyssey x86j4105 using SO 2.3.21. Some logs:
- /tmp/anaconda.log
ERR anaconda: Error code 1 running the kickstart script at line 43
- /tmp/ks-script-IM0alg.log
line 63: /3: syntax error: operand expected (error token is "/3")
OK, I have found the solution for Odyssey x86j4105. I tried to install SO on the eMMC (device mmcblk1) which is only ~58GB (less than required >99GB). After connecting additional disk, installation completed successfully.
NVME installs should work properly now starting in 2.3.30
These symptoms can also been seen when attempting a virtualised installation on a disk using the LsiLogic SCSI controller driver. Centos 7.X does not support LsiLogic or BugLogic drivers which is documented up to 7.4. No mention of that limitation on the 7.6 release notes (applicable to SO installer) strangely enough, but the issue seems to remain.
Came across this with libvirt/KVM which defaults to lsilogic
when using a SCSI controller and will likely also affect VMware. In my case, changing to virtio-scsi
fixed the issue, allowing the virtual disk to be seen by the installer.
This error occurs when it is unable to find a hard disk to install on. Going to try and improve the messaging to address confusion.
Hello Community,
I've got the same issue as OP, no NVME Disks involved, just normal HDDs in a RAID 10. I used the most recent version of Security Onion (securityonion-2.3.140-20220718), but also have had the same issue with version 2.3.91 and 2.3.120.
When i tested it with version 2.3.91 and 2.3.120 there wasn't Ubuntu installed on the server, just the blank virtual RAID drive.
Tried installation mediums:
- USB DVD-Drive
- USB Thumb Drive (with Ventoy)
- Internal DVD Drive
Outputs and logs were from the USB DVD-Drive attempt.
Output of lsblk (sdb device can be ignored [plugged in after failed installation for logs and outputs]):
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 1 3.6T 0 disk
|-sda1 8:1 1 512M 0 part
|-sda2 8:2 1 1G 0 part
`-sda3 8:3 1 3.6T 0 part
`-ubuntu--vg-ubuntu--lv 253:2 0 3.6T 0 lvm
sdb 8:16 1 14.9G 0 disk
|-sdb1 8:17 1 14.8G 0 part
`-sdb2 8:18 1 32M 0 part /media
sr0 11:0 1 7.1G 0 rom /run/install/repo
loop0 7:0 0 432.4M 1 loop
loop1 7:1 0 2G 1 loop
|-live-rw 253:0 0 2G 0 dm /
`-live-base 253:1 0 2G 1 dm
loop2 7:2 0 512M 0 loop
`-live-rw 253:0 0 2G 0 dm /
Output of /tmp/anaconda.log:
11:55:08,980 INFO anaconda: /sbin/anaconda 21.48.22.147-1
11:55:10,165 INFO anaconda: created new libuser.conf at /tmp/libuser.R3ZEeF with instPath="/mnt/sysimage"
11:55:10,167 INFO anaconda: 65667072 kB (64128 MB) are available
11:55:10,260 INFO anaconda: check_memory(): total:64128, needed:320, graphical:410
11:55:10,322 INFO anaconda: anaconda called with cmdline = ['/sbin/anaconda']
11:55:10,322 INFO anaconda: Default encoding = utf-8
11:55:10,364 INFO anaconda: Running kickstart %%pre script(s)
11:55:10,364 INFO anaconda.stdout: Running pre-installation scripts
11:55:10,598 ERR anaconda: Error code 1 running the kickstart script at line 43
11:55:10,598 INFO anaconda: All kickstart %%pre script(s) have been run
11:55:10,598 INFO anaconda: Parsing kickstart: /run/install/ks.cfg
Hardware Specs:
- Mainboard: Supermicro X11DPL-i C621 S3647
- RAID Controller: Adaptec 8405 4Port 12Gb LP PCIe3.0 x8
- 4 x 2TB WD Ultrastar
Please let me know, if i can help to solve the issue with any other logs or outputs.
Best Regards MW
Hey, I have the same problem with 2.1.3.140-20220729 at Lenovo P350 Workstation (ThinkStation) - Type 30E3 , GRUB seems not to recognize the NVME. At UEFI bios, SATA is set to ACPI (instead of Intel RST), secure boot is disabled (as Lenovo mentions here). You can select, which install procedure you want to start, after hiting ENTER, menu disappears ant nothing happens. An installed Ubuntu tells me "/dev/nvme0n1pX" as device name. Also testes 2.3.130.
@TOoSmOotH So could it maybe be that there still an issue with NVME drives and like i wrote in my previous comment maybe with the model of my RAID controller? I nearly tried everything to install Security Onion on that machine and had no success, the last thing i maybe try is install it via pxe, but that would be pretty time-consuming and i am not sure if it makes any difference if i just change the way i'm delivering the installation medium.
I resolved this topic via installing Ubuntu 20.04 and installing Security Onion there. Works great.
Thanks! This wouldn't be my favourite solution, but i'll give it a try as soon as i've got some time for testing.
We are having the same issues with NVMe drives on a dell 740xd with the same situation and everything. Is there any resolution beyond installing security onion manually overtop another distro?
We are having the same issues with NVMe drives on a dell 740xd with the same situation and everything. Is there any resolution beyond installing security onion manually overtop another distro?
Yes, Ubuntu as I did https://github.com/Security-Onion-Solutions/securityonion/issues/1825#issuecomment-1211717061 , see also https://docs.securityonion.net/en/2.3/installation.html
i am on dell with vmware workstation. i changed my virtual disk type from scsci to sata and problem solved.
I ran into the same error others have referenced when attempting to install from the ISO.
I was able to work around the problem by entering my BIOS setup and reverting the operating mode of the drive controller from Intel Rapid Storage Technology (confusingly enabled by the "RAID ON" option) to AHCI. This was on a Dell pc that I use as my test system.
From past experience with changing this setting, reverting back to AHCI has a significant impact on performance, so I don't think this will be a permanent solution.