The check for dkms kernel modules relies on the output of `dkms
status`. dkms command invocation will perform the following sanity
check:
```
if [ ! -e <(echo) ]; then
warn $"dkms will not function properly if /proc is not mounted."
fi
```
This check will however throw the following warning when SIGPIPE is
set to be ignored:
```
sbin/dkms: line 2497: echo: write error: Broken pipe
```
While only cosmetic, this can be confusing. Therefore, temporarily
enable SIGPIPE before calling dkms, restoring the originally setting
afterwards.
Reported-by: Alexander Zeidler <a.zeidler@proxmox.com>
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
(cherry picked from commit 2bbf10d9ef)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This should catch installations from our ISO on non-ZFS in uefi mode,
which won't get the updated grub efi binary installed upon upgrade,
because grub-pc is installed instead of grub-efi-amd64.
Adding this to pve7to8 should make this even more visible, than the
corresponding patch for promxox-kernel-helper (warnings printed during
regular package upgrades might be overlooked more easily than
a yellow line in the major upgrade checkscript)
The if/else order was chosen to limit the nesting level of the long
messages.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
For Fedora 38 the systemd shared object files used to check the systemd
version are located at /usr/lib64/systemd or /usr/lib/systemd.
Therefore, include /usr/lib64/systemd in the list of directories to
check.
Further, Fedora 38 adds a fc38 postfix to the filename, so expand the
regex to cover that as well.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
Commit 114e5f2c ("pve7to8: sync over from stable-7 branch")
accidentally got rid of the correct value 0 here and also the new TODO
message to improve the situation. But the TODO is actually easy,
because there already is the $upgraded variable. Just rely on that
instead of hard-coding and forgetting about it again.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
can be useful for things that might be OK, so where warn or even fail
would be to drastic, but that should be still checked as they seem
odd.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
since the package won't get installed for systems upgraded from 7 to 8
we warn users who need systemd-boot - to be able to initialize new
ESPs - that they need to install it
The check for package installation is based on existance of the
changelog, since the package information used in pve7to8 comes from
the API-modules, which limit it to the pve-relevant packages.
tested in VMs with uefi and legacy mode, with existing
proxmox-boot-uuids both with and w/o systemd-boot being installed
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Just like 3b776617 ("pve6to7: enable noout before upgrade") last time,
it should be enabled in the stable branch to ensure users see the
warning before upgrade.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
It's required in the schema for notes-template and protected, but when
parsing vzdump.conf, it shouldn't matter whether the storage parameter
is set or not.
The warning is ugly and users might interpret it as something that
needs to be acted upon for the upgrade:
parse error in '/etc/vzdump.conf' - 'storage': missing property - 'notes-template' requires this property\nmissing property - 'protected' requires this property
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
It just talks about the default behavior since PVE 7. It's rather
confusing to mention this, because the behavior doesn't change anymore
in PVE 8.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
The current inequality check for content-dirs does not correctly
handle the case in which `abs_path` returns undef. This can result in
confusing warnings:
storage [...] uses directory for multiple content types [...]
Fix this by skipping paths for which `abs_path` returns undef. This
matches the behavior of the actual content-dirs check in PVE 8 [0].
[0]: https://git.proxmox.com/?p=pve-storage.git;a=commit;h=09f1f847a
Fixes: ea0a4f1943
Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
consistently use for instead of foreach (just shorter and avoids that
one thinks foreach does something special) and break a long line
while at it.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
While it would be a failure now (and I thus have recommended Dominik
to use a fail here), we cannot really predict how this
evolves. If NVIDIA fixes the issue in newer driver/tooling we cannot
detect this and telling users to ignore a failure can lead to them
getting condition on that and start ignoring any failure.
So, let's ignore my initial error-level hunch and use a warning,
which is quite prominent too.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Avoid a error message like "Failed to get unit file state for
nvidia-vgpu-mgr.service: No such file or directory" on systems that
don't have that service.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Currently the nvidia vgpu host driver (15.2) does not support kernels >
6.0 and thus will not work with bookworm based releases for now.
Fail when the service is running, and warn if it only exists, but is
disabled/stopped (in case a user installed it sometime but did not need
it and disabled it).
In any case, link to the known issues section in the upgrade guide
(which we can update to contain up-to-date information).
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Checking /lib/systemd if it is present and a directory is not enough, as
the shared object file used to check the version might nevertheless be
located at /usr/lib/systemd, or under /usr/lib/x86_64-linux-gnu/systemd.
So check also the latter paths, if the former returned no match.
Further, Arch Linux appends the minor version and release version to the
filename, so include that in the regex as well.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
users can have the 6.2 kernel already installed, so this check needs
to cope with that.
The last non-bpo version on bullseye releases was 6.2.11-2-pve and
the first release for bookworm was 6.2.16-1-pve, so use a regex that
matches the bookworm one and newer, but fails with any tilde
characters, which must be used for any 6.2 update in bullseye from
now on to ensure correct upgrades.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Using a directory for multiple content types will throw an error in
PVE 8 (see 5f4b5bd1 in pve-storage). Hence, detect this in pve7to8 for
active storages and warn if needed.
Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
The commit hash of the Ceph version might be different between major
releases. For example:
ceph version 17.2.6 (810db68029296377607028a6c6da1ec06f5a2b27) quincy (stable)
ceph version 17.2.6 (995dec2cdae920da21db2d455e55efbc339bde24) quincy (stable)
This can lead to unnecessary warnings of multiple detected versions.
Therefore, extract the version, e.g. 'ceph version 17.2.6', and the
commit hash. Use the simplified version for the version checks and show
an info line when the commit is different instead of a warning.
If the commit hashes are the only difference, we are likely in the
middle of the upgrade.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
note that this is only checked in the hyper-converged use-case,
otherwise we don't really care what ceph client version is in use, as
that cannot really break much w.r.t. the upgrade (i.e., packaging
dependencies) itself.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
As for persistent storage we normally use GB not GiB nowadays (e.g.,
in the Web UI), as 2^30 is bigger than 10^9, rounding up to 5 GB
should be fine; it's really safer to have a bit more free space as
minimally required in some minimal setups.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
albeit this is affecting guests too, maybe it would better fit into a
new Virtual Guests section.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
