Currently, when multiple NICs are present in a system the TUI
sometimes selects the wrong interface (not the one that has the
default gateway/dhcp lease)
I assume this is due to HashMap's values yielding an iterator in
arbitrary order
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Co-authored-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
[ TL: avoid intermediate vector, reuse the SelectView's iter()]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
according to `man zfsprops` the copies option can only be 1, 2, or 3.
limit the field to 3 just like we do for the GTK based UI, as setting
higher options can't work anyway.
Signed-off-by: Stefan Sterz <s.sterz@proxmox.com>
[ TL: fleece in note that we already limit this in the GTK UI ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The GTK installer/UI module in the low-level installer does the same.
Messages used with this are worded for this, using yes/no instead can be
quite confusing (e.g.
Proxmox::Install::ask_existing_vg_rename_or_abort())
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Happens due to a force-unwrap() under the false assumption that the
disk for LVM configurations always exists when switching to a LVM
filesystem.
This fails spectacularly with a panic when switching from e.g. Btrfs to
ext4 in the filesystem chooser.
Fixes: eda9fa0 ("fix #4856: tui: bootdisk: use correct defaults in advanced dialog")
Reported-by: Christian Ebner <c.ebner@proxmox.com>
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
The GUI installer already has the same functionality, with this the TUI
installer gains the same. It is a nice touch anyway, primarily to
indicate to the user that the installer is not frozen or similar.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
This at least gives _some_ feedback to the user he can potentially
report or try to address, instead of a single, hardcoded message.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
While at it, convert it to a proper `View`-impl, instead of a functional
component.
No functional changes.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
The size of the install disk was set to the size of the first disk,
regardless of what disk was selected. This only happened if the advanced
options dialog was never opened, and only a disk was selected in the
main bootdisk dialog.
Properly solving this involved restructuring the LVM advanced bootdisk
dialog, to also hold the selected disks, like the ZFS and Btrfs dialogs.
In addition to that, the `BootdiskOptionsRef` needs quite some passing
around, to cover all the cases, since the dialog also needs to be
"reentrant-safe".
I tested (among other things):
* Only select disk, don't open the advanced dialog, go to summary,
then back to the bootdisk dialog -> selected disk should be kept
* Select disk, open advanced dialog but leave everything as is, go to
summary, then go back again -> selected disk should be kept
* Same as previous, but change the "Total size" for the disk, go to
summary and back -> selected disk and size should be kept
* Same as previous, but additionally change filesystem to XFS -> disk,
filesystem and size should be kept
* Same as previous, but then create a ZFS RAID, go to summary & back,
ZFS RAID should be kept with all parameters
* etc ..
Further I also verified that the correct disk size(s) get written into
the setup structure for the low-level installer.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Will be used/passed around quite a lot of times due to future changes,
so simplify it a bit.
No functional changes.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
To set the maximum value for arc_max accordingly, simply pass down
`RuntimeInfo` directly instead of the disks array to the views.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Most of the churn here is due to changing the inner view from an
`EditView` to a `LinearLayout`. Also prompted the introduction of two
small helpers .inner() and .inner_mut() to simplify things everywhere
else in the view.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
all it did moved to the common 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>
by switching dependencies and deleting doubled code to avoid ambiguities
within the same scope.
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
If lots of disks are present and the available screen size is rather
small, it might be impossible for users to properly set all disks as
they want.
Fix it by making the view scrollable.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
previously the tui used `u64` internally to represent the disk size.
since the perl-based installer expects GiB as floats and that is also
what is displayed in the tui that meant a lot of converting back and
forth. it also lead to an error where the disk sizes that were set
seemed to not have been persisted, even though the sizes were
correctly set. this commit refactors the installer to convert the size
once in the beginning and then stick to `f64`.
Signed-off-by: Stefan Sterz <s.sterz@proxmox.com>
Reviewed-by: Christoph Heiss <c.heiss@proxmox.com>
Tested-by: Christoph Heiss <c.heiss@proxmox.com>
it's just safer to make the user look at the summary and avoid that a
stray enter hits of the installation.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
except the password dialog, since the user must provide input
to do that, we have to set the focus index on all relevant views
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
After eaa7d41 - which directs all stderr from the TUI to tty2 - this can
be safely done without interrupting the TUI.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Since we already handly non-present domain names, invalid names can be
handled the same way, as not to completely fail the installation.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
While this might look at it should it terminal emulators, in a raw tty
this can have different effects; e.g. being a bright blue/green and
nearly unreadable. For now, just remove the effect completely, the
semantics are still very much clear.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Since we already handly non-present domain names, invalid names can be
handled the same way, as not to completely fail the installation.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Otherwise, the user would be blocked from continuing the the installer,
instead just being presented with an error.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Similar to our actual battle proven get_ip_config, but as the TUI
uses this one, and switching to it rather more risk, make just
addresses optional, add skip for "lo" loopback and don't skip ifaces
that aren't UP in the current helper.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
with this you can type without removing the decimal places, but if
you type inside the decimal places it'll just move the cursor to the
end and do nothing
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
If, for some reason, the network is not properly configured (due to
e.g. no DHCP server being present on the network), there will be no
routes in the runtime environment as well. So do not depend on that,
otherwise the installer fails at the start.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
