Was probably missed because it used to be in a binary crate where doc
tests aren't run automatically.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
Reviewed-by: Christoph Heiss <c.heiss@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Copy code that is common to its own crate.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
Reviewed-by: Christoph Heiss <c.heiss@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
It will be used for code shared among the different crates in the
installer. For now between the TUI installer and the upcoming auto
installer.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
Reviewed-by: Christoph Heiss <c.heiss@proxmox.com>
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
[TL: fold in Christoph's buildsys fix ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Enables the advanced and LVM dialog to determine what options (max
root/data size and Btrfs RAIDs) by itself, without needing to resort to
the global `setup_info()` function.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
This aligns it with the other constructors for options struct by
introducing a `::defaults_from()` function.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
[ TL: merge fix for missing state member when declaring a Interface
struct in a test on master ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This now tries to use the hostname from the DHCP lease if it was set,
falling back to the product name as before.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
This now tries to use the hostname from the DHCP lease if it was set,
falling back to the product name as before.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
like we do in the GTK UI since recently, there we also color the
filled circle green, but with current cursive crate version this
doesn't seem to be easy, at least not without breaking its theming a
bit (e.g., by just using ANSI escape codes), so just use the circle
for now.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
We do actually want the block size if it is integer - currently, it is
always set to `undef` (and then `null` in the serialized JSON).
Fixes: 15b2cd7 ("sys: block: fix possible use of `undef`-value when detecting disk sizes")
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Even if the installer is run in release mode, the test-mode flag should
be honored on whether to start a test-installation or not.
The test mode is always forced on in debug builds, so the cfg()
conditionals can be dropped.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Commit 55dc67c ("tui: fix FQDN validation") mostly fixed FQDN
validation, but missed a case when the search domain only has one
component.
As Fqdn::from() requires at least two components to pass validation, the
search domain parsing from the runtime environment info provided by the
low-level installer failed. This resulted in that the network dialog
defaulted to "<product>.example.invalid" as FQDN, instead of
"<product>.<searchdomain>" as it should.
Fixes: 55dc67c ("tui: fix FQDN validation")
Reported-by: Aaron Lauterer <a.lauterer@proxmox.com>
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
The GUI installer already has the same rules in place, not allowing to
boot from 4Kn disks when booting in legacy BIOS mode. The TUI installer
currently only checks that for ZFS RAIDs, so extend that check to all
filesystem configurations.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
This is already checked for LVM and ZFS setups, but not for Btrfs. Add
it there too, as it doesn't work anyway.
Tested by creating a block device with 4K sectorsize using
the following QEMU args:
-device virtio-blk,drive=testdrive4k,logical_block_size=4096,physical_block_size=4096
-drive file=/path/to/4k-testdisk.img,if=none,id=testdrive4k
The 4k-testdisk.img was created with:
qemu-img create -f qcow2 /path/to/4k-testdisk.img 16G
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
As that value can indeed be undefined, handle that (edge-)case
gracefully. There is only one place where it is checked, in the ZFS RAID
setup dialog. Aligns it with how the low-level installer handles that
case too.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
`$size` and `$logical_bsize` might get unset if there invalid, but then
are unconditionally converted to an int - which throws an error.
This was reported on the forum by a user [0].
Fix it by changing the check a bit to skip the disk immediately if
detecting either of those two values are invalid or simply not present.
The fix for `$logical_bsize` simply avoids trying to convert to value to
an int if invalid.
tl;dr: Should have no impact at all, in the end. The same
`run-env-info.json` is generated w/ and w/o the patch if all disks are
fine. I then also hacked up the script a bit to actually have an invalid
size, this resulted in the "affected" disk simply missing from the disk
array - the expected behavior in this case.
[0] https://forum.proxmox.com/threads/error-installing-proxmox-8.131921/
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
This can be tested by creating a block device with 4K sectorsize using
the following QEMU args:
-device virtio-blk,drive=testdrive4k,logical_block_size=4096,physical_block_size=4096
-drive file=/path/to/4k-testdisk.img,if=none,id=testdrive4k
The 4k-testdisk.img was created with:
qemu-img create -f qcow2 /path/to/4k-testdisk.img 16G
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Instead of always just selecting an essentially random NIC (depending on
the enumeration), use the correct one for the rest of the
(DHCP-obtained) IP configuration.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Since we now have a test suite (or, at least the TUI installer in this
case), we can enable dh_auto_test so that it will be run on package
builds.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
This adds early checks when setting up ZFS and Btrfs RAIDs, such as
minimum number of disks in the RAID, mirror sizes and legacy BIOS
compatibility.
The same rules as the GUI uses are applied, which unfortunaly means that
this logic is essentially duplicated between the GUI and TUI.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Now we don't just fail silently, but instead give the user/developer
some indication what went wrong.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
This is needed later on to check whether a RAID setup is compatible with
BIOS and 4Kn disks, in particular ZFS.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Add checks to ensure that:
* It is actually has a hostname, not just a domain name
* Properly check if the hostname is purely numeric, which was
broken/different to how the GUI installer does it
The custom error type also allows for easier future adaptions, as the
changes can be entirely contained to the `Fqdn` type.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
.. in the same fashion as the GUI installer.
See also proxinstall:create_intro_view() for reference.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Currently there is a bug that you only can install < 8 GB when you NOT
accept the warning. This is wrong. A user should have to accept the
warning to install on small systems
Signed-off-by: Philipp Hufnagl <p.hufnagl@proxmox.com>
[T: reword commit subject & fix typo there ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Another puzzle piece in the quest to align the TUI installer more to
its GUI counterpart.
Like the GUI installer, it will only be shown if >3 disks are
detected on the system.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
If the minimum requirements are not met, the TUI installer will create a
popup notifying you that the install might not work and then exits the
installer.
While the GUI also creates such a popup, it will not exit the installer.
This patch adapts the behavior of the GUI: the TUI creates a popup
warning you that min spec is not met but doesn't abort the install.
Signed-off-by: Noel Ullreich <n.ullreich@proxmox.com>
Reviewed-by: Christoph Heiss <c.heiss@proxmox.com>
Tested-by: Christoph Heiss <c.heiss@proxmox.com>
[T: fix conflict in context and drop intermediate variable ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
As the runtime environment now exports that info, use it. In turn, this
allows us to drop the dependency on `proxmox-sys`, as that check was its
only user.
The dependency graph drops from 107 to 88 crates from this, which
definitively is a nice change.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
As that info is now available through the runtime environment info, use
it and avoid duplicating logic.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Can later be used by the installer frontends, as well as nicely alinging
with the 'single source of truth' "policy".
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
> On-Access [...] leverages a kernel api called fanotify to block
> processes from attempting to access malicious files. This
> prevention occurs in kernel-space, and thus offers stronger
> protection than a purely user-space solution.
This is not really useful for the PMG use case and requires user
configuration as otherwise it refuses to start. In fact, is the sole
unit marked as failed after a fresh installation:
> ERROR: Clamonacc: at least one of OnAccessExcludeUID,
> OnAccessExcludeUname, or OnAccessExcludeRootUID must be specified
> it is recommended you exclude the clamd instance UID or uname to
> prevent infinite event scanning loops.
So disable it by default, if a user really wants this, whyever that
would be, the can just configure it and enable it again via
systemctl.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
