Stoiko Ivanov [Wed, 23 Oct 2019 16:10:26 +0000 (18:10 +0200)]
raise postifx main.cf compatibility_level to 2
otherwise a warning was issued (when missing /etc/aliases.db) that the system
is using the backward compatible setting of $mydestination for $relay_domain
(see [0]).
by collecting them, but proceeding with the rest of the installation. it
is possible that only either legacy or EFI boot fails, and even if both
do, manually fixing the bootloader setup by booting a live CD is very
often possible.
still display the error screen at the end if bootloader setup was not
successful, so that expectations are not set too high..
prompt user if a vgrename is OK for exisiting 'pve'/'pmg' VGs
If one has a 'pve' VG on a disks not selected as install target
(e.g., on re-installation to different disk or if putting a used disk
into another server where PVE was installed on) the vgcreate call
errored out, as for creation the VG names must be unique.
Cope with that by asking the users if a rename to a
'<vgname>-OLD-<short-uid>' name is OK in this case. It ensures that
no data is lost and that we can safely continue with the
installation. The admin can then later on wipe the renamed VG if it
was really decommissioned or save data from it (or actually use it)
This can cope (tested) with:
* a single 'pve' VG on another device
* a single 'pve' VG spanning multiple devices
* multiple 'pve' VGs spanning different sets of devices
This is achieved by using the VG UUID for rename, and by recording
all PVs with said UUID as index.
Note, while this commit message talks mostly about 'pve' VG the patch
itself is actually agnostic of the specific name, works for 'pmg' and
possible (future) other VG names too.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
/etc/hostid is used by ZFS (spl.ko) to determine which host last imported a
pool creating and importing a pool with one hostid during install and booting
with a different one (or none) leads to the system refusing to import the pool
see spl-module-parameters(5) and zpool(8).
by copying the /etc/hostid from the installer into the target system we ensure
that it stays consistent
mount efivarfs to ensure we can read bigger variables
In short, EFI variables can get quite big, and the old sysfs
interface was made for when they couldn't. A few firmwares out there
have such big variables, and if those are accessed through the sysfs
backed interface one gets a "Input/Output Error". 'grub-install'
chokes on that error when it iterates over all variables to do it's
stuff, and thus fails our installation. When we mount the efivarfs,
which does not has this limitations, one can read all variables just
fine - at least as long as the NVRAM backing them is not broken.
from Linux Kernel Documentation/filesystems/efivarfs.txt:
> The efivarfs filesystem was created to address the shortcomings of
> using entries in sysfs to maintain EFI variables. The old sysfs EFI
> variables code only supported variables of up to 1024 bytes. This
> limitation existed in version 0.99 of the EFI specification, but was
> removed before any full releases. Since variables can now be larger
> than a single page, sysfs isn't the best interface for this.
> Variables can be created, deleted and modified with the efivarfs
> filesystem.
Also mount it in the installer environment for debugging purpose.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
underline that we detected less than 1024 MB of *useable* memory
firmwar, kernel, and some PCI(e) devices can use some memory, which
then is not available for userspace, thus the total memory installed
for this server normally differs at least about 50 MB from the
useable one.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This ensures that when booting from a USB stick, or similar device,
we do not show that device in the "Target Harddisk" selector.
While there may be some constructed cases where this actually worked
and was wanted, e.g., one created a partition on the end of a USB
storage device, put the ISO on that and used the beginning of that
device as target, I'd say that even if that worked with luck, it's
better not actively not support it.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Oguz Bektas [Tue, 2 Jul 2019 13:17:32 +0000 (15:17 +0200)]
abort installation if memory is less than 1GB
show a message on screen about memory requirement, then die and abort
the installation. (Note: followup removes the die again - Thomas)
The "magical" limit seems around 850 - 900 MiB memory needed, it's
a bit strange, as we do not need that much, proxinstall + webkit +
base system are around 300 MiB, the rest is page cache, but it seems
that the memory pressure gets to big.
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com> Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
With the recent fixes to the installers initial /dev creation, the installer
and the kernel should now have the same view on the created devices and links
along with `pvremove -ff` and writing zeroes to the first 16M of all
partitions, which belong to disks selected in the installer run `zpool
labelclear`.
This prevents a failure to boot after installation, if the disks were
previously also used as a zpool called rpool, but in a different configuration
(e.g. installing a raidzX first and then changing to raid10).
update systemd-boot config after initializing esps
run the kernel-postinst hook once (like we do for update-grub) instead
of once per ESP. This fixes an error (the hook does not write entries for
mounted partitions), and save quite a bit of (un)mounting and copying in case
of multiple ESPs
Thomas Lamprecht [Mon, 25 Mar 2019 20:18:23 +0000 (21:18 +0100)]
unconfigured: mount /dev/shm as tmpfs inside chroot
as preparation for GKT3 WebKit2 perl bindings, which wants to make a
shared memory file there, but fails and hangs the installer as
/dev/shm didn't exists in the chroot environment.
Doesn't hurt to just create it now already
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht [Mon, 25 Mar 2019 18:47:05 +0000 (19:47 +0100)]
tell udev to ignore being in a chroot
since udev/systemd v241 udev actively ignores requests if it detects
running in a chroot environment[0], as we do exactly this in our
setup process we need to tell udev that it is OK and we know what we
do, so set SYSTEMD_IGNORE_CHROOT=1 which makes the
"running_in_chroot" function lie[1].
Thomas Lamprecht [Thu, 13 Dec 2018 10:13:32 +0000 (11:13 +0100)]
buildsys: do not copy test disk images over to build dir
this is unecessary and rsycn does no sparse copy if the --sparse
option is not passed.
As I want to introduce easier testing with multiple disks this helps
alot in reducing test setup and package build time.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Oguz Bektas [Tue, 11 Dec 2018 09:02:22 +0000 (10:02 +0100)]
implement previous button
this implements a previous button to the installer, along with some
structural changes to allow the installer to be more modular in the
future (such as a step list and a global config hash)
Stoiko Ivanov [Fri, 7 Dec 2018 11:35:31 +0000 (12:35 +0100)]
Fix #2009: Recreate hdsize_adj with new hdsize
Creating $hdsize_size_adjustment once with a passed hdsize, breaks changing
the disk to a smaller/larger one, since the installer is stuck with the limits
set with the initial disk.
Stoiko Ivanov [Wed, 28 Nov 2018 11:40:57 +0000 (12:40 +0100)]
Reset adjustment for spinbutton_hdsize
After setting the input buffer for the spinbutton the default value
wasn't displayed anymore, resulting in odd behaviour when clicking in the field
w/o entering/changing a value.
Setting the adjustment again, sets the default value as before
Stoiko Ivanov [Thu, 22 Nov 2018 17:27:02 +0000 (18:27 +0100)]
Do not create a swap zvol
Using zvols as swap devices does create deadlocks for users, as of zfs 0.7.9.
As the discussion of the issue [0] shows, fixing this is involved, and probably
won't be happening anytime soon (before zfs 0.8).
Not creating swap as a zvol seems like the better default setting for now.
Users needing swap can either leave unpartitioned space, by setting minfree,
or create the zvol quite easily after installation
Stoiko Ivanov [Thu, 22 Nov 2018 17:26:57 +0000 (18:26 +0100)]
Unify and adapt disk partitioning
Change partition_bootable_disk:
* Increase the efi-esp partitions' size to 512M (from 256M)
* Create the bios_boot partition in the first MB (sectors 34:2047)
* Split the sgdisk invocation into 2, to get 1M alignment for efi and os
partitions
Changes are inspired by the wiki-entries by zol-upstream [0].
Use partition_bootable_disk also for bootable ZFS disks.
This provides users with the opportunity to leave unpartitioned space at
the end of the disk (by setting the hdsize parameter) for use outside of ZFS
(e.g. to create a dedicated swap partition).
projects / pve-installer.git / log