Re: Grosse fatigue
On 23/09/2022 09:41, BERTRAND Joël wrote: Bonjour à tous, Ce matin, une fois de plus, systemd a cru bon tuer X et, incidemment, toutes les applications en cours (me contraignant à repartir de la sauvegarde de la nuit, je n'ai heureusement perdu qu'une heure de travail). Ce ne serait encore pas trop grave s'il ne s'arrêtait pas au milieu du chemin, tuant X mais surtout pas les terminaux de contrôles dépendants de X : Une suggestion en rapport est peut-être d'utiliser et d'améliorer mon https://github.com/bstarynk/misc-basile/blob/master/sync-periodically.c Par ailleurs, je cherche des partenaires intéressés par http://refpersys.org/ - contactez moi alors aussi sur mon mél professionnel (au CEA, LIST): basile.starynkevi...@cea.fr -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
Re: Grosse fatigue
Bonjour, Le 23/09/2022 à 14:24, Haricophile a écrit : Le Fri, 23 Sep 2022 12:42:41 +0200, "antoine.valmer" a écrit : eth0, wlan0... c'est explicite, et pratique pour réparer un réseau défaillant. Le nouveau nommage est explicite aussi, c'est juste pas fait pour les humains. Ce que je reproche n'est pas la logique du truc, mais ce fait qui effectivement rend complexe ce qui était simple du point de vue de l'humain et du contrôle de ce qu'on fait. Je suppose que ça va avec les automatisations, le branchement à chaud, les gros parcs et toussa, mais il y a une perte de l'idée qu'on doit contrôler sa machine et pas l'inverse. On se simplifie la vie en rendant les choses plus complexes. C'est un paradoxe. l'ordre eth0, eth1... était fonction de la façon dont étaient détectées les cartes par le kernel lors du boot (ordre de chargement des modules). Pour que cela soit stable c'est à l'aide des règles udev que se faisait l'association nom/@MAC à la première détection de la carte. En cas de changement de carte réseau fallait supprimer la règle dans /etc/udev/rules.d/70-persistent-net.rules pour retrouver eth0 disponible. C'était un peu galère pour affecter des noms spécifiques en fonction de la position des cartes dans un PC (déploiement d'images). Le nouveau nommage fait ça tout seul. C'est plus stable et pas nécessairement plus complexe (source https://debian-facile.org/viewtopic.php?pid=264958#p264958) : wl = WireLess en= EtherNet p1 = bus PCI n° 1 (non présent si contrôleur sur la carte mère) s0 = Slot n° 0 f0 = Fonction n° 0 (quand le périphérique contient plusieurs fonctions) Pour retourner aux anciens noms, modifier le fichier /etc/default/grub et ajouter les options net.ifnames=0 et biosdevname=0 à la ligne GRUB_CMDLINE_LINUX=(https://memo-linux.com/debian-9-retrouver-les-noms-des-interfaces-reseaux-eth/). Puis update-grub en root devrait le faire. Bonne soirée, Luc.
Re: Grosse fatigue
Le Fri, 23 Sep 2022 12:42:41 +0200, "antoine.valmer" a écrit : > eth0, wlan0... c'est explicite, et pratique pour réparer un réseau > défaillant. Le nouveau nommage est explicite aussi, c'est juste pas fait pour les humains. Ce que je reproche n'est pas la logique du truc, mais ce fait qui effectivement rend complexe ce qui était simple du point de vue de l'humain et du contrôle de ce qu'on fait. Je suppose que ça va avec les automatisations, le branchement à chaud, les gros parcs et toussa, mais il y a une perte de l'idée qu'on doit contrôler sa machine et pas l'inverse. On se simplifie la vie en rendant les choses plus complexes. C'est un paradoxe.
Re: Grosse fatigue
Le 23/09/2022 à 12:42, antoine.valmer a écrit : On Friday 23 September 2022 12:34:01 BERTRAND Joël wrote: Attention, les ports sont renommés automatiquement sauf s'il y a des règles udev spécifiques. Cela fut rigolo au passage de l'ancien système au nouveau (et si j'ai pu récupérer eth1 et eth2, eth0 n'a rien voulu savoir et se retrouve lan0). Hello, on peut tout à fait modifier le nom des ports eth, wlan..., que ces noms abscons non explicites (ens...) attribués d'office par Debian et Ubuntu : https://waytolearnx.com/2019/05/renommer-linterface-par-defaut-ens33-a-lancienne-eth0-sur-ubuntu-16-04.html eth0, wlan0... c'est explicite, et pratique pour réparer un réseau défaillant. Bonne journée. Et au moins ça change pas sur une mise à jour de udev/systemd comme ça m'est arrivé.
Re: Grosse fatigue
On Friday 23 September 2022 12:34:01 BERTRAND Joël wrote: > Attention, les ports sont renommés automatiquement sauf s'il y a des > règles udev spécifiques. Cela fut rigolo au passage de l'ancien système > au nouveau (et si j'ai pu récupérer eth1 et eth2, eth0 n'a rien voulu > savoir et se retrouve lan0). Hello, on peut tout à fait modifier le nom des ports eth, wlan..., que ces noms abscons non explicites (ens...) attribués d'office par Debian et Ubuntu : https://waytolearnx.com/2019/05/renommer-linterface-par-defaut-ens33-a-lancienne-eth0-sur-ubuntu-16-04.html eth0, wlan0... c'est explicite, et pratique pour réparer un réseau défaillant. Bonne journée.
Re: Grosse fatigue
Erwann Le Bras a écrit : > > > >> Bonjour >> >> Le 23/09/2022 à 10:31, Erwann Le Bras a écrit : >> [...] >>> chez moi usrmerge n'est pas installé et Debian ne m'a jamais obligé à >>> l'installer. >>> J'ai /usr dans /, je n'ai jamais vu l'intéret de les séparer >>> >>> Je suis en Debian stable (11.5). >> >> Si tu as fait un upgrade d'une version antérieure, pas d'usrmerge. >> Installation fraîche: usrmerge installé. > > > ah bah voilà. Ça doit être comme mes ports réseaux qui s'appellent > encore "lo0", "eth0" et "eth1" sur mon serveur. > > sur le serveur c'est la même install depuis Debian 8, qui a changé de > disques et de machine. Attention, les ports sont renommés automatiquement sauf s'il y a des règles udev spécifiques. Cela fut rigolo au passage de l'ancien système au nouveau (et si j'ai pu récupérer eth1 et eth2, eth0 n'a rien voulu savoir et se retrouve lan0).
Re: Grosse fatigue
Bonjour Le 23/09/2022 à 10:31, Erwann Le Bras a écrit : [...] chez moi usrmerge n'est pas installé et Debian ne m'a jamais obligé à l'installer. J'ai /usr dans /, je n'ai jamais vu l'intéret de les séparer Je suis en Debian stable (11.5). Si tu as fait un upgrade d'une version antérieure, pas d'usrmerge. Installation fraîche: usrmerge installé. ah bah voilà. Ça doit être comme mes ports réseaux qui s'appellent encore "lo0", "eth0" et "eth1" sur mon serveur. sur le serveur c'est la même install depuis Debian 8, qui a changé de disques et de machine. amitiés, -- Erwann
Re: Grosse fatigue
Bonjour Le 23/09/2022 à 10:31, Erwann Le Bras a écrit : [...] chez moi usrmerge n'est pas installé et Debian ne m'a jamais obligé à l'installer. J'ai /usr dans /, je n'ai jamais vu l'intéret de les séparer Je suis en Debian stable (11.5). Si tu as fait un upgrade d'une version antérieure, pas d'usrmerge. Installation fraîche: usrmerge installé. -- Daniel
Re: Grosse fatigue
Bonjour, Erwann Le Bras a écrit : > chez moi usrmerge n'est pas installé et Debian ne m'a jamais obligé à > l'installer. > J'ai /usr dans /, je n'ai jamais vu l'intéret de les séparer C'est ce matin que j'ai constaté qu'il était autoritairement poussé dans testing. Jusqu'ici, je m'en suis fort bien passé. Personnellement, je n'ai jamais compris qu'il faille les regrouper, surtout dans l'embarqué où l'on aime bien avoir une partition / minimale en ro. Là, une corruption de /usr met le système par terre (et dans l'embarqué, une telle corruption peut arriver assez vite).
Re: Grosse fatigue
Le 23/09/2022 à 10:31, Erwann Le Bras a écrit : [...] chez moi usrmerge n'est pas installé et Debian ne m'a jamais obligé à l'installer. J'ai /usr dans /, je n'ai jamais vu l'intéret de les séparer Je suis en Debian stable (11.5). [...] Bonjour, De ce que je comprends, ce sera problématique en Stable à partir de Debian 12 Bookworm: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636 et en Unstable Sid, le support a déjà été abandonné ces jours derniers: https://lists.debian.org/debian-devel-announce/2022/09/msg1.html
Re: Grosse fatigue
Michel Memeteau a écrit : > Bonjour , > > > Je pensais que Systemd-OOM était désactivé sur debian ? Je préférerais que ce soit un truc comme ça, mais non. Dans les logs, j'ai juste systemd qui tue la session, comme ça, presque gratuitement. Et concernant la session, c'est une sortie propre, comme si je la quittais normalement (avec les programmes qui se ferment les uns après les autres). Seuls les bash restent orphelins et consomment du temps CPU. Il n'y a pas de problème de mémoire. La machine embarque 64 Go de mémoire (et 96 Go de swap) et ça doit pouvoir faire fonctionner FreeCAD sans se bauger. Ce n'est pas une histoire de carte graphique non plus (la carte embarque 8 Go de mémoire). Mais ça m'arrive aussi en utilisant firefox sans que la mémoire ne soit occupée plus que ça. Le pire, c'est qu'il me tue la session sans aller jusqu'au bout. Mais de temps en temps, il me tue aussi les répliques de base PostgreSQL, ou ypbind... Ça pue l'accès réseau non maîtrisé de systemd. J'ai déjà fait un rapport d'erreur il y a de longs mois sans obtenir de correctif.
Re: Grosse fatigue
Pierre-Elliott Bécue a écrit : > Une ligne de log, quelque chose qui montre que systemd a bien tué X > et éventuellement pourquoi, ou bien on est juste sur yet another > mail de baseless FUD? Sep 23 08:49:31 hilbert systemd[1]: Stopping User Manager for UID 0... Sep 23 08:49:31 hilbert systemd[577146]: Activating special unit Exit the Session... Sep 23 08:49:31 hilbert systemd[577146]: Removed slice User Core Session Slice. Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Main User Target. Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Basic System. Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Paths. Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Sockets. Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Timers. Sep 23 08:49:31 hilbert systemd[577146]: Closed D-Bus User Message Bus Socket. Sep 23 08:49:31 hilbert systemd[577146]: Closed GnuPG network certificate management daemon. Sep 23 08:49:31 hilbert systemd[577146]: Closed Socket to launch DrKonqi for a systemd-coredump crash. Sep 23 08:49:31 hilbert systemd[577146]: Closed GCR ssh-agent wrapper. Sep 23 08:49:31 hilbert systemd[577146]: Closed GNOME Keyring daemon. ... Sep 23 08:49:31 hilbert systemd[577146]: Reached target Shutdown. Sep 23 08:49:31 hilbert systemd[577146]: Finished Exit the Session. Sep 23 08:49:31 hilbert systemd[577146]: Reached target Exit the Session. Sep 23 08:49:31 hilbert systemd[1]: user@0.service: Deactivated successfully. Sep 23 08:49:31 hilbert systemd[1]: Stopped User Manager for UID 0. Sep 23 08:49:31 hilbert systemd[1]: Stopping User Runtime Directory /run/user/0... Sep 23 08:49:31 hilbert systemd[1]: run-user-0.mount: Deactivated successfully. Sep 23 08:49:31 hilbert systemd[1]: user-runtime-dir@0.service: Deactivated successfully. Sep 23 08:49:31 hilbert systemd[1]: Stopped User Runtime Directory /run/user/0. Sep 23 08:49:31 hilbert systemd[1]: Removed slice User Slice of UID 0. ... Au passage, systemd va jusqu'à tuer ypbind : Sep 23 08:49:46 hilbert systemd[1]: ypbind.service: Main process exited On se demande bien pourquoi. Et il relance le tout comme si rien ne s'était passé (enfin, là, parce que par moment il tue ypbind sans le redémarrer, ce qui pose des problèmes amusants sur une machine diskless en NIS/NFS). De toute façon, la question n'est pas là. systemd décide pour une raison inconnue de clôturer la session. Naturellement, il n'y a AUCUNE erreur avant la première ligne de log. Je veux donc me séparer à la fois de cette saleté qui est une brique pour essuyer les plâtres et d'usrmerge. Je précise que ce genre de chose arrive tous les deux ou trois jours et que c'est gavant.
Re: Grosse fatigue
bonjour
je n'ai jamais constaté ce comportement :
sur mon ordi il arrive -rarement, mais je ne sais pas pourquoi- que
lightdm parte en vrille et je dois le redémarrer par 'systemctl restart
lightdm' depuis la console locale en root.
Ma session utilisateur est fermée, et les les processus correctement
stoppés.
("ps -fu //" ne retourne rien, rien de suspect dans
l'activité CPU/RAM au bout d'un instant)
Je peux me reconnecter sans soucis et relancer mes applis.
Certes, je perds le travail non sauvegardé mais je me suis habitué à
sauvegarder souvent mon travail.
chez moi usrmerge n'est pas installé et Debian ne m'a jamais obligé à
l'installer.
J'ai /usr dans /, je n'ai jamais vu l'intéret de les séparer
Je suis en Debian stable (11.5).
Ce matin, une fois de plus, systemd a cru bon tuer X et, incidemment,
toutes les applications en cours (me contraignant à repartir de la
sauvegarde de la nuit, je n'ai heureusement perdu qu'une heure de
travail). Ce ne serait encore pas trop grave s'il ne s'arrêtait pas au
milieu du chemin, tuant X mais surtout pas les terminaux de contrôles
dépendants de X :
amitiés,
--
Erwann
Re: Grosse fatigue
Bonjour , Je pensais que Systemd-OOM était désactivé sur debian ? Le 23/09/2022 à 09:41, BERTRAND Joël a écrit : Bonjour à tous, Ce matin, une fois de plus, systemd a cru bon tuer X et, -- -- Michel Memeteau Ekimia ( https://ekimia.fr ) Directeur tel:+33(0)624808051 Address : 620 avenue de la roche fourcade 13400 Aubagne France
Re: Grosse fatigue
BERTRAND Joël wrote on 23/09/2022 at 09:41:24+0200: > Bonjour à tous, > > Ce matin, une fois de plus, systemd a cru bon tuer X et, incidemment, > toutes les applications en cours (me contraignant à repartir de la > sauvegarde de la nuit, je n'ai heureusement perdu qu'une heure de > travail). Ce ne serait encore pas trop grave s'il ne s'arrêtait pas au > milieu du chemin, tuant X mais surtout pas les terminaux de contrôles > dépendants de X : > > top - 09:03:05 up 3 days, 53 min, 19 users, load average: 48,54, 25,93, > 14,15 > ... > KiB Mem : 65562712 total, 5298100 libr, 24405232 util, 3078024 tamp/cache > KiB Éch : 10066329+total, 71624128 libr, 29039160 util. 7755600 dispo Mem > ... > 76791 bertrand 20 0 10108 2468 1660 R 76,2 0,0 13:08.04 > bash >2418 bertrand 20 09988 1792 1648 R 75,2 0,0 13:06.32 > bash > 79309 bertrand 20 09988 2432 1640 R 75,2 0,0 13:30.25 > bash > 307331 bertrand 20 09988 2604 1812 R 75,2 0,0 13:06.87 > bash > 422686 bertrand 20 0 10104 2564 1768 D 75,2 0,0 13:08.79 > bash > 475927 bertrand 20 0 10252 2508 1688 R 75,2 0,0 13:08.96 > bash > 477249 bertrand 20 0 10172 2460 1652 R 75,2 0,0 13:29.82 > bash >2114 bertrand 20 0 10108 2016 1680 R 74,3 0,0 13:09.14 > bash >2122 bertrand 20 0 10108 2056 1716 D 74,3 0,0 13:09.67 > bash >3684 bertrand 20 09988 1808 1672 R 74,3 0,0 13:02.70 > bash >4944 bertrand 20 09988 1892 1732 R 74,3 0,0 13:02.49 > bash > 77325 bertrand 20 09988 2580 1780 R 74,3 0,0 13:10.73 > bash > 103189 bertrand 20 0 10808 3064 1712 R 74,3 0,0 13:02.45 > bash > 309027 bertrand 20 09988 2496 1708 R 74,3 0,0 12:59.61 > bash > 429272 bertrand 20 0 10104 2532 1736 R 74,3 0,0 13:08.76 > bash > > en laissant des zombies partout, des fichiers à moitié ouverts et > corrompus ! Je ne vous ai pas mis toute la liste, la charge est > uniquement due aux bash qui tournent la poignée dans le coin sans rien > faire puisqu'ils ne sont plus associés à un terminal. Le swap de s'est > rempli qu'_après_ que X a été tué par systemd. > > Cette machine n'a aucun problème matériel. Je l'ai testée en long, en > large et en travers. > > J'avoue que ça commence sérieusement à me fatiguer. systemd se permet > de tuer la session X sans aucune raison (rien dans les logs sinon un > truc du style systemd: kill X). Je tourne en testing à jour pour tout un > tas de raisons que je n'expliciterai pas ici. > > Sur ces entrefaites, je passe ne console texte et je m'aperçois que > trois paquets ne peuvent s'installer. Comment ça ? Pour mémoire, > "unattented-upgrade" _N_'est _PAS_ configuré parce que j'ai une version > de KiCAD et une autre de FreeCAD en rolling releases (et > qu'accessoirement lorsque le truc décide de mettre à jour LaTeX, le > réseau rame durant plusieurs heures parce que la station de travail est > diskless). La seule chose qui est faite, c'est un apt update la nuit. > Les mises à jour automatique mettent un bazar là-dedans et je préfère > toujours les passer à la main quand je sais que je ne dérangerai personne. > > Je tente donc un apt dist-upgrade et là, je vois que le truc veut > m'installer usrmerge. Mais pour tout un tas de raisons, JE NE VEUX PAS > DE CETTE SALETÉ. Pourquoi ? Toute mon installation est diskless et/ou > embarqué et usrmerge met un bazar incommensurable là-dedans. Pour une > installation diskless, ça multiplie les latences (regardez un peu le > trafic sur un NFS/TCP, c'est effarant) et dans l'embarqué où / et /usr > ne sont pas sur les mêmes partitions, ça oblige à des contorsions pour > espérer démarrer correctement jusqu'au bout. > > Est-il possible de refuser usrmerge ? Ou faut-il que j'envisage de > réinstaller cette machine sous autre chose, autre chose qui n'utilise ni > systemd vus les dysfonctionnements du truc ni usrmerge ? D'ailleurs > existe-t-il encore une distribution Linux sans usrmerge ? > > À titre personnel, je ne comprends toujours pas que Debian cherche à > imposer systemd vue la fiabilité de la chose dès lors qu'on n'est plus > sur un poste de travail avec un disque en local (la gestion des timeouts > réseau ou des accès réseau concurrents au sens large est... rigologène > pour rester poli et surtout non reproductible d'une version à l'autre). > Quant à ursmerge, dans l'embarqué, on préférerais avoir un répertoire > /rescue à la NetBSD et un /usr séparé pour toujours pouvoir démarrer un > système minimal même lorsque la partition /usr est plantée (/ pouvant > rester en lecture seule). Là, si /usr est corrompue pour une raison ou > pour une autre, on n'est même pas sûr de réussir à démarrer le système > (sauf à se retrouver dans un shell embarqué dans le fumeux initramfs). > > Merci pour toutes vos suggestions, > > JKB Une ligne de log,
Grosse fatigue
Bonjour à tous, Ce matin, une fois de plus, systemd a cru bon tuer X et, incidemment, toutes les applications en cours (me contraignant à repartir de la sauvegarde de la nuit, je n'ai heureusement perdu qu'une heure de travail). Ce ne serait encore pas trop grave s'il ne s'arrêtait pas au milieu du chemin, tuant X mais surtout pas les terminaux de contrôles dépendants de X : top - 09:03:05 up 3 days, 53 min, 19 users, load average: 48,54, 25,93, 14,15 ... KiB Mem : 65562712 total, 5298100 libr, 24405232 util, 3078024 tamp/cache KiB Éch : 10066329+total, 71624128 libr, 29039160 util. 7755600 dispo Mem ... 76791 bertrand 20 0 10108 2468 1660 R 76,2 0,0 13:08.04 bash 2418 bertrand 20 09988 1792 1648 R 75,2 0,0 13:06.32 bash 79309 bertrand 20 09988 2432 1640 R 75,2 0,0 13:30.25 bash 307331 bertrand 20 09988 2604 1812 R 75,2 0,0 13:06.87 bash 422686 bertrand 20 0 10104 2564 1768 D 75,2 0,0 13:08.79 bash 475927 bertrand 20 0 10252 2508 1688 R 75,2 0,0 13:08.96 bash 477249 bertrand 20 0 10172 2460 1652 R 75,2 0,0 13:29.82 bash 2114 bertrand 20 0 10108 2016 1680 R 74,3 0,0 13:09.14 bash 2122 bertrand 20 0 10108 2056 1716 D 74,3 0,0 13:09.67 bash 3684 bertrand 20 09988 1808 1672 R 74,3 0,0 13:02.70 bash 4944 bertrand 20 09988 1892 1732 R 74,3 0,0 13:02.49 bash 77325 bertrand 20 09988 2580 1780 R 74,3 0,0 13:10.73 bash 103189 bertrand 20 0 10808 3064 1712 R 74,3 0,0 13:02.45 bash 309027 bertrand 20 09988 2496 1708 R 74,3 0,0 12:59.61 bash 429272 bertrand 20 0 10104 2532 1736 R 74,3 0,0 13:08.76 bash en laissant des zombies partout, des fichiers à moitié ouverts et corrompus ! Je ne vous ai pas mis toute la liste, la charge est uniquement due aux bash qui tournent la poignée dans le coin sans rien faire puisqu'ils ne sont plus associés à un terminal. Le swap de s'est rempli qu'_après_ que X a été tué par systemd. Cette machine n'a aucun problème matériel. Je l'ai testée en long, en large et en travers. J'avoue que ça commence sérieusement à me fatiguer. systemd se permet de tuer la session X sans aucune raison (rien dans les logs sinon un truc du style systemd: kill X). Je tourne en testing à jour pour tout un tas de raisons que je n'expliciterai pas ici. Sur ces entrefaites, je passe ne console texte et je m'aperçois que trois paquets ne peuvent s'installer. Comment ça ? Pour mémoire, "unattented-upgrade" _N_'est _PAS_ configuré parce que j'ai une version de KiCAD et une autre de FreeCAD en rolling releases (et qu'accessoirement lorsque le truc décide de mettre à jour LaTeX, le réseau rame durant plusieurs heures parce que la station de travail est diskless). La seule chose qui est faite, c'est un apt update la nuit. Les mises à jour automatique mettent un bazar là-dedans et je préfère toujours les passer à la main quand je sais que je ne dérangerai personne. Je tente donc un apt dist-upgrade et là, je vois que le truc veut m'installer usrmerge. Mais pour tout un tas de raisons, JE NE VEUX PAS DE CETTE SALETÉ. Pourquoi ? Toute mon installation est diskless et/ou embarqué et usrmerge met un bazar incommensurable là-dedans. Pour une installation diskless, ça multiplie les latences (regardez un peu le trafic sur un NFS/TCP, c'est effarant) et dans l'embarqué où / et /usr ne sont pas sur les mêmes partitions, ça oblige à des contorsions pour espérer démarrer correctement jusqu'au bout. Est-il possible de refuser usrmerge ? Ou faut-il que j'envisage de réinstaller cette machine sous autre chose, autre chose qui n'utilise ni systemd vus les dysfonctionnements du truc ni usrmerge ? D'ailleurs existe-t-il encore une distribution Linux sans usrmerge ? À titre personnel, je ne comprends toujours pas que Debian cherche à imposer systemd vue la fiabilité de la chose dès lors qu'on n'est plus sur un poste de travail avec un disque en local (la gestion des timeouts réseau ou des accès réseau concurrents au sens large est... rigologène pour rester poli et surtout non reproductible d'une version à l'autre). Quant à ursmerge, dans l'embarqué, on préférerais avoir un répertoire /rescue à la NetBSD et un /usr séparé pour toujours pouvoir démarrer un système minimal même lorsque la partition /usr est plantée (/ pouvant rester en lecture seule). Là, si /usr est corrompue pour une raison ou pour une autre, on n'est même pas sûr de réussir à démarrer le système (sauf à se retrouver dans un shell embarqué dans le fumeux initramfs). Merci pour toutes vos suggestions, JKB
