Depuis 2 heures, la mémoire s'écroule en 20 minutes et Jeedom crashe

Non aucun reboot ne sera nécessaire.

Reboot « nécessaire » quand :

  • passage à une version majeure de ProxMox (par exemple ici ProxMox 8). Et dans ce cas il ne suffit pas de cliquer sur upgrade pour lancer la migration
  • nouveau kernel Linux. Et encore dans ce cas le redémarrage n’est pas obligatoire : seulement nécessaire si tu veux utiliser le nouveau kernel . Ici ça pourrait régler ton problème néanmoins .

Linux n’est pas Windows : il est très rare de devoir rebooter .

2 avis différents !
Alors je peux voir comment s’il y a un nouveau kernel ?

J’ai regardé différents tuto tout à l’heure dont un qui parlait des ajouts de la 7.4 par rapport à la 7.3 et le présentateur rebootait. Mais il avait installé un nouveau kernel 6 au lieu de 5 je crois…
Dans les images, je vois le pve-kernel-5.15 qui doit passer de 7.2.14 à 7.4.11 mais rien qui me fasse penser à un nom de kernel Debian.
Merci

Pourtant nous sommes cohérents.
Le nouveau kernel pourrait corriger ton problème. Et dans ce cas il faut rebooter.

Pve-kernel c’est bien le kernel Linux (il est spécifique à Proxmox ce n’est pas celui des distributions Debian).

OK, merci, j’essaierai ça demain. Trop tard ce soir, car si tout va bien il y en a pour 5 minutes, mais en cas de malchance…

Mais bon ! Le firmware ou la dernière version qui corrige tout les problèmes, je suis trop âgé pour croire encore au père Noël (encore que lui, qui sait ?). C’est que j’en ai installé des firmwares ou des nouvelles versions miracle.

La version que j’utilise n’a jamais connu le moindre problème jusqu’à hier, soit plus d’un an et, sans que quoi que ce soit ait été modifié, ni sur l’hôte, ni sur Jeedom, d’un seul coup d’un seul la mémoire allouée n’est plus reconnue et ce même après plus de 5 reboots… ??
Personne n’a la moindre idée de ce qui a pu causer ces crashes ? N’a été confronté ou a été au courant que quelqu’un a été confronté à ce problème ?
Merci

La version que j’utilise n’a jamais connu le moindre problème jusqu’à hier, soit plus d’un an et, sans que quoi que ce soit ait été modifié, ni sur l’hôte, ni sur Jeedom, d’un seul coup d’un seul la mémoire allouée n’est plus reconnue et ce même après plus de 5 reboots… ??
Personne n’a la moindre idée de ce qui a pu causer ces crashes ? N’a été confronté ou a été au courant que quelqu’un a été confronté à ce problème ?

Je ne veux pas être rabat joie, lorsque l’on s’adresse à un développeur ou à un forum ou à un support pour un problème sur une version datant d’un an et plus, la réponse est toujours la même " as tu fait les mises à jour de ton Os et de l’application? dans la négative fait ta mise à jour, si tu as toujours le problème, je regarderais".
Pourquoi :

  • En un an et plus les programmes ont énormément évolués + les corrections de bugs + correction de sécurité
  • Le développeur ne va pas changer sa plateforme de travail et de tests pour un seul problème sur une
    vieille version.
  • Le développeur ne modifiera pas le code d’un vieux programme, c’est perdre son temps sauf pour une très bonne raison

En tout cas dans le monde professionnel c’est comme ça.

1 « J'aime »

De plus Proxmox 7 = Debian 11 et Proxmox 8 = Debian 12 ce qui change significativement le contexte en termes de comportement .

Hello
Bon, pour l’instant je suis passé sans encombres à 7.4. Reboot nécessaire. Mais Jeedom a redémarré sans encombre, du moins avec toute sa mémoire (ouf).
Je vais retrouver une machine de spare pour tester la migration v8. Ca m’a ll’air compliqué, en particulier la sauvegarde de la configuration Proxmox. En vieux routier de mini systèmes IBM et de Windows tous serveurs, j’ai toujours du mal avec les outils Linux qui ne prévoient pas une simple option de sauvegarde de leur configuration.
D’après ce que j’ai lu sur la doc Proxmox, il faut aller sur tous les répertoires en ligne de commande et les sauvegarder en ligne de commande.
Si quelqu’un peut me confirmer qu’il n’y a pas d’autre solution.
Merci d’avance

Il y a des scripts pour le backup de l’host.

J’utilise celui-ci (et déjà testé la restauration).

Merci, mais outre le fait que je suis tellement nul que je n’ai jamais compris comment on pouvait récupérer des outils Linux sur Github et comment les intégrer, il semble que les liens donnés sur cette page soient inaccessibles. Je vois bien le détail des scripts de sauvegarde et de celui de restauration, mais je ne sais pas comment l’intégrer dans ProxMox
Qui plus est l’auteur dit qu’il n’a pas testé depuis longtemps, et un message émet des doutes sur la restauration depuis une version supérieure.
Je vais chercher un peu, mais si ta patience devant mes hésitations n’est pas à bout…
Merci

Le lien d’origine du script est plutôt celui-ci en effet :

Testé il y a un an. L’auteur est une référence pour admin proxmox .

Sinon celui-ci encore plus simple à mettre en œuvre (Proxmox VE Host Backup) :

Site de référence pour les scripts Proxmox.

Attention :

The scripts will only work with PVE7 Version 7.4-13 or later, or PVE8 Version 8.1.1 or later.

Le principe est toujours le même : un dump des répertoires système qui vont bien.

OK Merci, je vais regarder.
Pour l’instant je suis en train d’esayer de migrer en V8.1 sur une machine de spare. J’ai suivi point par point toutes les instructions de la doc ProxMox, même les lignes de commandes Ceph que je ne crois pas posséder.
J’ai lancé un apt dist-upgrade qui s’est bloqué sur un répertoire où il n’avait pas les droits (je suis en root bien sûr)
J’ai relancé un apt comme indiqué avec un __fix-missing (ou quelque chose commeca) puis relancé apt dist-upgrade.

Et là je suis bloqué sur cette fenêtre. Plus rien n’avance et je ne sais pas quoi taper :

adduser (3.130) unstable; urgency=low

  deluser's --no-preserve-root option is deprecated, and it will be
  removed after Debian bookworm. deluser will in the future completely
  refuse to delete the root user. If you want to delete root, you need
  to use other tools.

  We are planning to deprecate and remove the GROUPHOMES and LETTERHOMES
  configuration options. They help big installations, but nowadays those
  installations are probably using a directory service like LDAP and Active
  Directory to manage their users and do not use adduser anyway. If you're
  using one of these options and want them to stay, please write that to
  #1025623 and let us know. Some kind of help and committment, for example
  verified autopkgtest scripts, would be appreciated and make it easier for
  us to keep the feature around.

  We are planning to deprecate and remove the QUOTAUSER configuration
  option. If you're using this, please write that to #1026898 and let us
  know. Some kind of help and committment, for example verified autopkg
  testscripts, would be appreciated and make it easier for us to keep
  the feature around.

  There have been some changes to --disabled-password and --disabled-login,
  documented in adduser(8). Maintainers using these options with adduser
  --system in their maintainer scripts should review their scripts and
  check whether the default is enough and the options can be removed.

  The --gecos option is being renamed to --comment to get aligned with
  passwd's terminology. --gecos will continue to work throughout the
  bookworm cycle.

  The NEWS entry for 3.124, shown below, was added to give more explanation
  about the addition of the users group as a supplementary group to a newly
  created user. This change was inconsistently documented in adduser(8),
  this inconsistency was fixed in adduser 3.130.

 -- Marc Haber <mh+debian-packages@zugschlus.de>  Sun, 25 Dec 2022 17:11:31 +0100

adduser (3.124) unstable; urgency=medium

  As pointed out in #678615, adduser has behaved somewhat inconsistently
  in the past, using the users group (GID 100) only if USERGROUPS was set
  to the non-default 'no'. This has been changed as documented in
  adduser.conf(5): If USERGROUPS is yes, the newly created user will now
  be added as a supplementary group; if USERGROUPS is no, users will be the
  primary group. If you want to restore the old behavior, set USERGROUPS=yes,
  leave USERS_GROUP empty and set USERS_GID to "-1".

:

Quelqu’un aune idée ? Je suis loin du sujet de départ, mais bloqué pour bloqué…
Merci

Si c’est une migration, tu avais bien lancé le script pve7to8 avant ? Tout était OK ?
Car je ne comprends pas comment tu ne peux pas avoir les droits si tu es root .

Pour le message essaye au hasard entrée ou q.

Le Q a fonctionné (Enter j’avais déjà testé).
Il est allé au bout, chaque fois qu’il ma demandé, j’ai choisi de garder la configuration précédente - j’ai essayé de lui demander les différences, mais vu que je ne sais pas à quoi ça sert…
A la fin j’ai eu :

Processing triggers for initramfs-tools (0.142) ...
update-initramfs: Generating /boot/initrd.img-6.5.13-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.
System booted in EFI-mode but 'grub-efi-amd64' meta-package not installed!
Install 'grub-efi-amd64' to get updates.
Processing triggers for pve-ha-manager (4.0.3) ...
root@monproxmoxsec://etc/apt#

Heureusement qu’il y a de la doc parce qu’il fallait aussi lancer :

[ -d /sys/firmware/efi ] && apt install grub-efi-amd64

Je n’ose imaginer le sort des incompétents Linux comme moi s’il se passe quelque chose de non prévu dans la doc.
A priori, je suis en 8.1. Reste à espérer que le jour où je le ferai sur la machine de prod, il ne se passe rien de pire.

Je ne sais pas ce qu’il est advenu des choses à faire moyennement urgente ou pas urgente… Dont ce répertoire (en fait il contenait peut être une adresse Internet) auquel je n’avais pas accès…
Ca, c’est le genre de choses qui n’est jamais dans les tutos
merci

En fait le plus simple est souvent de sauvegarder les VM et LXC, et faire une nouvelle installation de zéro, directement avec l’iso Proxmox.

Surtout n’oublie pas le script pve7to8 avant de migrer. Il t’indique tous les problèmes potentiels avant migration .

Ca aurait marché sans le package EFI.
Tu aurais pu aussi mettre ton UEFI en mode BIOS.
C’est toujours un peu le bazar les EFI sous Linux du fait des clés de chiffrage uniquement validés pour Microsoft (ou comment tenter de verrouiller le marché des PC).

Pour savoir quoi répondre pour les fichiers de configuration, c’est indiqué dans la doc de migration …
https://pve.proxmox.com/wiki/Upgrade_from_7_to_8

J’ai retrouvé une partie des messages :

Reading package lists... Done
E: Failed to fetch https://enterprise.proxmox.com/debian/pve/dists/bookworm/InRelease  401  Unauthorized [IP: 51.91.38.34 443]
E: The repository 'https://enterprise.proxmox.com/debian/pve bookworm InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

Après quoi j’ai relancé ; apt dist-upgrade

Ça n’a rien à voir.
C’est le repository proxmox entreprise que tu avais saisi alors que tu n’as pas de souscription. Du coup c’est bien fait ça a été automatiquement désactivé .
C’est également indiqué dans la doc de migration :wink:

Oui, bien sûr, je l’avais lancé, c’est dans la doc… Tout était vert !

Je suis sûr que tout est dans la doc, mais il y a des centaines d’instructions, et on vous dit : si vous avez ci, si vous avez ça… Moi, je ne sais pas si je l’ai ou pas vu que je ne sais pas de quoi il s’agit. 95 % des utilisateurs n’ont rien, alors ils devraient faire une doc pour l’utilisateur de base non payant, et une autre technique pour ceux qui ont des options et comprennent au moins un peu de quoi on leur parle.
Enfin, à cheval donné on ne regarde pas la dent, dit le dicton… Mais ces installs prise de tête sont la raison pour laquelle je ne me suis jamais aventuré dans Linux sauf sous la contrainte. Ceci dit, les installs trapues de Microsoft sont aussi de vraies prises de tête, avec des docs très fouillis et souvent approximative.
En tous cas merci de ton aide

C’est la liste des modifications entre deux versions majeurs. Le changelog en somme. Il faut appuyer sur la touche espace pour faire défiler la totalité des informations jusqu’au bout. Puis effectivement, comme l’a mentionné Madcow, appuyer sur « q » pour quitter. Il est fortement recommandé de lire et comprendre ce qui y est mentionné, car, certes, les migrations Debian et par conséquent Proxmox se passent généralement bien, mais lorsqu’il y a un changement majeur dans la gestion d’un logiciel, avoir lu et compris les informations qui sont regroupées dans ce changelog évitent de perdre un temps important à errer sur Google ou les forums à la recherche du « pourquoi ça ne fonctionne plus comme avant ».

À tout hasard, pour ceux qui pourraient être lire ce fil de discussion en ayant à l’esprit de vouloir virtualiser Jeedom sans vouloir ou avoir les connaissances pour gérer un Proxmox (ce qui n’est pas simple si on veut vraiment maîtriser cette solution de virtualisation), je rappelle l’existence des NAS qui fournissent une solution de virtualisation simple et efficace ne nécessitant pas de mettre les mains dans la gestion de l’hyperviseur puisque ça se gère en clics clics clics lorsque le constructeur du NAS met à jour la couche logicielle.

Hello
En ce qui me concerne, Jeedom serait depuis longtemps sur un de mes 2 Nas Synology dont effectivement Virtual Machine Manager est une merveille surtout en BTRFS, si :
1°) Les Synology avaient plus de 2 ports USB, assez capricieux, peu tolérants avec les HUB USB, surtout USB3. J’ai besoin de 4 ports USB pour mes clés Jeedom, et j’ai aussi besoin de brancher des disques de sauvegarde USB, plus l’onduleur. C’est la critique principale. Les HUB USB que j’ai testés jusqu’à présent m’ont causé pas mal de soucis
2°) Les Synology ont besoin de redémarrer assez régulièrement pour leurs mises à jour, bien plus souvent qu’une machine ProxMox dédiée. Et en moyenne, ils le font la nuit, et n’aiment pas trop arrêter les machines virtuelles et en particulier Jeedom. Du moins pour les tests que j’ai fait.

En plus, même par rapport à mon DS923+ et ses 32 Gb de mémoire, le processeur du NUC est bien plus performant, les disques bien plus rapides. Peut être que Jeedom n’en a pas besoin, mais à la 4e ou 5ème machine virtuelle, plus les containers Dockers (pardon, c’est Container manager maintenant), ça peut commencer à compter…

C’est à cause de ça que j’ai installé ProxMox. Mais au moins il sauvegarde ses VMs sur le NAS, c’est déjà ça !