09_01 - la création de la VM le 260909

VM Debian sur le NAS SasNexte — poste de l'univers Jux

Procédure établie le 09/09/2026. Machine installée et opérationnelle le jour même. V2 du 09/09/2026 — redémarrage éprouvé, réservation DHCP posée, correction de l'erreur sur le gestionnaire de connexion.

Ce qui change par rapport à la V1. Le §7 corrige une affirmation fausse : LightDM est installé, contrairement à ce que la V1 annonçait. Le §9 est neuf — la procédure de redémarrage et sa validation réelle. Le §4 insiste sur le démontage de l'ISO, qui avait été omis. Deux points du « reste à faire » sont clos : la réservation DHCP et la question ufw.

1. Raison d'être

Ce poste n'existe pas pour l'ubiquité, mais pour l'étanchéité. Il s'agit de cesser de mélanger deux univers sur une même machine.

	PC NEXTE (Windows)	VM Debian (NAS)
Univers	Alteris / NEXTE — professionnel	Jux — personnel
BookStack	`bookstack.alteris.ovh`	`bookstack.juxjux.ovh`
Serveur d'appui	VPS Alteris `79.137.14.202`	VPS Jux `51.77.141.54`
Outils	QGIS, LibreOffice, PostGIS, pièces de mission	Firefox, Thunderbird, FileZilla, Calibre, Claude Code

Un seul MCP BookStack par machine. C'est ce qui rend structurellement impossible de publier une procédure Alteris dans le BookStack perso, ou l'inverse — au lieu d'une discipline à tenir à chaque page.

Règle à ne pas relâcher. Pas de partage de mission NEXTE monté dans la VM, pas de coffre Alteris, pas de clé SSH vers 79.137.14.202. Un « juste un petit accès » suffit à rendre la séparation décorative.

2. Prérequis matériels — le seul point bloquant

Le DS220+ embarque un Celeron J4025 (2 cœurs, 2 threads). Le facteur limitant est la RAM.

	Valeur constatée
RAM totale	5776 Mo (2 Go soudés + barrette 4 Go ajoutée en 2023)
Consommé par DSM	~1160 Mo
Volume1	Btrfs — exigé par VMM — 1,4 To libres
DSM	7.4

VMM réserve la mémoire statiquement : les 3 Go sont retirés à DSM en permanence tant que la VM tourne, qu'elle travaille ou non. Il n'y a pas de ballooning dynamique. Le plafond utile est d'environ 3,5 Go, DSM gardant un socle incompressible de 1,5 à 2 Go. Au-delà, c'est DSM qui swappe — et comme le disque virtuel est sur ce même NAS, tout ralentit ensemble.

Sur 2 Go alloués la VM tiendrait aussi : à l'usage réel, elle consomme ~~369~~360 Mo au repos, et 473 Mo avec le bureau XFCE ouvert. Le dimensionnement se fait sur le pic, pas sur la somme des applications — elles ne tournent jamais ensemble.

3. Création de la machine virtuelle

Virtual Machine Manager n'était pas installé : Centre de paquets → Virtual Machine Manager, puis créer un stockage sur volume1.

À la première ouverture, DSM propose d'ouvrir les ports 30200-30300 dans le pare-feu. Accepter, puis restreindre la règle au sous-réseau local (Panneau de configuration → Sécurité → Pare-feu, source 192.168.1.0 / 255.255.255.0). Ces ports n'ont aucune raison d'être joignables de l'extérieur.

Paramètres retenus

Écran	Réglage
Nom	`debian-jux`
Processeurs	2
Mémoire	3 Go
Carte vidéo	`vmvga` (seul choix)
Type de machine	`PC` (châssis i440fx, BIOS legacy)
Disque	40 Go, contrôleur VirtIO SCSI, réclamation d'espace cochée
Réseau	Default VM Network, VirtIO
Micrologiciel	Legacy BIOS, pas UEFI
Disposition clavier	`fr`
Port série	Désactiver — inutile, et il a brouillé le diagnostic
Contrôleur USB	Désactivé
Autostart	Oui

Démarrer depuis Disque virtuel

Réclamation d'espace : c'est le TRIM, à ne pas confondre avec l'allocation à la demande (que VMM applique déjà par défaut). Sans elle, le fichier disque croît au fil des apt et n'en redescend jamais.

VirtIO SCSI expose le disque en /dev/sda, pas /dev/vda.

Adresse MAC. VMM en génère une localement administrée — ici 02:11:32:25:c6:e8, reconnaissable à son préfixe 02:. Elle est stable tant que l'interface réseau existe, mais supprimer et recréer la carte réseau dans VMM la change — et rend caduque, en silence, la réservation DHCP du §8.

4. Installation de Debian 13

L'image

Téléchargée directement par le NAS, ce qui évite de faire transiter 755 Mo par le PC :

cd '/volume1/Iso VM'
wget -c -O debian-13.6.0-amd64-netinst.iso \
  https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-13.6.0-amd64-netinst.iso
sha256sum debian-13.6.0-amd64-netinst.iso
curl -s https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/SHA256SUMS | grep netinst

Les deux sommes doivent être identiques.

Le mode d'installation

Prendre « Graphical install », pas « Install ». Le mode texte impose de saisir des numéros dans des listes qui défilent hors écran, et la console noVNC de VMM gère mal le clavier. Le mode graphique donne la souris : tous les choix se font au clic.

« Graphical install » ne désigne que le mode d'affichage — le premier écran reste le choix de la langue, où l'on prend « French — Français ».

Les réponses qui comptent

Écran	Réponse
Nom de machine	`jux-debian`
Domaine	vide
Mot de passe root	(voir remarque ci-dessous)
Partitionnement	Assisté – disque entier → `sda` → tout dans une seule partition
Miroir	France, `deb.debian.org`, pas de mandataire
Sélection des logiciels	décocher tout sauf serveur SSH et utilitaires usuels du système
GRUB	Oui → `/dev/sda`

Pas de LVM : sur un disque virtuel il n'apporte rien, on agrandit le disque dans VMM. Pas de chiffrement : la VM démarre automatiquement au boot du NAS et réclamerait une passphrase en console à chaque fois.

~~Ne pas cocher Xfce dans la sélection des logiciels : cette case installe aussi un gestionnaire de connexion, dont on ne veut pas (voir §6).~~

Remarque sur le mot de passe root. Le laisser vide fait installer sudo et place l'utilisateur dans le groupe. En définissant un mot de passe root — ce qui a été fait ici — sudo n'est pas installé, et le script de post-installation doit être lancé via su - avec le nom d'utilisateur en argument. sudo reste ensuite protégé par mot de passe : aucune automatisation à distance ne peut l'utiliser.

🔴 Démonter l'ISO — l'étape qu'on oublie

Avant le redémarrage final : démonter l'ISO dans les paramètres de la VM (Action → Modifier → Autres → Fichier ISO pour le démarrage → Démonté),.

~~sinon~~

Ça ~~elle~~n'a ~~reboote~~pas été fait le 09/09 — l'ISO est restée montée toute la journée sans qu'on s'en aperçoive, parce que Démarrer depuis : Disque virtuel masque le symptôme : la VM démarre sur le disque et tout paraît normal.

Le danger n'est pas immédiat, il est différé. Le jour où le disque devient non amorçable — GRUB cassé, disque plein — la VM ne s'arrête pas sur une erreur : elle démarre l'~~installeur.~~installeur Debian. Sur une machine sans écran, avec autostart activé, c'est le scénario où l'on formate sans le voir.

Le vérifier fait partie de la mise en service, au même titre que le reste. Le démontage est accepté à chaud, VM allumée.

5. LE PIÈGE — la console meurt au démarrage

Symptôme. Après l'installation, l'écran se fige systématiquement sur :

/dev/sda1: clean, 40622/2485504 files, 552845/9938432 blocks
[  5.812838] systemd-ssh-generator[255]: Failed to query local AF_VSOCK CID
[  5.958389] systemd[1]: Finished modprobe@efi_pstore.service
[  6.941405] ACPI: bus type drm_connector registered

Plus rien ensuite. Aucune invite de connexion, Ctrl+Alt+F2 sans effet, et la machine n'apparaît pas sur le réseau.

Cause. Trente millisecondes après drm_connector registered, le pilote de la carte vidéo vmvga prend la main sur l'écran et tue la console. Le système, lui, démarre parfaitement : SSH répond, le réseau monte, l'invite de connexion existe — elle n'est simplement plus affichée nulle part.

Correctif — dans /etc/default/grub :

GRUB_CMDLINE_LINUX_DEFAULT="nomodeset"

puis update-grub. nomodeset interdit le kernel modesetting et garde la console en VGA texte de bout en bout.

Retirer quiet en même temps, et ne jamais le remettre. C'est lui qui rend le diagnostic impossible : entre les messages du noyau et l'invite de connexion, l'écran reste muet, et rien ne distingue un démarrage figé d'un démarrage silencieux.

nomodeset ne coûte rien à l'usage. Vérifié le 09/09 : le bureau XFCE s'affiche normalement dans la console VMM malgré nomodeset. Seule l'accélération graphique est perdue, dont on n'a de toute façon pas l'emploi ici.

Deux fausses pistes, pour ne pas les refaire

Le port série. Plausible — on l'avait activé, et une console redirigée vers ttyS0 produit exactement ce gel. Mais la ligne GRUB ne contenait aucun console=ttyS0. Vérifier avant de supposer.
Un blocage du démarrage. Écarté par un détail : le compteur de fichiers affiché par fsck augmentait d'un démarrage à l'autre (40500 puis 40622). Un système qui ne démarre pas n'écrit rien.

Comment atteindre GRUB

La console VMM n'existe que si la VM tourne — impossible de l'ouvrir « avant ». Il faut garder la fenêtre de console ouverte (bouton ~~Connect~~Connecter), démarrer la VM depuis DSM, cliquer ~~Connect~~Connecter aussitôt et maintenir Maj : GRUB affiche alors son menu et suspend le ~~décompte.~~décompte (GRUB_TIMEOUT=5).

Sur la ligne « Debian GNU/Linux », appuyer sur e — pas Entrée — descendre jusqu'à la ligne linux /boot/vmlinuz…, aller en fin de ligne, ajouter nomodeset et supprimer quiet, puis Ctrl+X.

Une correction faite ainsi ne vaut que pour ce démarrage. Elle ne devient permanente qu'une fois écrite dans /etc/default/grub et suivie d'un update-grub — voir le §9, où cette distinction a failli passer inaperçue.

Les entrées « recovery mode » sont inutilisables si le compte root est verrouillé ~~(mot de passe vide à l'installation)~~ : le shell de secours refuse de s'ouvrir.

6. Post-installation

Script : 260909-postinstall_vm_debian_jux_v2.sh. Idempotent, environ 20 minutes et 1,5 Go de paquets.

su -
bash /home/julien/260909-postinstall_vm_debian_jux_v2.sh julien 2>&1 \
  | tee /home/julien/260909-postinstall.log

L'argument julien est nécessaire : sans sudo, le script ne peut pas deviner pour quel utilisateur il travaille.

Étape	Contenu
0	GRUB : `nomodeset` ajouté, `quiet` retiré, fichier d'origine sauvegardé en `.avant-nomodeset-260909`
1	Locale `fr_FR.UTF-8`, clavier français, fuseau Europe/Paris
2-3	Mise à jour, socle (`sudo`, `curl`, `git`, `ripgrep`…)
4	XFCE ~~sans gestionnaire de connexion~~
5	xrdp + xorgxrdp, `~/.xsession`, règle polkit
6	Firefox ESR, Thunderbird, FileZilla, Calibre (+ paquets de langue)
7	Node.js, puis Claude Code via npm avec préfixe `~/.npm-global`
8	Syncthing, ufw (22, 3389, 22000, 21027)

Deux partis pris

~~Pas de gestionnaire de connexion.~~ ~~La VM n'a pas d'écran ; c'est xrdp qui ouvre la session. Cela évite le conflit « session déjà ouverte » qui empoisonne les installations XFCE + xrdp, et économise environ 150 Mo.~~

L'interface web de Syncthing n'écoute qu'en ~~local.~~local (127.0.0.1:8384). L'exposer sur le réseau donnerait un accès sans mot de passe à tout le contenu synchronisé.

7. LightDM — ce qui est réellement installé

Correction de la V1. Elle affirmait « XFCE sans gestionnaire de connexion », en présentant comme un fait ce qui n'était qu'une intention de conception. C'est faux.

Constaté le 09/09 après redémarrage :

lightdm.service — active (running), enabled
Paquets : lightdm, lightdm-gtk-greeter, light-locker
Cible systemd par défaut : graphical.target

LightDM a été tiré comme dépendance par le méta-paquet XFCE. L'étape 4 du script ne l'a jamais empêché.

Décision retenue : on garde LightDM

Le raisonnement, contre-intuitif mais solide : la console VMM de DSM est du noVNC — c'est-à-dire un accès navigateur qui existe déjà, sans rien installer.

Ce que la console DSM affiche dans le navigateur Avec LightDM (retenu) écran de connexion, puis le bureau XFCE complet Sans LightDM jux-debian login: — un terminal texte

Garder LightDM donne donc « navigateur → bureau graphique » gratuitement. Coût : environ 150 Mo au repos, sans conséquence sur 3 Go.

⚠️ La contrainte qui vient avec : une seule session à la fois

C'est exactement le conflit que la V1 disait vouloir éviter, et il est réel.

xrdp fonctionne ici en backend Xorg. Si une session XFCE est déjà ouverte sur :0 (la console) et qu'on lance une session RDP avec le même utilisateur, on tombe sur « session déjà ouverte » : écran noir ou reprise erratique. light-locker ajoute sa part — la session RDP peut revenir verrouillée sans moyen commode de la déverrouiller.

Console ou RDP, jamais les deux. Se déconnecter proprement de XFCE (Déconnexion, pas seulement fermer la fenêtre VMM) avant de basculer d'un accès à l'autre.

Si l'on change d'avis

Revenir au design initialement prévu tient en une commande, réversible :

sudo systemctl disable --now lightdm && sudo systemctl set-default multi-user.target

8. Accès

Bureau à distance — RDP

mstsc /v:192.168.1.10

Accepter l'avertissement de certificat (auto-signé), puis sur l'écran xrdp : Session = Xorg, utilisateur julien.

Depuis un mobile : Microsoft Remote Desktop, même adresse.

C'est l'accès le plus fluide pour travailler — nettement plus réactif que le noVNC de DSM.

Bureau dans le navigateur — console DSM

http://192.168.1.82:5000 → Virtual Machine Manager → debian-jux → Connecter.

Fonctionne depuis n'importe quel navigateur du réseau local, sans client à installer. Utile aussi quand le réseau de la VM est en panne : la console voit l'écran même si SSH et RDP ne répondent plus.

Ce n'est pas un lien direct — il faut passer par DSM. Pour un vrai signet vers le bureau, la piste est Apache Guacamole (passerelle RDP/VNC vers HTML5) sur le VPS Jux, mais seulement après WireGuard : exposé seul sur Internet, Guacamole devient la porte d'entrée de la VM.

Réservation DHCP — faite le 09/09

L'adresse est réservée sur la Freebox v8 (Ultra), passerelle 192.168.1.254 :

Paramètres de la Freebox → DHCP → Baux Statiques
  jux-debian   02:11:32:25:C6:E8   →   192.168.1.10

Éprouvée au redémarrage du §9 : la VM est revenue sur .10.

Si un jour la VM réapparaît sur une autre adresse sans raison, le premier réflexe est de comparer la MAC réelle (ip link show ens3) à celle du bail : la recréation de la carte réseau dans VMM en génère une nouvelle.

RustDesk a— étéécarté

~~écarté.~~

L'infrastructure existe pourtant sur le VPS Jux (hbbs/hbbr, client enregistré, diode verte) mais n'a jamais donné de session exploitable — il échoue silencieusement, sans rien laisser d'exploitable pour diagnostiquer.

Pour ~~l'accès~~le ~~en déplacement,~~nomadisme, la voie retenue ~~est~~reste WireGuard sur le VPS Jux + RDP : le diagnostic y est binaire (wg show affiche un handshake, ou rien), les clients sont natifs partout, aucun port n'est à ouvrir sur la box — c'est la VM qui monte le tunnel ~~vers le VPS~~ — et le même tunnel sert ~~aussi~~ pour SSH et pour DSM.

Interface Syncthing

ssh -L 8385:127.0.0.1:8384 julien@192.168.1.10

puis http://127.0.0.1:8385.

Le port local est 8385 et non 8384 : le Syncthing du PC NEXTE occupe déjà ~~8384, et le tunnel échouerait sur~~ bind: Permission denied.8384. Les deux interfaces sont identiques à l'écran — vérifier le nom de l'appareil en haut à droite (jux-debian) avant de déclarer un partage.

8.9. ÉtatRedémarrage final— vérifiéprocédure et validation

Pourquoi ça ne va pas de soi

Le 09/09, la VM a tourné toute la journée sur un démarrage de 14:51 obtenu par édition manuelle de GRUB (Ctrl+X). Tout ce qui devait survivre à un redémarrage — GRUB persistant, ufw, configuration xrdp — a été écrit après ce démarrage, entre 15:02 et 15:12.

Autrement dit : la machine fonctionnait, mais rien ne prouvait qu'elle refonctionnerait. Une VM qui marche n'est pas une VM qui redémarre.

La procédure

Avant — deux préalables, dans cet ordre :

Réserver l'adresse dans le DHCP de la box (§8). Sans ça, on teste le redémarrage en gardant le seul facteur capable de faire perdre la machine. Vérifier Action → Modifier → Autres : Autostart = Oui, Démarrer depuis = Disque virtuel, et surtout ISO démontée (§4).

Pendant :

Ouvrir la console (bouton Connecter) et la garder à l'écran. Action → **Éteindre** — c'est l'arrêt ACPI propre, l'équivalent d'un appui bref sur le bouton d'alimentation. Pas Forcer l'arrêt, qui est la coupure de courant brutale, à réserver aux machines qui ne répondent plus. Attendre le statut Arrêté, puis Action → **Mettre sous tension**.

Le point de contrôle à l'écran : les messages du noyau doivent défiler au-delà de ACPI: bus type drm_connector registered. S'ils s'arrêtent là, nomodeset n'a pas tenu — voir §5.

Un instantané préalable (Action → Prendre un instantané) est possible et se supprime ensuite sans toucher la VM. Il n'a pas été jugé utile ici : la machine n'avait qu'un jour et tout son contenu est reproductible par le script du §6. Il prendra son sens quand elle contiendra des comptes Thunderbird et des données Syncthing.

Le contrôle après redémarrage

Depuis le PC NEXTE, en PowerShell (voir la remarque sur ssh.exe au §11) :

who -b ; cat /proc/cmdline
for u in ssh xrdp xrdp-sesman syncthing@julien ufw; do \
  printf "%-18s %-10s %s\n" "$u" "$(systemctl is-active $u)" "$(systemctl is-enabled $u)"; done
systemctl --failed --no-pager
ip -4 addr show ens3 | grep inet
systemd-analyze

is-enabled compte autant que is-active. Un service active mais disabled fonctionne aujourd'hui et disparaît au prochain démarrage — c'est précisément le genre d'écart qu'un test de redémarrage existe pour révéler.

Vérifier que le pare-feu filtre vraiment

ufw status exige root. On peut s'en passer : depuis le PC, comparer un port autorisé et un port qui ne l'est pas.

Test-NetConnection 192.168.1.10 -Port 22
Test-NetConnection 192.168.1.10 -Port 12345

refus immédiat (quelques dizaines de ms) sur le port fermé = aucun filtrage, les paquets atteignent la pile réseau qui répond RST expiration longue (plus de 20 s) = politique DROP active, les paquets sont ignorés sans réponse

Mesuré le 09/09 : 16 ms sur le port 22, 21 501 ms sur le port 12345. Le pare-feu filtre.

Résultat du test — 09/09/2026, 16:43

Point de contrôle	Constaté
~~Machine~~`/proc/cmdline`	`jux-debianro nomodeset`, pas de `192.168.1.10quiet`, ~~Debian~~— ~~13.6,~~la ~~noyau~~config ~~6.12.107~~persistante tient
~~Interface~~ssh, ~~réseau~~xrdp, xrdp-sesman, syncthing@julien	`ens3active` ~~(VirtIO)~~+ `enabled`
~~Services actifs~~ufw	~~ssh,~~`active` ~~xrdp,~~+ ~~syncthing@julien~~`enabled`, et filtre réellement
~~Ports~~Unités ~~ouverts~~en échec	~~22 et 3389 ; 8384 fermé de l'extérieur~~aucune
~~Applications~~Erreurs prioritaires au journal	~~Firefox ESR 140, Thunderbird 140, FileZilla 3.68, Calibre 8.5, XFCE 4.20~~aucune
~~Claude Code~~Adresse	2.`192.168.1.26610` — via la réservation

Durée 19,7 s (5,7 s noyau + 13,9 s espace utilisateur) RAM au repos ~~369~~360 Mo sur 2978

La question ufw laissée ouverte par la V1 est close : il n'y avait aucun bug. Le service apparaissait inactive parce qu'il avait été installé après le démarrage en cours. Un redémarrage suffisait à le montrer.

9.10. Reste à faire

~~1 ·~~ MCP BookStack perso, à déclarer dans la VM — jeton à créer sur bookstack.juxjux.ovh (profil → Jetons d'API ; le secret n'est affiché qu'une fois) :

claude mcp add -s user bookstack-jux \
  -e BOOKSTACK_BASE_URL=https://bookstack.juxjux.ovh/api \
  -e BOOKSTACK_API_TOKEN=ID:SECRET \
  -e MCP_TRANSPORT=stdio -- npx -y bookstack-mcp-server

Le suffixe /api est obligatoire, le jeton s'écrit id:secret.

2Jamais ~~· Réserver~~ 192.168.1.10 ~~dans~~sur le ~~DHCP~~PC deNEXTE — c'est ce que la ~~box,~~VM ~~sinon~~existe ~~l'adresse~~pour ~~bougera.~~empêcher.

~~3 ·~~ Comptes Thunderbird.

~~4 ·~~ WireGuard sur le VPS Jux 51.77.141.54. (différé) Apache Guacamole, après WireGuard, si le lien navigateur direct se confirme utile. Publier cette procédure dans bookstack.juxjux.ovh, depuis le Claude Code de la VM — donc après le point 1.

5Points ·clos ~~Vérifier~~depuis ~~ufw~~la V1 : sudoréservation DHCP (§8) et vérification ufw status verbose(§9). ~~Le pare-feu annonce~~ ~~« Firewall is active and enabled on system startup »~~ ~~et ses règles sont chargées, mais~~ systemctl is-active ufw ~~renvoie~~ inactive ~~— comportement connu de cette unité, non confirmé faute de droits root au moment du contrôle.~~

10.11. À retenir pour toute future VM Linux sur ce NAS

nomodeset est obligatoire avec la carte vmvga de VMM sous Debian 13. Sans lui, la machine paraît plantée alors qu'elle fonctionne ~~parfaitement.~~parfaitement — et il ne coûte rien : le bureau graphique s'affiche quand même.
Ne jamais laisser quiet : c'est la différence entre un diagnostic en deux minutes et une heure de tâtonnements.

Une correction passée dans GRUB au clavier ne survit pas au redémarrage. Elle n'est acquise qu'écrite dans /etc/default/grub puis suivie d'update-grub. Démonter l'ISO d'installation, et le vérifier. Le symptôme est masqué par l'ordre de démarrage ; le danger ne se manifeste que le jour où le disque ne démarre plus. Désactiver le port série : inutile, et il oriente le diagnostic sur une fausse piste. Mode graphique pour l'installeur, à cause du clavier de la console noVNC. VirtIO SCSI → /dev/sda, jamais /dev/vda. Redémarrer pour de vrai avant de déclarer une machine en service. Tant qu'elle n'a pas subi un cycle complet, on ne sait pas si elle est configurée — seulement qu'elle marche. Vérifier ce qui est installé, pas ce qu'on a voulu installer. LightDM était là malgré une procédure qui affirmait le contraire. systemctl status et dpkg -l tranchent ; la documentation, non. Depuis le PC NEXTE, SSH passe par %WINDIR%\System32\OpenSSH\ssh.exe en PowerShell, jamais par le ssh de Git Bash qui ne parle pas au ssh-agent de Windows. Et pour tout script distant un peu long, l'encoder en base64 — PowerShell 5.1 détruit les guillemets internes.