Mathieu Benoit
eb5e607e1e
« Table does not exist » : six lignes d'iptables et « code de retour 1 », après avoir déjà posé la strophe dans /etc/network/interfaces. Rien dans ce bruit ne dit qu'il faut redémarrer. L'hôte tournait le noyau cloud de Debian, qui est dépouillé de tout netfilter — aucun module NAT, ni legacy ni nft. Et le cas n'a rien d'exotique : c'est notre propre install_proxmox.sh qui le produit. Il pose le noyau Proxmox sans redémarrer, à raison — lancé par ssh, un reboot couperait la session et ferait passer l'installation pour un échec. Une Proxmox imbriquée fraîchement installée est donc TOUJOURS dans cet état. L'avertissement sur le noyau existait déjà, mais à la CONFIRMATION de l'hôte, et l'hôte est ensuite mémorisé : on revient des jours plus tard créer un pont, et plus personne ne rappelle rien. Le garde va donc là où la conséquence tombe, et AVANT toute écriture. Il interroge la table NAT elle-même et non le NOM du noyau — « -pve » est un indice, pas une preuve — puis nomme le noyau en cours, celui qui est posé, et la commande qui règle l'affaire. Le sommaire de déploiement le dit désormais aussi, tant qu'on lit encore l'écran plutôt qu'au bout d'un journal d'une heure. --- EN --- "Table does not exist": six lines of iptables and "exit code 1", after the stanza had already been written into /etc/network/interfaces. Nothing in that noise says a reboot is needed. The host was running Debian's cloud kernel, stripped of all netfilter — no NAT module, legacy or nft. And the case is not exotic: our own install_proxmox.sh produces it. It installs the Proxmox kernel without rebooting, rightly — run over ssh, a reboot would cut the session and make the install look failed. A freshly installed nested Proxmox is therefore ALWAYS in this state. The kernel warning already existed, but at host CONFIRMATION, and the host is then remembered: you come back days later to create a bridge and nothing reminds you. So the guard moves to where the consequence lands, and BEFORE any write. It asks the NAT table itself rather than the kernel's NAME — "-pve" is a hint, not a proof — then names the running kernel, the installed one, and the command that settles it. The deployment summary now says it too, while the screen is still being read rather than at the end of an hour-long log. Assisted-by: Claude Opus 5 |
||
|---|---|---|
| .. | ||
| auto_ask.py | ||
| database_manager.py | ||
| deploy_form_extras.py | ||
| deploy_form_lib.py | ||
| deploy_form_plan.py | ||
| kdbx_manager.py | ||
| logo_ascii.txt | ||
| migration_form.py | ||
| migration_stats.py | ||
| migration_status.py | ||
| migration_status_tui.py | ||
| proxmox_deploy_form.py | ||
| proxmox_menu.py | ||
| qemu_access.py | ||
| qemu_deploy.py | ||
| qemu_deploy_form.py | ||
| qemu_hardware.py | ||
| qemu_install.py | ||
| qemu_install_monitor.py | ||
| qemu_manage.py | ||
| qemu_menu.py | ||
| README.base.md | ||
| README.fr.md | ||
| README.md | ||
| source_todo.sh | ||
| textual_setup.py | ||
| todo.json | ||
| todo.py | ||
| todo_example.json | ||
| todo_file_browser.py | ||
| todo_i18n.py | ||
| todo_prefs.py | ||
| todo_telemetry.py | ||
| todo_upgrade.py | ||
| version_manager.py | ||
TODO is an assistant robot to use ERPLibre
Execute it with ./script/todo/todo.py or make todo.
For a new project, copy todo_example.json to private/todo/todo_override.json | private/todo/todo_override_private.json and edit it.
The mail/ package is the mail client reachable from Assistant > Mail:
several IMAP/SMTP accounts, a local cache, and a Textual TUI. See
../../doc/EMAIL.md.
Where the code lives
todo.py carries the menus and the general helpers. Everything around a
single subject sits in its own file, and the whole thing is assembled by
mixins on the TODO class — one file, one subject, its header states its
boundary.
| File | What it owns |
|---|---|
todo.py |
the menus, the configuration, the general helpers |
qemu_menu.py |
the QEMU/KVM menu, the image catalogue, the statistics |
qemu_deploy.py |
deciding then running a deployment |
qemu_install.py |
the recipes run inside a VM |
qemu_manage.py |
lifecycle, disks, hardware, cleanup, addresses |
qemu_access.py |
SSH, tunnels, consoles, Android emulator |
proxmox_menu.py |
the same, on a REMOTE Proxmox VE host |
The two deployment forms — libvirt here, Proxmox over there — ask the same questions, so they share a foundation rather than each holding a copy:
| File | What it owns |
|---|---|
deploy_form_lib.py |
pure logic (sizes, plan, totals, spec), the shared CSS, the resource-row factory, the progress view |
deploy_form_plan.py |
the plan's gestures: overrides, locks, copies, renaming, free values |
qemu_deploy_form.py |
what QEMU/KVM adds: desktops, tools, branches, install profiles |
proxmox_deploy_form.py |
what Proxmox adds: host, storage, bridge, VMID, address |
A form inherits PlanMixin and provides three hooks: which presets each
resource offers, the name a VM would fall back to, and what a lock freezes.
test_todo_deploy_form_lib.py fails if a form redefines a gesture the
foundation already carries — that is what keeps the architecture from drifting
back into two copies.