====== Proxmox ======
===== Doc =====
Bel article sur proxmox 5 => https://community.capensis.org/t/nouveautes-installation-et-configuration-de-proxmox-5-2/133
===== Petites commandes à connaitre =====
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
===== Définition (vieille version) =====
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.
===== Installation =====
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
===== Configuration =====
==== Cas de figure : une seule adresse ip public + un LAN ====
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
==== Cas de figure : Une adresse ip WAN pour chaque VM ====
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.
===== Backup & restore =====
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.
===== Partager un répertoire =====
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
#!/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.
===== Templates supplémentaires =====
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.
==== Proxmox 5 ====
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
====== Proxmox 4 ======
===== Bug =====
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à :)
===== Bug2 =====
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 };
===== Commande =====
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 [ARGS] [OPTIONS]
pct clone -experimental [OPTIONS]
pct create [OPTIONS]
pct destroy
pct list
pct migrate [OPTIONS]
pct resize [OPTIONS]
pct restore [OPTIONS]
pct template -experimental [OPTIONS]
pct config
pct set [OPTIONS]
pct delsnapshot [OPTIONS]
pct listsnapshot
pct rollback
pct snapshot [OPTIONS]
pct resume
pct shutdown [OPTIONS]
pct start [OPTIONS]
pct stop [OPTIONS]
pct suspend
pct console
pct cpusets
pct df
pct enter
pct exec []
pct fsck [OPTIONS]
pct mount
pct pull [OPTIONS]
pct push [OPTIONS]
pct status [OPTIONS]
pct unlock
pct unmount
pct help [] [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
====== Proxmox 5 ======
===== sur une VM non LXC, c'est lent =====
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
===== cluster =====
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
====== Proxmox 6 ======
===== Installation =====
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..
{{ :linux:proxmox6_partitionnement.jpg |}}
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
===== Configuration =====
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)
===== upgrade 6 to 7 =====
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/
===== Autres bidouilles =====
==== Login ssh long LXC ====
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.