Bel article sur proxmox 5 ⇒ https://community.capensis.org/t/nouveautes-installation-et-configuration-de-proxmox-5-2/133

Pour supprimer la config ceph si vous l’avez activé par inadvertance

pveceph purge

Pour tester la migration de 6 vers 7

pve6to7
pve6to7 --full

Proxmox est une distribution linux sous debian lenny qui intègre les outils openvz ( http://wiki.openvz.org/Main_Page ) permettant la virtualisation de machine.

L’intérêt de proxmox est qu’ils ont développés une interface web permettant de gérer facilement les outils openvz.

Ici l’install se fait via OVH sur un kimsufi 2g

On va sur la page http://pve.proxmox.com/wiki/Get_Virtual_Appliances pour trouver nos OS qu’on veut installer en VM

Ensuite, dans notre cas nous voulons installer une debian 6.0 64bit

cd /vz/template/cache/
wget http://download.proxmox.com/appliances/system/debian-6.0-standard_6.0-4_amd64.tar.gz

Par défaut, vous avez un bridge vmbr0 connecté sur votre interface réseau physique avec votre adresse publique

Name: vmbr0
IPv4/CIDR : 94.94.94.94/24
Gateway (IPv4) : 94.94.94.254
Bridge ports: eno1

Créons un bridge qui définira notre réseau local

Name: vmbr1
IPv4/CIDR : 192.168.0.1/24
Gateway (IPv4) : (vide)
Bridge ports: (vide)

On crée maintenant une VM avec les infos suivantes

Name: eth0
Bridge: vmbr1
IPv4 : Static
IPv4/CIDR : 192.168.0.2/32
Gateway (IPv4) : 192.168.0.1

Maintenant, il faut dire au système que l’on veut faire de l’ip forwarding

echo 1 > /proc/sys/net/ipv4/ip_forward

Ensuite il suffit juste de rajouter une règle iptable pour router notre réseau local vers le bridge qui a accès au WAN

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o vmbr0 -j MASQUERADE

Vous pouvez automatiser tout ça dans votre fichier /etc/network/interface

auto vmbr1
iface vmbr1 inet static
        address 192.168.0.1/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        post-up echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o vmbr0 -j MASQUERADE
        post-up /root/dnat.sh
        post-down iptables -t nat -D POSTROUTING -s 192.168.0.0/24 -o vmbr0 -j MASQUERADE

Le fichier /root/dnat.sh pourra contenir des règles de NAT pour accéder à la machine depuis l’extérieur

Pour un accès ssh de votre VM, vous devez utiliser un autre port que le 22 qui est déja utilisé par votre serveur principal.
Exemple pour le port 2222 qui sera redirigé sur le port 22 de votre VM 192.168.0.2

iptables -t nat -A PREROUTING -i vmbr0 -p tcp --dport 2222 -j DNAT --to-destination 192.168.0.2:22

Dans ce cas la, pas besoin de faire du nat, on a une sorte de pont entre le wan et les vm. On ne peut pas faire d’iptables directement dans les VM, je n’ai pas trouvé l’astuce… Donc tout se faire sur le serveur proxmox.

L’insterface vmbr0 correspond à l’interface de proxmox, ensuite, tout ce qui est forwardé sur cette interface fini sur les VM.

Brièvement, pour couper le port 80 sur la machine proxmox mais sans couper le port 80 de vos VM

iptables -A INPUT -i vmbr0 -p tcp --dport 80 -j DROP

A l’inverse, couper le port 80 de toutes vos VM sans couper celui de proxmox

iptables -A FORWARD -i vmbr0 -p tcp --dport 80 -j DROP

Pour couper le port 80 d’une seule VM, procurez-vous son adresse ip et ajoutez-la dans la règle

iptables -A FORWARD -i vmbr0 -p tcp -d 199.199.199.199 --dport 80 -j DROP

Garder à l’esprit que vos VM peuvent communiquer entre elle, je mettrai prochainement une règle permettant de les isoler entre elles.

La commande suivante permet un backup de base

[root@serveur:]# vzdump --compress 102
INFO: starting new backup job: vzdump --compress 102
INFO: Starting Backup of VM 102 (openvz)
INFO: CTID 102 exist unmounted down
INFO: status = CTID 102 exist unmounted down
INFO: backup mode: stop
INFO: ionice priority: 7
INFO: creating archive '/var/lib/vz/dump/vzdump-openvz-102-2012_01_22-23_33_14.tgz'
INFO: Total bytes written: 457912320 (437MiB, 4.3MiB/s)
INFO: archive file size: 188MB
INFO: Finished Backup of VM 102 (00:01:46)
INFO: Backup job finished successfuly

Le contenu de l’archive comprend toute l’arborescence du serveur virtuel ce qui est pratique pour récupérer toutes les données que l’on souhaite sans avoir les outils openvz sous la main.

La commande suivante permet la restautarion d’un backup de ma machine 101 sur une nouvelle machine nommé 103

[root@serveur:/vz/vzdump]# vzrestore vzdump-openvz-101-2012_01_29-00_00_02.tgz 103
INFO: restore openvz backup 'vzdump-openvz-101-2012_01_29-00_00_02.tgz' using ID 103
INFO: extracting archive 'vzdump-openvz-101-2012_01_29-00_00_02.tgz'
INFO: Total bytes read: 583393280 (557MiB, 21MiB/s)
INFO: extracting configuration to '/etc/vz/conf/103.conf'
INFO: restore openvz backup 'vzdump-openvz-101-2012_01_29-00_00_02.tgz' successful

Avec proxmox vous n’avez pas besoin d’utiliser ces lignes de commandes pour faire un backup, tout est prévu dans l’interface web.

Il suffit de déclarer un espace de stockage pour les backups, ensuite on crée une tache de backup en spécifiant la période, combien de backup on garde et quelle machine on veut sauvegarder.

Rien n’est prévu toutefois pour faire une restauration… il faudra passer par la ligne de commande.
Une fois la commande de restauration effectué, vous retrouverez la machine dans votre interface web.

Admettons vous voulez un répertoire dans votre VM qui contient plein de données mais vous ne souhaitez pas que ces données soient inclus dans le backup de votre VM.

La solution est de créer un répertoire qui sera partagé par le système proxmox dans votre VM.

Pour cela on va utiliser un montage bind directement sur la machine proxmox.

Admettons que votre VM est le numéro 101, tapez cette commande sur la machine proxmox.

mount --bind /var/lib/vz/stockage /var/lib/vz/root/101/mnt/stockage

Maintenant tout ce que vous stockerez sur votre VM dans le répertoire /mnt/stockage ne sera pas considérer comme des données de votre VM et ne sera donc pas sauvegardé par votre backup.

Pour que ce montage se fasse automatiquement, vous devez créer le fichier suivant

/etc/vz/conf/101.mount

#!/bin/bash
source /etc/vz/vz.conf
source ${VE_CONFFILE}
mount --bind /vz/stockage ${VE_ROOT}/mnt/stockage

Assurez-vous qu’il soit exécutable, chez moi il s’est mis automatiquement exécutable.

Par défaut on trouve pas mal de templates disponibles sur proxmox mais par exemple, il n’y a que la version 32bits de Debian.

On peut trouver une version 64bits et d’autres distrib ici ⇒ http://wiki.openvz.org/Download/template/precreated

Il n’y a plus qu’a les télécharger dans le répertoire template prévu par proxmox.

Plus de openVZ maintenant c’est du LXC

Our image repositories contain a list of available images, and there is a cron job run each day to download that list. You can trigger that update manually with:

pveam update

After that you can view the list of available images using:

pveam available

You can restrict this large list by specifying the section you are interested in, for example basic system images:

List available system images

# pveam available --section system
system          archlinux-base_2015-24-29-1_x86_64.tar.gz
system          centos-7-default_20160205_amd64.tar.xz
system          debian-6.0-standard_6.0-7_amd64.tar.gz
system          debian-7.0-standard_7.0-3_amd64.tar.gz
system          debian-8.0-standard_8.0-1_amd64.tar.gz
system          ubuntu-12.04-standard_12.04-1_amd64.tar.gz
system          ubuntu-14.04-standard_14.04-1_amd64.tar.gz
system          ubuntu-15.04-standard_15.04-1_amd64.tar.gz
system          ubuntu-15.10-standard_15.10-1_amd64.tar.gz

Before you can use such a template, you need to download them into one of your storages. You can simply use storage local for that purpose. For clustered installations, it is preferred to use a shared storage so that all nodes can access those images.

pveam download local debian-8.0-standard_8.0-1_amd64.tar.gz

You are now ready to create containers using that image, and you can list all downloaded images on storage local with:

# pveam list local
local:vztmpl/debian-8.0-standard_8.0-1_amd64.tar.gz  190.20MB

The above command shows you the full Proxmox VE volume identifiers. They include the storage name, and most other Proxmox VE commands can use them. For example you can delete that image later with:

pveam remove local:vztmpl/debian-8.0-standard_8.0-1_amd64.tar.gz

solution ⇒ https://www.razva.ro/fixing-apparmordenied-namerunsystemdjournaldev-log/

J’ai constaté ça dans /var/log/syslog

Mar  5 21:37:58 p2pfr kernel: [2587040.014930] audit: type=1400 audit(1488746278.820:13404): apparmor="DENIED" operation="sendmsg" profile="/usr/sbin/named" name="/run/systemd/journal/dev-log" pid=20470 comm="named" requested_mask="w" denied_mask="w" fsuid=109 ouid=0
Mar  5 21:38:33 p2pfr kernel: [2587074.565032] audit: type=1400 audit(1488746313.371:13411): apparmor="DENIED" operation="sendmsg" profile="/usr/sbin/named" name="/run/systemd/journal/dev-log" pid=20469 comm="named" requested_mask="w" denied_mask="w" fsuid=109 ouid=0
Mar  5 21:38:55 p2pfr kernel: [2587096.733778] audit: type=1400 audit(1488746335.538:13413): apparmor="DENIED" operation="sendmsg" profile="/usr/sbin/named" name="/run/systemd/journal/dev-log" pid=20473 comm="named" requested_mask="w" denied_mask="w" fsuid=109 ouid=0
Mar  5 21:39:00 p2pfr kernel: [2587101.993724] audit: type=1400 audit(1488746340.798:13414): apparmor="DENIED" operation="sendmsg" profile="/usr/sbin/named" name="/run/systemd/journal/dev-log" pid=20473 comm="named" requested_mask="w" denied_mask="w" fsuid=109 ouid=0
Mar  5 21:39:25 p2pfr kernel: [2587126.367660] audit: type=1400 audit(1488746365.173:13420): apparmor="DENIED" operation="sendmsg" profile="/usr/sbin/named" name="/run/systemd/journal/dev-log" pid=20467 comm="named" requested_mask="w" denied_mask="w" fsuid=109 ouid=0
Mar  5 21:39:25 p2pfr kernel: [2587126.624156] audit: type=1400 audit(1488746365.429:13421): apparmor="DENIED" operation="sendmsg" profile="/usr/sbin/named" name="/run/systemd/journal/dev-log" pid=20469 comm="named" requested_mask="w" denied_mask="w" fsuid=109 ouid=0
Mar  5 21:40:06 p2pfr kernel: [2587167.443497] audit: type=1400 audit(1488746406.248:13429): apparmor="DENIED" operation="sendmsg" profile="/usr/sbin/named" name="/run/systemd/journal/dev-log" pid=20471 comm="named" requested_mask="w" denied_mask="w" fsuid=109 ouid=0
Mar  5 21:40:11 p2pfr kernel: [2587172.965146] audit: type=1400 audit(1488746411.768:13431): apparmor="DENIED" operation="sendmsg" profile="/usr/sbin/named" name="/run/systemd/journal/dev-log" pid=20468 comm="named" requested_mask="w" denied_mask="w" fsuid=109 ouid=0

Après une recherche, j’ai pu comprendre que proxmox utilise un soft qui s’appelle AppArmor qui est une espèce de soft qui controle ce que d’autres soft ont le droit de lire ou écrire sur le serveur.

Si on analyse le log, on nous parle du profile /usr/sbin/named qui veut accéder à /run/systemd/journal/dev-log en écriture ( requested_mask=w )

Il faut donc chercher sur proxmox la règle du même nom ⇒ /etc/apparmor.d/usr.sbin.named et là on ne trouve aucune trace de /run/systemd/journal/dev-log

Donc pour faire les choses bien, on va ajouter notre règle dans le fichier prévu à cette effet dans /etc/apparmor.d/local/usr.sbin.named ce qui doit donner ça

# Site-specific additions and overrides for usr.sbin.named.
# For more details, please see /etc/apparmor.d/local/README.
/run/systemd/journal/dev-log rw,

Ensuite on lance la commande qui recharge seulement ça

apparmor_parser -r /etc/apparmor.d/usr.sbin.named

et voilà :)

Après installation de debian 9 et mise à jour en debian 9.1, impossible de redémarrer la VM.

Solution ⇒ https://forum.proxmox.com/threads/lxc-start-fails-unsupported-debian-version-9-1.35860/

--- /usr/share/perl5/PVE/LXC/Setup/Debian.pm.orig    2017-07-22 08:57:59.495838723 -0700
+++ /usr/share/perl5/PVE/LXC/Setup/Debian.pm    2017-07-22 08:53:18.607049610 -0700
@@ -28,7 +28,7 @@
     $version = $1;
 
     die "unsupported debian version '$version'\n"
-    if !($version >= 4 && $version <= 9);
+    if !($version >= 4 && $version <= 9.1);
 
     my $self = { conf => $conf, rootdir => $rootdir, version => $version };

Voir ou sont monté les VM

# losetup 
NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE
/dev/loop0         0      0         0  0 /var/lib/vz/images/101/vm-101-disk-1.raw
/dev/loop1         0      0         1  0 /var/lib/vz/images/150/vm-150-disk-1.raw
/dev/loop2         0      0         1  0 /var/lib/vz/images/201/vm-201-disk-1.raw

Ensuite vous pouvez soit les monter pour accéder aux fichiers, soit faire un fsck

fsck /dev/loop0

Un utilitaire pour gérer les containers LXC dans un terminal

USAGE: pct <COMMAND> [ARGS] [OPTIONS]
       pct clone <vmid> <newid> -experimental <boolean> [OPTIONS]
       pct create <vmid> <ostemplate> [OPTIONS]
       pct destroy <vmid>
       pct list 
       pct migrate <vmid> <target> [OPTIONS]
       pct resize <vmid> <disk> <size> [OPTIONS]
       pct restore <vmid> <ostemplate> [OPTIONS]
       pct template <vmid> -experimental <boolean> [OPTIONS]

       pct config <vmid>
       pct set <vmid> [OPTIONS]

       pct delsnapshot <vmid> <snapname> [OPTIONS]
       pct listsnapshot <vmid>
       pct rollback <vmid> <snapname>
       pct snapshot <vmid> <snapname> [OPTIONS]

       pct resume <vmid>
       pct shutdown <vmid> [OPTIONS]
       pct start <vmid> [OPTIONS]
       pct stop <vmid> [OPTIONS]
       pct suspend <vmid>

       pct console <vmid>
       pct cpusets 
       pct df <vmid>
       pct enter <vmid>
       pct exec <vmid> [<extra-args>]
       pct fsck <vmid> [OPTIONS]
       pct mount <vmid>
       pct pull <vmid> <path> <destination> [OPTIONS]
       pct push <vmid> <file> <destination> [OPTIONS]
       pct status <vmid> [OPTIONS]
       pct unlock <vmid>
       pct unmount <vmid>

       pct help [<cmd>] [OPTIONS]

exemple: lister les VM

pct list

entrer à l’intérieur d’une VM

pct enter 101

ouvrir la console d’une VM (pour sortir de la console, Ctrl+a q)

pct console 101

Par exemple, j’ouvre aptitude, ça met 4 plombe, je lance un truc nodejs, ca met 8 plombe.

Par magie, en désactivant le SWAP, on retrouve la rapidité normal du système.

sudo swapoff -a

J’ai voulu test en créant un cluster puis en m’apercevant que fallait monter un vpn entre 2 proxmox.. bref. Mais que vois-je ? pas de bouton pour supprimer le cluster !!

Heureusement, voici les commandes

systemctl stop pve-cluster
systemctl stop corosync
pmxcfs -l
rm /etc/pve/corosync.conf
rm /etc/corosync/*
killall pmxcfs
systemctl start pve-cluster

Bizarrement, proxmox n’est plus disponible dans les os pré-installé de soyoustart, je vais devoir l’installer à la main sur une Debian 10

Au préalable, il va falloir bien partitionner son serveur en n’oubliant pas LVM

• /dev/sda1 20 Go (/)
• /dev/sda2 4096 Go (swap)
• /dev/sda3 500 Go (lvm) /var/lib/vz
• /dev/sda4 1.4To (lvm) /backup

laisser un peu d’espace disque pour LVM, sinon, je ne sais pas pourquoi mais ça bug..

Ensuite il faut suivre le tuto officiel ⇒ https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Buster

Petite particularité soyoustart, il y a un cloud config à modifier pour ne pas qu’il écrase le fichier /etc/hosts à chaque reboot

vi /etc/cloud/cloud.cfg

Commenter la ligne suivante dans le cloud_init_modules

# - update_etc_hosts

et modifiez la ligne suivante à la fin du fichier

manage_etc_hosts: True

en

manage_etc_hosts: False

Redémarrez et supprimez ensuite les anciens kernel en 4.xx

Convertissez votre partition en lvm-thin

// pour cela, on le supprime
root@proxmox6:/# umount /var/lib/vz
root@proxmox6:/# lvremove vg/vz
Do you really want to remove active logical volume vg/vz? [y/n]: y
  Logical volume "vz" successfully removed

// on le recrée avec 99% de l'espace dispo pour lui laisser 1% pour faire son business..
root@proxmox6:/# lvcreate -l +99%FREE -n data vg
WARNING: ext4 signature detected on /dev/vg/data at offset 1080. Wipe it? [y/n]: y
  Wiping ext4 signature on /dev/vg/data.
  Logical volume "data" created.
root@proxmox6:/# lvconvert --type thin-pool vg/data
  Thin pool volume with chunk size 256.00 KiB can address at most 63.25 TiB of data.
  WARNING: Converting vg/data to thin pool's data volume with metadata wiping.
  THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Do you really want to convert vg/data? [y/n]: y
  Converted vg/data to thin pool.

// on modifie le fstab pour pas monter le volume thin-pool
UUID=21bf4e05-83a4-452d-a927-093e5b1ea506       /       ext4    defaults        0       1
UUID=822a0a6d-46fb-45de-bd8d-3eb386323977       /backup ext4    defaults        0       0
#UUID=74d12ded-edf6-42be-9c75-b6784909c283      /var/lib/vz     ext4    defaults        0       0
UUID=18245d31-414d-4339-b13d-70b730fc109f       swap    swap    defaults        0       0
UUID=2d1cff2c-f4a0-4455-a694-b2e06191aa71       swap    swap    defaults        0       0
UUID=3c2be4e9-eec4-49aa-8148-121f6151c3aa       swap    swap    defaults        0       0

On se retrouve ensuite avec un proxmox 6 tout neuf. L’espace disque total utilisé est de 2.7Go

Maintenant que tout est installé, il va falloir configurer 2, 3 trucs dans l’interface web.

Sélectionnez votre serveur proxmox puis allez dans Système / Réseau

Créer un “Linux Bridge” vmbr0 en saisissant votre ip (commande ip a pour la connaitre) votre passerelle (commande route -n pour la connaitre) et le ports du bridge qui est votre carte réseau (eno1 par exemple)

Ensuite, redémarrez votre proxmox.

Toujours dans Système, Certificats permet d’ajouter un certificat ssl pour votre https. Ca reste assez intuitif

Dans la partie Disques / LVM nous devrions retrouver nos 2 groupes vg et vg1

Allons dans LVM-Thin ou nous devons retrouver data

Cliquez sur Datacenter puis Stockage.

Ajouter un LVM-thin avec un nom, le volume groupe (vg) le pool data devrait apparaitre et ce stockage stockera uniquement les image disques et conteneurs.

Ajouter un répertoire pour le backup (ici /backup)

Après avoir checké avec la commande

pve6to7

Suivre la procédure sur https://pve.proxmox.com/wiki/Upgrade_from_6.x_to_7.0

sed -i 's/buster\/updates/bullseye-security/g;s/buster/bullseye/g' /etc/apt/sources.list
sed -i -e 's/buster/bullseye/g' /etc/apt/sources.list.d/pve-install-repo.list
apt update
apt dist-upgrade

Ensuite, je n’avais pas fait attention à ça

update-initramfs: Generating /boot/initrd.img-5.15.131-1-pve

gzip: stdout: No space left on device
E: mkinitramfs failure gzip 1
update-initramfs: failed for /boot/initrd.img-5.15.131-1-pve with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/pve-kernel-5.15.131-1-pve.postinst line 19.
dpkg: error processing package pve-kernel-5.15.131-1-pve (--configure):
 installed pve-kernel-5.15.131-1-pve package post-installation script subprocess returned error exit status 2
Setting up libboost-iostreams1.74.0:amd64 (1.74.0-9) ...
Setting up libsigc++-2.0-0v5:amd64 (2.10.4-2) ...
Setting up aptitude-common (0.8.13-3) ...
dpkg: dependency problems prevent configuration of pve-kernel-5.15:
 pve-kernel-5.15 depends on pve-kernel-5.15.131-1-pve; however:
  Package pve-kernel-5.15.131-1-pve is not configured yet.

dpkg: error processing package pve-kernel-5.15 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of proxmox-ve:
 proxmox-ve depends on pve-kernel-5.15; however:
  Package pve-kernel-5.15 is not configured yet.

dpkg: error processing package proxmox-ve (--configure):
 dependency problems - leaving unconfigured
Setting up libcwidget4:amd64 (0.5.18-5) ...
Setting up aptitude (0.8.13-3) ...
update-alternatives: using /usr/bin/aptitude-curses to provide /usr/bin/aptitude (aptitude) in auto mode
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for libc-bin (2.31-13+deb11u7) ...
Errors were encountered while processing:
 pve-kernel-5.15.131-1-pve
 pve-kernel-5.15
 proxmox-ve
E: Sub-process /usr/bin/dpkg returned an error code (1)

et le reboot s’est mal passé…

Obligé de rebooter sur un live rescue

mount /dev/mapper/system--mdjrx-root /mnt
mount /dev/sda1 /mnt/boot
for name in proc sys dev ; do mount --bind /$name /mnt/$name; done

chroot /mnt

relancer les commandes apt dist-upgrade et constater que rien ne fonctionne…

Finalement, ce qui a fonctionner

umount /boot
fsck.ext4 -p -c -f /dev/sda1
/dev/sda1: Updating bad block inode.
/dev/sda1: 362/51000 files (1.4% non-contiguous), 152848/203776 blocks

apt dist-upgrade
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 5.15.131-1-pve /boot/vmlinuz-5.15.131-1-pve
Setting up pve-kernel-5.15 (7.4-8) ...
Setting up proxmox-ve (7.4-1) ...

Plus d’erreurs.

Après un reboot, j’ai eu droit à ça

Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

donc reboot sur un ancien kernel et

update-initramfs -u -k 5.15.131-1-pve 

update-initramfs: Generating /boot/initrd.img-5.15.131-1-pve
gzip: stdout: No space left on device
E: mkinitramfs failure gzip 1
update-initramfs: failed for /boot/initrd.img-5.15.131-1-pve with 1.


df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       188M  138M   36M  80% /boot

il n’y a donc pas assez d’espace sur la partition de /boot

Faisons le ménage en cherchant avec grub les kernel installé

dpkg --list | grep kernel

en supprimant les paquets obsolètes

apt purge nom_du_paquet

et en supprimant à la main les fichiers resté dans /boot de la même version supprimé

On relance ensuite les 2 commandes qui vont bien

oot@proxmox202009:/boot# update-initramfs -u -k 5.15.131-1-pve 
update-initramfs: Generating /boot/initrd.img-5.15.131-1-pve
Running hook script 'zz-proxmox-boot'..
Re-executing '/etc/kernel/postinst.d/zz-proxmox-boot' in new private mount namespace..
No /etc/kernel/proxmox-boot-uuids found, skipping ESP sync.
root@proxmox202009:/boot# df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       188M  134M   41M  77% /boot

root@proxmox202009:/boot# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.15.131-1-pve
Found initrd image: /boot/initrd.img-5.15.131-1-pve
Found linux image: /boot/vmlinuz-5.4.203-1-pve
Found initrd image: /boot/initrd.img-5.4.203-1-pve
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
done

On reboot. Et là… encore un problème. Le système boot bien, tout fonctionne sauf l’accès à internet.

Et oui il était écrit en petit dans la doc ( https://pve.proxmox.com/wiki/Upgrade_from_6.x_to_7.0#Check_Linux_Network_Bridge_MAC ) que debian 11 allait changer tout seul l’adresse MAC du bridge et comme le bridge communique avec l’hebergeur via l’adresse MAC, ben ça ne fonctionne pas.

donc, faire un

ip -c link

pour récupérer l’adresse mac de votre interface réseau (ou la récupérer dans votre interface admin de votre hébergeur) et rajouter dans le /etc/network/interfaces la ligne

hwaddress 00:00:00:00:00

on restart le réseau

systemctl restart networking

Et ça marche !! (enfin l’hyperviseur, pour les LXC y’a encore du boulot)

Et ça fait plaisir de voir que je ne suis pas le seul à avoir eu des problèmes → https://blog.zwindler.fr/2021/07/19/les-soucis-que-jai-rencontre-en-upgradant-proxmox-ve-7/

Sur un LXC avec une debian 11, se connecter en ssh était super long

Dans les log du LXC je voyais ceci

Jun 19 14:41:43 zabbix dbus-daemon[78]: [system] Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
Jun 19 14:41:43 zabbix sshd[1013861]: pam_systemd(sshd:session): Failed to create session: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms)

En redémarrant le service concerné, j’ai vu qu’il ne fonctionnait pas

root@lxc:/var/log# systemctl restart systemd-logind
Job for systemd-logind.service failed because the control process exited with error code.
See "systemctl status systemd-logind.service" and "journalctl -xe" for details.

root@lxc:/var/log# systemctl status systemd-logind
● systemd-logind.service - User Login Management
     Loaded: loaded (/lib/systemd/system/systemd-logind.service; static)
     Active: failed (Result: exit-code) since Wed 2024-06-19 14:43:27 UTC; 15s ago
       Docs: man:sd-login(3)
             man:systemd-logind.service(8)
             man:logind.conf(5)
             man:org.freedesktop.login1(5)
    Process: 1013940 ExecStart=/lib/systemd/systemd-logind (code=exited, status=226/NAMESPACE)
   Main PID: 1013940 (code=exited, status=226/NAMESPACE)
        CPU: 5ms

juin 19 14:43:27 zabbix systemd[1]: systemd-logind.service: Scheduled restart job, restart counter is at 5.
juin 19 14:43:27 zabbix systemd[1]: Stopped User Login Management.
juin 19 14:43:27 zabbix systemd[1]: systemd-logind.service: Start request repeated too quickly.
juin 19 14:43:27 zabbix systemd[1]: systemd-logind.service: Failed with result 'exit-code'.
juin 19 14:43:27 zabbix systemd[1]: Failed to start User Login Management.

La solution trouvé sur le net consiste à masquer le service…

root@zabbix:/var/log# systemctl mask systemd-logind
Created symlink /etc/systemd/system/systemd-logind.service → /dev/null.

 mask UNIT...
           Mask one or more units, as specified on the command line. This will link these unit files to /dev/null, making it impossible to start them. This is a
           stronger version of disable, since it prohibits all kinds of activation of the unit, including enablement and manual activation. Use this option with
           care. This honors the --runtime option to only mask temporarily until the next reboot of the system. The --now option may be used to ensure that the units
           are also stopped. This command expects valid unit names only, it does not accept unit file paths.