We do not host any guests or the like here, so a bridged setup is nor
really required. Disable it for now.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
recursively unmount testdir before removing it. This prevents the subsequent
call to try to remove files in potentially still bindmounted /proc, /sys, /dev
filesystems.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Use the same regex as the 'email' format in JSONSchema (copied from there).
Otherwise, users can enter an email address which does not match our
schema and breaks the userlist API Call with a 'return value
verification failed', and one cannot rectify this via the gui
(the user has to manually edit the user.cfg or set the email via
pveum)
i noticed this while testing and using the 'insert emoji' menu in the
context menu
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
currently only the first vdev of a ZFS rpool gets created with the stable
/dev/by-id paths, all later vdevs (in a RAID0 or RAID10 setup) are left as
sdX.
By iterating over all disks in the pool and replacing their occurence with
their by-id path we get consistent and recommended names for all vdevs.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
by wiping the partition table after the initial sanity checks regarding
minimal size and blocksize of the device, no data is destroyed for an
install that would fail in any case.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Installation on disks with 4k logical blocksize (4kn) failed, because
the bios_boot (a.k.a. gdisk partitiontype EF02, place for grub in
legacy BIOS boot mode) partition is created using start and end
sectors (and sector 2047 is not at 1M, where the ESP starts)
This patch addresses the issue by not creating the bios_boot
partition on 4kn disks at all - legacy boot from 4kn disks is not
supported by most BIOS implementations and grub does not support it
[0].
Checks for 4kn disks, when booted in legacy mode are added, and
prevent from leaving the harddisk selection page, if an not bootable
selection was made.
The partition numbering was kept (esp is partition 2, data is
partition 3, for consistency with other installations)
If any of the bootable disks is 4kn then the installation of the grub
legacy installation is skipped altogether.
Additionally the invocation of mkfs.vfat needs to add the parameter
'-s1' to create a bootable ESP on 4kn disks.
For a 512M vfat partition on a 512n or 512e disk, mkfs.vfat
calculates a default value of 8 sectors per cluster. For a 512M
partition on a 4kn disk, we need to scale this by 512/4096=8 and
explicitly set '-s' to 1 accordingly, since the calculation in
mkfs.vfat is brokenly assuming 512b sectors[1].
Tested with a qemu-machine by passing
'logical_block_size=4096,physical_block_size=4096' to the disk's device lines
and installing in UEFI and legacy booted mode:
* ZFS RAIDZ1
* ZFS single-disk
* ZFS RAID10 (in legacy mode grub fails to install, if any 4kn disk is in the
pool, even if it's not in the first vdev)
* EXT4
[0] http://savannah.gnu.org/bugs/?46700
[1]: https://github.com/dosfstools/dosfstools/issues/111
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
/sys/block/$dev/size is also given in 512b sectors even for 4kn disks.
Since it surprised me - mention it explicitly in the comment
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
postfix relies on /etc/aliases.db for forwarding mail, without this file
all mails get deferred. (see `man newaliases`)
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
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]).
[0] http://www.postfix.org/COMPATIBILITY_README.html#relay_domains
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
this fixes the display and selection problem with countries that
have non-ascii symbols in them, like "Côte d'Ivoire"
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
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..
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
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
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
see machine-id(5). The machine-id serves as a partial replacement to the hostid
(gethostid(3)) used by systemd and should be unique.
By generating a new one with `systemd-id128 new` (see machine-id(5),
sd-id128(3)) after the installation the newly installed system gets a unique
one.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
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>
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>
If a user really want's to try it, why not.
Also, no point in dividing by 1024 if we have a less-than operator
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
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).
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
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
