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>
.. in exactly the same way GUI and TUI installer do, streamlining them.
Up until now, testing the TUI installer often involved hand-editing the
`run-env-info.json` to put some proper disk sizes > 0 in place. This
makes this process a lot easier.
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>
That's what happens when you do some last-minute variable renaming and
trust that nothing broke ..
Fixes: 42aa2fa ("fix #4829: install: add new ZFS `arc_max` setup option")
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
grub packages in debian split between:
* meta-packages, which handles (among other things) the reinstalling
grub to the actual device/ESP in case of a version upgrade (grub-pc,
grub-efi-amd64)
* bin-packages, which contain the actual boot-loaders
The bin-packages can coexist on a system, but the meta-package
conflict with each other (didn't check why, but I don't see a hard
conflict on a quick glance)
Currently our ISO installs grub-pc unconditionally (and both bin
packages, since we install the legacy bootloader also on uefi-booted
systems). This results in uefi-systems not getting a new grub
installed automatically upon upgrade.
Reported in our community-forum from users who upgraded to PVE 8.0,
and still run into an issue fixed in grub for bookworm:
https://forum.proxmox.com/threads/.123512/
Reproduced and analyzed by Friedrich.
This patch changes the installer, to install the meta-package fitting
for the boot-mode.
We do not set the debconf variable install_devices, because the
'install_devices' variable is only defined for 'grub-pc', and thus
(still) only set for that package/namespace.
Reported-by: Friedrich Weber <f.weber@proxmox.com>
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Reviewed-by: Fabian Grünbichler <f.gruenbichler@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>
moved over from the TUI installer
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>
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>
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>
