`$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>
previously the disk selection was reset if the advanced options
dialogue was re-opened. this commit adapts the behavior to restore
the previous selection.
Signed-off-by: Stefan Sterz <s.sterz@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This is basically "installer information" and will is used
for things such as default values for which we do not want
to pass around all the data.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
The convoluted calculation logic in case the disks is 8GB leads to
datasize becoming 16EiB further down:
* after calculating and removing the rootsize from $rest, $rest becomes
smaller than $space (which should be the minimal non-used space in the
volume-group) - this leads to a negative value, which overflows in
the `& ~0xFFF` opration.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
While this was already done in the $rest < 48 GiB cases, it wasn't yet
done for the else branch and also not if $maxroot_mb was assigned,
because of being smaller.
Second and last step towards fixing an issue reported in the community
forum [0] where using 250.00 hdsize, 250 maxroot and 0 minfree would
fail.
Turns out two extents would be missing because of lvcreate implicitly
rounding up, one of them for the root LV (the one for metadata was
already handled in the previous commit).
[0]: https://forum.proxmox.com/threads/129320/post-566375
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
First step towards fixing an issue reported in the community forum [0]
where using 250.00 hdsize, 250 maxroot and 0 minfree would fail.
Turns out two extents would be missing because of lvcreate implicitly
rounding up, one of them for the metadata.
[0]: https://forum.proxmox.com/threads/129320/post-566375
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Otherwise the user only has 5 seconds to see the error message before
the machine reboots.
Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
