this is a detail of the tz zoneinfo data/format, avoid to do the
replacement dance too.
IMO most users would be even rather confused by the Etc/ prefix.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Adds 'Etc/UTC' as option to the timezone selection, regardless of what
country is selected.
The 'Etc/' prefix needs to be stripped for the installation, as this
value is written to /etc/timezone. PVE/PMG/PBS already use 'UTC' without
the prefix, so avoid regressing them.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
to ensure we have enough space for more kernels and possible unified
kernel images (UKI) in the future.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
zpool is used for the command, so it should also be referred to in
the error message.
Reported-by: Roland <devzero@web.de>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
For one as this just avoids very oddly specific swap size values, and
more importantly, storage systems like LVM that need to align their
sizes to their internal extent size won't round up on odd numbers
anymore.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Following commit 1a5fa7b093 but for
the non-PVE code path we also need to align down to 4 MB with the
adapted auto-sizing, especially on smaller disks.
For PMG and PBS installations. Without it installation fails due to
one missing extent when creating the root LV. Minimally tested on a
VM of mine
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
[ T: reworded commit message a bit ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
stay in MB size range for longer to have some accuracy level we need
and mask the last 2 bits (= 4 MB) to align down to a level that
should not interfere with LVM anymore.
Otherwise, with $rest sizes that hit the second if branch < 48
regressed on LVM due to missing one extend of expected space.
Dominik verified this off-list to fix the case Stefan run into.
Reported-by: Stefan Hanreich <s.hanreich@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Switch also from tracking the calculation in GB to MB for higher
accuracy and more flexibility.
Note also that the hd_gb / 8 -> GB is the same as hd_gb * 128 -> MB,
so the auto-calculation did not change semantically.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Avoid a per-default extra free space block if the disk has less than
32 GB of total space.
Use the full rest size for root if it's below 12 GB, not much of a
point in setting up a data thin LVM for guests then.
Then also show a display message if no thin LVM is created to inform
the admin
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Make the 8 GB disk check a soft limit, as most products are still
installable with less space, even though it may need some special
options in the disk selection. Still notify the user with a prompt to
avoid an expected possible error seem like it was unexpected.
Keep 2 GB as hard limit for now, makes no sense to install on such
small devices, only pain.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
It should actually fail since the switch to chrony, but syscmd only
returns the exit code and we did not check it.
Shortly thought about checking for the existence of
"$targetdir/lib/systemd/system/chrony.service" and enable
chrony.service in that case, but that is unnecessary too, as we know
due to this bogus enable timesyncd which never stopped chrony to run
happily enabled after installation anyway.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The"auto get lowest disk size from selected set" logic also reset it
to that if the previously chosen value was already lower on reopening
the disk dialogue.
That can be rather surprising for an user as the hdsize field is a
bit hidden in the advanced dialogue, so just reopening to ensure the
correct disks are selected may interfere with a previously lowered
hdsize.
Reported-by: Fabian Ebner <f.ebner@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
We can just get the configured adjustment and reset its value and
upper bound and not always do a more expensive recreation just for
that.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
we explicitly have an "Deselect All" Button if we got more than 4
disks, and if that's hit nothing is selected and we'd die with an
internal error in an normal, to be expected case; which must not
happen.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
we triggered the change even handler #disk-times, which is just
stupid as nothing in it depends from the inner loop, so move it out.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
as described in the bug-entry it is still not possible to have a
swapfile on general btrfs setups (only on single disk (single data
profile - documented in [0,1], and my quick tests confirmed it).
Users who still need/want swap can now set a hdsize smaller than their
disk-size to keep a part unpartitioned for adding a swap-partition
after installation (like with ZFS).
I quickly considered sticking with a single 'advanced raid' tab and
adapting the visibility of the individual lines, but did not see an
elegant way (as far as this is possible with GUI code) of doing that.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
the patch splits get_hdsize_spinbtn into a sub for generating the adjustment
gtk-element and one for the button itself and moves them above
create_raid_disk_raid (so that the adjustment sub can be called)
The adjustment gets it's data from the disks selected for installation
in the GUI, if a size is not provided.
Additionally the bogus 'zfs' argument to the create_raid_advanced_grid
was dropped.
Tested with a VM with 2x 100G disks, and one with 20G
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
zfs_mirror_size_check is already called in get_zfs_raid_setup when
necessary, so don't call it unconditionally, as this will cause a
false-positive error on RAID0 devices (where size mismatches are fine).
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
Tested-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Reviewed-by: Stoiko Ivanov <s.ivanov@proxmox.com>
instead of cutting it off by using int
especially relevant currently with 2 TB disks (people wonder why
it's displayed as 1 TiB - and would be fine with 1.95TiB).
Reported in our community forum:
https://forum.proxmox.com/threads/.103636/
Tested in a VM with a 100 GiB, 20GiB and 2TiB disk
Addtionally added the explicit return ath the end of the if branch,
instead of relying on the last statement not moving.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
for better readability - and more robust handling in proxmox-boot-tool
quickly tested with the latest PMG-ISO and the debug mode.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
we actively synced two times already at this point, immediately after
the installer GUI exited and before starting to unmount stuff, so
reboot should not be required to sync and may even hang if trying to
do
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
