this should fix failures of the template instances because either of the two
other import services picked up the pool in question first.
Signed-off-by: Fabian Grünbichler
---
...dd-systemd-unit-for-importing-specific-pools.patch | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
missed the subjectprefix, this is for ZFS ;) thanks @Stoiko for pointing
it out off-list
On March 28, 2024 10:41 am, Fabian Grünbichler wrote:
> this should fix failures of the template instances because either of the two
> other import services picked up the pool in question first.
>
> Signed-of
This slipped through while taking the wording from PMG.
Fixes: 67d2d94 ("installation: lvm-options: improve & align wording with
pmg-docs")
Signed-off-by: Christoph Heiss
---
Probably have been staring at the docs too long to not notice this
earlier ..
pve-installation.adoc | 2 +-
1 file chan
LGTM - Thanks for the idea and patch!
gave it a spin by creating a pool through the GUI, rebooting,
seeing the spurious warning, installing a patched version,
rebooting multiple times (no warning), adding yet another pool and
enabling zfs-import-scan.service (did not manage to boot without
zpool.c
On 2024-03-28 11:45, Christoph Heiss wrote:
This slipped through while taking the wording from PMG.
Fixes: 67d2d94 ("installation: lvm-options: improve & align wording with
pmg-docs")
Signed-off-by: Christoph Heiss
---
Probably have been staring at the docs too long to not notice this
ear
Should we stick with v1 or v2? V1 is definitely more strongly worded
than v2.
v1:
+**·SSDs·with·Power-Loss-Protection·(PLP)·are·recommended·for·good·performance.
+··Using·consumer·SSDs·is·discouraged.
vs v2:
+**·Enterprise·grade·SSDs·are·recommended·for·good·performance.·Check·for·power
+··los
so it can be deserialized from a string
Signed-off-by: Aaron Lauterer
---
proxmox-installer-common/src/utils.rs | 11 +++
1 file changed, 11 insertions(+)
diff --git a/proxmox-installer-common/src/utils.rs
b/proxmox-installer-common/src/utils.rs
index 36b1d53..f6521eb 100644
--- a/prox
necessary for the disk selection and network interfaces maps to have
tests with results that can be compared without much additional effort.
Signed-off-by: Aaron Lauterer
---
proxmox-installer-common/src/setup.rs | 8
proxmox-tui-installer/src/options.rs | 4 ++--
proxmox-tui-installer
Signed-off-by: Aaron Lauterer
---
proxmox-auto-installer/src/lib.rs | 1 +
proxmox-auto-installer/src/udevinfo.rs | 9 +
2 files changed, 10 insertions(+)
create mode 100644 proxmox-auto-installer/src/udevinfo.rs
diff --git a/proxmox-auto-installer/src/lib.rs
b/proxmox-auto-instal
Signed-off-by: Aaron Lauterer
---
Cargo.toml| 1 +
Makefile | 1 +
proxmox-auto-installer/Cargo.toml | 10 ++
proxmox-auto-installer/src/lib.rs | 0
4 files changed, 12 insertions(+)
create mode 100644 proxmox-auto-installer/Cargo.toml
It describes the data structure expected by the low-level-installer.
We do this so we can use it in more than the TUI installer, for example
the planned auto installer.
Make the members public so we can easily implement a custom From method
for each dependent crate.
Signed-off-by: Aaron Lauterer
Signed-off-by: Aaron Lauterer
---
unconfigured.sh | 8
1 file changed, 8 insertions(+)
diff --git a/unconfigured.sh b/unconfigured.sh
index 2b371f0..f02336a 100755
--- a/unconfigured.sh
+++ b/unconfigured.sh
@@ -5,6 +5,7 @@ trap "err_reboot" ERR
# NOTE: we nowadays get exec'd by the in
Signed-off-by: Aaron Lauterer
---
proxmox-installer-common/src/setup.rs | 10 ++
1 file changed, 10 insertions(+)
diff --git a/proxmox-installer-common/src/setup.rs
b/proxmox-installer-common/src/setup.rs
index f9f9e82..19113e1 100644
--- a/proxmox-installer-common/src/setup.rs
+++ b/pr
because we will need to access them directly in the future from a
separate binary
Signed-off-by: Aaron Lauterer
---
proxmox-auto-installer/src/utils.rs | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/proxmox-auto-installer/src/utils.rs
b/proxmox-auto-installer/src/utils.
Signed-off-by: Aaron Lauterer
---
proxmox-auto-installer/Cargo.toml | 1 +
proxmox-auto-installer/src/utils.rs | 46 +++--
2 files changed, 18 insertions(+), 29 deletions(-)
diff --git a/proxmox-auto-installer/Cargo.toml
b/proxmox-auto-installer/Cargo.toml
index b1d3e
Signed-off-by: Aaron Lauterer
---
proxmox-auto-installer/Cargo.toml| 1 +
proxmox-auto-installer/src/answer.rs | 256 +++
proxmox-auto-installer/src/lib.rs| 1 +
3 files changed, 258 insertions(+)
create mode 100644 proxmox-auto-installer/src/answer.rs
diff -
This patch series adds the possibility to do an automated / unattended
installation of Proxmox VE.
The overall idea is that we will have a dedicated ISO for the unattended
installation. It should be configured in such a way that it will start
the installation without any user interaction.
Though t
It sends a http(s) POST request with the sysinfo as payload and expects
an answer file in return.
In order to handle non FQDN URLs (e.g. IP addresses) and self signed
certificates, it can optionally take an SHA256 fingerprint of the
certificate. This can of course also be used to pin a certificate
contains several utility structs and functions.
For example: a simple pattern matcher that matches wildcards at the
beginning or end of the filter.
It currently uses a dedicated function (parse_answer) to generate the
InstallConfig struct instead of a From implementation. This is because
for now
It expects the contents of an answer file via stdin. It will then be
parsed and the JSON for the low level installer is generated.
It then calls the low level installer directly.
The output of the installaton progress is kept rather simple for now.
If configured in the answer file, commands will
It can parse an answer file to check against syntax errors, test match
filters against the current hardware and list properties of the current
hardware to match against.
Since this tool should be able to run outside of the installer
environment, it does not rely on the device information provided
Putting proxmox-fetch-answer into it's own crate, will keep the use of
OpenSSL localized to where we need it. Otherwise building other binaries
will always depend on OpenSSL as well, even without actually needing it.
Having a dedicated crate for the proxmox-autoinst-helper should make it
easier to
as they will be used directly by the auto installer
Signed-off-by: Aaron Lauterer
---
proxmox-installer-common/src/setup.rs | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/proxmox-installer-common/src/setup.rs
b/proxmox-installer-common/src/setup.rs
index 03beb77.
For the Enums that will be used to deserialize an answer file.
Signed-off-by: Aaron Lauterer
---
proxmox-installer-common/src/options.rs | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/proxmox-installer-common/src/options.rs
b/proxmox-installer-common/src/optio
Signed-off-by: Aaron Lauterer
---
proxmox-auto-installer/Cargo.toml | 4
1 file changed, 4 insertions(+)
diff --git a/proxmox-auto-installer/Cargo.toml
b/proxmox-auto-installer/Cargo.toml
index 75cfb2c..67218dd 100644
--- a/proxmox-auto-installer/Cargo.toml
+++ b/proxmox-auto-installer/Car
Fetches UDEV device properties prepended with 'E:' for NICs and disks.
The result is stored in its own JSON file.
This information is needed to filter for specific devices. Mainly for
the auto-installer for now.
Signed-off-by: Aaron Lauterer
---
Proxmox/Makefile| 1 +
Proxmox/Sys/U
Log to stdout and the file the binary needs to set up.
This is a first variant. By using the log crate macros we can change
that in the future without too much effort.
Signed-off-by: Aaron Lauterer
---
proxmox-auto-installer/Cargo.toml | 2 ++
proxmox-auto-installer/src/lib.rs | 1 +
proxmox-
Signed-off-by: Aaron Lauterer
---
debian/control | 10 ++
1 file changed, 10 insertions(+)
diff --git a/debian/control b/debian/control
index 3ca208b..1326400 100644
--- a/debian/control
+++ b/debian/control
@@ -8,10 +8,20 @@ Build-Depends: cargo:native,
libgtk3-perl,
This helps to know how the system was set up in steps after the
installation. For example in debug mode or when using post commands in
the automatic/unattended installation.
Signed-off-by: Aaron Lauterer
---
proxmox-low-level-installer | 1 +
1 file changed, 1 insertion(+)
diff --git a/proxmox-
as only the 'path' property is serialized -> deserialization is
problematic. The information would be present in the 'run-env-info-json',
but for now there is no need for it in any code that deserializes the
low-level config. Therefore we are currently skipping it on
deserialization
If we need it
It will collect the information from the current system and show the
payload of identifiers that will be send.
To avoid confusion, the subcommands for the device info and filter
matching have been renamed.
Signed-off-by: Aaron Lauterer
---
.../src/bin/proxmox-autoinst-helper.rs| 54
Signed-off-by: Aaron Lauterer
---
proxmox-installer-common/Cargo.toml | 1 +
proxmox-installer-common/src/options.rs | 10 --
proxmox-installer-common/src/setup.rs | 43 +++--
3 files changed, 48 insertions(+), 6 deletions(-)
diff --git a/proxmox-installer-common/C
it is meant as a helper utility to prepare an installation for chroot
and clean up afterwards
It tries to determine the used FS from the previous installation, will
do what is necessary to mount/import the root FS to /target. It then
will set up all bind mounts.
Signed-off-by: Aaron Lauterer
---
sorry, forgot to set the subject: pve-installer
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
They will be used as payload when POSTing a request for an answer file. The
idea is, that with this information, it should be possible to identify
the system and generate a matching answer file on the fly.
Many of these properties can also be found on the machine or packaging
of the machine and cou
it is supposed to be run first and fetch an answer file.
The initial implementation searches for a partition/filesystem called
'proxmoxinst' or 'PROXMOXINST' with an 'answer.toml' file in the root
directory.
Once it has an answer file, it will call the 'proxmox-auto-installer'
and pipe in the con
This plugin will send a HTTP POST request with identifying sysinfo to
fetch an answer file. The provided sysinfo can be used to identify the
system and generate a matching answer file on demand.
The URL to send the request to, can be defined in two ways. Via a custom
DHCP option or a TXT record on
Am 26/03/2024 um 10:16 schrieb Christian Ebner:
> For certain network setups the default values currently used to send
> a wake on lan magic packet are not correct, e.g. it will get send via
> the interface for which the default gateway is configured.
>
> This patches add optional configuration op
By matching the resulting json to be passed to the low level installer
against known good ones.
The environment info was gathered from one of our AMD Epyc Rome test
servers to have a realistic starting point.
Signed-off-by: Aaron Lauterer
---
proxmox-auto-installer/tests/parse-answer.rs | 102
39 matches
Mail list logo
