HannesK wrote: ↑Oct 07, 2024 3:52 pm
@Entropy:
upgrades from Ubuntu: yes, that "upgrade path" is something mentioned earlier in the thread via "repair mode".
UPS support: I put it on the feature request list. How do you connect to the UPS? serial, USB, network?
@HannesK
Thanks for spelling it out for me (upgrade path from Ubuntu).
We have a dedicated UPS for our particular LHR, so it's connected via USB. Given the importance of the data to us I plan to keep it as a dedicated UPS, but in a more cost sensitive application I would expect SNMP comms. At least that's how we do shared Liebert / Vertiv UPS elsewhere in our org.
ccox@griffinnet.com wrote: ↑Oct 14, 2024 12:30 pm
NEW ISO UPDATE
Still getting stuck on multipath with and without inst.nompath.
I will try and find a different raid card(older) and maybe some non-sas drives - can't complain about multipath if there are no multipath disks, right?
It's the same problem for us. However, we have all SATA drives. I have also tried deleting the arrays using a different USB bootable tool (Rufus and Etcher) and the inst.nompath. Nothing has worked.
Don't know if this helps but, I tested a clean RHEL 9 install and that works fine - Plymouth does show the waiting on multipath but it moves on to the next steps and gets to the gui in under 5 seconds
HannesK wrote: ↑Oct 07, 2024 12:42 pm
@BrianBuchanan : I'm not 100% sure I understood the feedback, but I try to answer With when re-installing the operating system with "repair mode", then the installer would not know where something was mounted before. It would just keep everything except the smallest disk and mount that to /mnt/... . My understanding is, that there is no reason against /mnt/.
It was the "veeamrepository-xx" part of "/mnt/veeamrepository-XX" that I was focused on, suggesting using the filesystem's UUID as the mount point name instead.
For example if the original install creates and mounts a file system using the UUID as the mount point, then the repair mode could do the same and it would be consistent forever.
click on done does nothing... in the bottom is a yellow line call "no disk selected; please select at least one disk to install to"
if i go to return i just cant "begin installation", yellow line again, complaining about missing items -> "installation destination" -> no disk selected...
Then, something is not configured correctly with your system to run the installation properly. Checking the documentation to ensure you meet the requirements is my best suggestion.
@DaStivi : All disks are automatically selected. The "done" button does nothing. That is expected, but I missed it in the "known issues" section in the user guide. I will add that, thanks. If the disk requirements in general are not met, then the installer fails before getting into the graphical installer.
If I need to guess, then you have a VM with BIOS instead of UEFI. With BIOS, everything looks different and does not work in general. Almost nothing you see would match with the user guide / video. Can you confirm that the VM meets the system requirements about UEFI secure boot?
Open issues update:
- @flow90 confirmed that the "kickstart insufficient" bug is resolved in a later build. Thanks again for testing
- this bug is resolved in a later build. Thanks again for testing
- the "cancel waiting for multipath siblings" is still under investigation. Thanks so far for the information you provided via email.
is it possible to add a check to simply block installation with BIOS-Mode? i did recognized the installer looked different then my test before with the TP Version (there are all kind of languages selectable when running the installer in bios mode... with uefi for example only english is left... looks like the kickstart script isn't running then in bios)... but i just stumbled across the bios/uefi setting on creating my new test machine...
Probably possible, but due to complexity of "block BIOS", we prioritized other features. As you are not the first one, I move the priority a bit higher now
i just ran into the next issue,... after enabling SSH for repo creation. i simply cannot logon with the provided ssh creds... at first i thought it might be some issue with strange characters in the password (like ~ ) but even after stopping ssh and enabling it again and getting different passwords with not that special-special-characters i still cant login.. i just get access denied everytime (putty) and "a supplied password or user name is incorrect" from VBR ... ssh-keys match so i do connect to the correct machine..
vhradmin can never log in via SSH
veeamsvc can log in via SSH, but I guess the account is locked now https://www.veeam.com/kb4663. We plan to simplify the special characters in a later build. The "permanent lockout" is a default setting of the DISA STIG profile. We considered to unlock after a few minutes, but currently it's the default setting.
tested this great ISO with a VM, but now I'm having issues when trying to add the new hardened repo to the veeam server: SSH-connection is fine, but then it fails during the installation of the installer service...
Which logs would i have to check?
BTW, what I like so far is the very short and simplified installation wizard and so your linux box runs within a few minutes. I have only spotted one little detail I don't like: The difference in the password between I an l is very hard to spot and so you can have a lot of retries/failures...
Hello, @mcz : which build do you use? If it was the 0.1.15, then very likely there is no connection to repository.veeam.com and / or the paths do not match anymore. That is fixed only in 0.1.16
on the password: Agree with I vs l. The plan is to get rid of passwords completely. The 0.1.16 build simplified and we will see what can be done.
Bug update: the "multipath siblings" issue was identified and technically there is a workaround if one edits the boot option like in the picture below.
1. the string on the left (red) must also be on the right side (green). Rufus might cut it off.
2. the inst.ks= (orange) must be added on the right
The reason for the problem is, that USB boot was used. We will work on a fix for that. Hint: please use Balena Etcher instead of Rufus for creating your bootable USB drive. Rufus seems to be known to create issues here and there for Rocky Linux (it's not the root cause for this particular problem, just additional information).
HannesK wrote: ↑Oct 22, 2024 11:36 am
Hello,
@mcz : which build do you use? If it was the 0.1.15, then very likely there is no connection to repository.veeam.com and / or the paths do not match anymore. That is fixed only in 0.1.16
on the password: Agree with I vs l. The plan is to get rid of passwords completely. The 0.1.16 build simplified and we will see what can be done.
Best regards
Hannes
Correct Hannes, as soon as I used 0.1.16, everthing works as expected. Thanks!
stupid questions, guys: how can you escape the main menu? because if you for instance have to install a driver for your network card, you somehow need console-access to install it... thanks!
With when re-installing the operating system with "repair mode", then the installer would not know where something was mounted before. It would just keep everything except the smallest disk and mount that to /mnt/... . My understanding is, that there is no reason against /mnt/.
