J'en ai 3 équivalents au MB155SP-B de chez Icy dock qui tournent sans pb depuis 15 ans.
Ce n'est pas silencieux, donc pensez à l'emplacement du serveur qui va héberger cela.
Aussi voir aussi cables sata et alim de bonne longueur.
Les tiroirs sont fournis avec le boitier et sont interchangeables avec les autres boitiers de la marque ( x2, x3, boitier usb).
Voici ce que j'ai pu trouver.
Je n'ai pas retrouvé de log de démarrage avant mise à jour.
Démarrage après upgrade
Aug 1013:20:20 ebox systemd-udevd[231]: /etc/systemd/network/99-default.link: No valid settings found in the [Match] section, ignoring file. To match all interfaces, add OriginalName=* in the [Match] section.
Aug 1013:20:20 ebox systemd[1]: Started Rule-based Manager for Device Events and Files.
Aug 1013:20:20 ebox systemd[1]: Starting Network Service...
Aug 1013:20:20 ebox systemd-udevd[236]: Using default interface naming scheme 'v247'.
Aug 1013:20:20 ebox systemd-networkd[237]: Enumeration completed
Aug 1013:20:20 ebox systemd[1]: Started Network Service.
Aug 1013:20:20 ebox systemd[1]: Starting Wait for Network to be Configured...
puis un peu plus loin
Aug 1013:20:20 ebox kernel: [5.764095] r8169 0000:03:00.0 eth0: RTL8168c/8111c, 00:12:23:34:45:67, XID 3c4, IRQ 27
Aug 1013:20:20 ebox kernel: [5.764108] r8169 0000:03:00.0 eth0: jumbo features [frames: 6122 bytes, tx checksumming: ko]
Enfin, après rétablissement de /etc/systemd/network/99-default.link
Aug 2113:15:40 ebox systemd[1]: Started ifup for enp3s0.
Aug 2113:15:40 ebox systemd-networkd[238]: enp3s0: Link UP
Aug 2113:15:40 ebox systemd-networkd[238]: enp3s0: Gained carrier
Aug 2113:15:40 ebox systemd-networkd[238]: enp3s0: Gained IPv6LL
Aug 2113:15:40 ebox sh[574]: enp3s0=enp3s0
Aug 2113:15:40 ebox kernel: [5.855206] r8169 0000:03:00.0 enp3s0: renamed from eth0
Aug 2113:15:40 ebox kernel: [26.146512] r8169 0000:03:00.0 enp3s0: Link is Down
Aug 2113:15:40 ebox kernel: [29.124674] r8169 0000:03:00.0 enp3s0: Link is Up - 1Gbps/Full - flow control off
Aug 2113:15:40 ebox kernel: [29.124701] IPv6: ADDRCONF(NETDEV_CHANGE): enp3s0: link becomes ready
Oui, j'avais aussi pensé à une régle udev mais pourtant:
$ls -Rl /etc/udev/
/etc/udev/:
total 12
drwxr-xr-x 2 root root 409617 avril 2015 hwdb.d
drwxr-xr-x 2 root root 40967 août 2018 rules.d
-rw-r--r-- 1 root root 3052 févr. 2021 udev.conf
/etc/udev/hwdb.d:
total 0
/etc/udev/rules.d:
total 0
Et notamment pas le 70-persistent-net.rules que j'avais supprimé lors d'une dernière migration.
J'ai jeter un oeil à /var/log/apt/term.log mais rien d'évident, à mon niveau en tout cas.
Si vous avez d'autres idées de log à regarder, je veux bien regarder par curiosité intellectuelle.
De toute facon entre l'age des machines, et la possible fin de support de i386, pas sur que ca passe à Debian 12.
Sur ces 2 ebox B202 avec ce soucis, c'est du i386, qui est tjs supporté par Debian, mais sans doute moins testé. Plus l'historique de monté de version qui doit pas aider.
Difficile de diagnostiquer plus avant sur des historiques aussi anciens, mais il faut peut etre être prudent avant de faire ces majs à distance sur des configs aussi chargées.
Sur 2 autres machines x64 "moins" fossilisées ( seulement 8->9->10->11), c'est passé sans ce désagrément.
Pour info, petite surprise ici lors du passage de 10 à 11.
Retour au nommage des interfaces réseau non persistent enp3s0 -> eth0. Ca fait mal au premier reboot quand ssh ne répond plus.
Apres branchement clavier et écran, et en créant le fichier /etc/systemd/network/99-default.link, c'est revenu à la normale.
C'est sans doute du à l'historique de ces 2 machines qui ont bien vécues: installation initiale en Lenny, survécu au passage de systemd…
Je crois qu'il faudra prévoir une réinstall from scratch pour la version 12.
Ce serait tout de meme surprenant que vous n'ayez pas un accès ipv4 vers internet. Internet n'est que partiellement accessible en ipv6.
Vous devez etre derrière un CGNAT, donc une ipv4 partagée, cf Yunohost forum
Si vous utilisez le routeur du FAI, etes vous sur de ne pas avoir accès à internet ipv4 ? par exemple ipv4.google.com uniquement accessible en ipv4.
Peut etre que votre fai, permet une redirection de port limité. Si c'est vraiment 40 clients par ip, ce n'est sans doute pas le cas.
Autre piste si vous utilisez votre propre modem:
Si c'est comme chez Free ipv4 partagée pour certains, il n'est pas possible de connecter un modem / routeur standard. Il faut impérativement utiliser la box/modem du FAI qui gère cette ip partagée et 1/4 des ports.
Au final, si c'est bien du cgnat massif, un VPN vers un serveur externe accessible en ipv4 qui fera le relai vers votre serveur.
Clonezilla ne gère pas ce fs. Mais en mode brut, il doit pouvoir copier le disque tout de meme. L'image sera de taille plus importante car les espaces vides seront aussi copiés mais ca ne devrait pas etre un soucis, je doute que le disque d'un OS/2 soit si imposant que cela.
[^] # Re: Debian
Posté par dr191 . En réponse au message Quelle est votre distribution linux préférée ?. Évalué à 3.
Idem ici, Debian ou Debian depuis 20 ans
# Hp Instant Ink ?
Posté par dr191 . En réponse au journal imprimante HP. Évalué à 3. Dernière modification le 24 décembre 2021 à 11:07.
Salut
Probablement un modèle hp avec instant ink qui vous impose une connexion internet et une usine à gaz pour la mise en route.
Le modèle M234sdw ( sans le e) est vendu 100 EUR plus cher n'a pas etre pas cette contrainte ?
[^] # Re: Ca marche
Posté par dr191 . En réponse au message Baie disques durs 3"5 HotSwap. Évalué à 1.
Je ne crois pas avec ceux la.
Les tiroirs sont comme cela
Quand je disais compatible, je pensais à ces boitiers x3 par exemple.
# Ca marche
Posté par dr191 . En réponse au message Baie disques durs 3"5 HotSwap. Évalué à 1.
Salut,
J'en ai 3 équivalents au MB155SP-B de chez Icy dock qui tournent sans pb depuis 15 ans.
Ce n'est pas silencieux, donc pensez à l'emplacement du serveur qui va héberger cela.
Aussi voir aussi cables sata et alim de bonne longueur.
Les tiroirs sont fournis avec le boitier et sont interchangeables avec les autres boitiers de la marque ( x2, x3, boitier usb).
[^] # Re: Surprise, retour à eth0
Posté par dr191 . En réponse à la dépêche Sortie de Debian 11 « Bullseye ». Évalué à 1.
Voici ce que j'ai pu trouver.
Je n'ai pas retrouvé de log de démarrage avant mise à jour.
Démarrage après upgrade
puis un peu plus loin
Enfin, après rétablissement de /etc/systemd/network/99-default.link
[^] # Re: Surprise, retour à eth0
Posté par dr191 . En réponse à la dépêche Sortie de Debian 11 « Bullseye ». Évalué à 1. Dernière modification le 20 août 2021 à 20:18.
Oui, j'avais aussi pensé à une régle udev mais pourtant:
Et notamment pas le 70-persistent-net.rules que j'avais supprimé lors d'une dernière migration.
J'ai jeter un oeil à /var/log/apt/term.log mais rien d'évident, à mon niveau en tout cas.
Si vous avez d'autres idées de log à regarder, je veux bien regarder par curiosité intellectuelle.
De toute facon entre l'age des machines, et la possible fin de support de i386, pas sur que ca passe à Debian 12.
[^] # Re: Surprise, retour à eth0
Posté par dr191 . En réponse à la dépêche Sortie de Debian 11 « Bullseye ». Évalué à 5.
Sur ces 2 ebox B202 avec ce soucis, c'est du i386, qui est tjs supporté par Debian, mais sans doute moins testé. Plus l'historique de monté de version qui doit pas aider.
Difficile de diagnostiquer plus avant sur des historiques aussi anciens, mais il faut peut etre être prudent avant de faire ces majs à distance sur des configs aussi chargées.
Sur 2 autres machines x64 "moins" fossilisées ( seulement 8->9->10->11), c'est passé sans ce désagrément.
# Surprise, retour à eth0
Posté par dr191 . En réponse à la dépêche Sortie de Debian 11 « Bullseye ». Évalué à 8.
Pour info, petite surprise ici lors du passage de 10 à 11.
Retour au nommage des interfaces réseau non persistent enp3s0 -> eth0. Ca fait mal au premier reboot quand ssh ne répond plus.
Apres branchement clavier et écran, et en créant le fichier /etc/systemd/network/99-default.link, c'est revenu à la normale.
C'est sans doute du à l'historique de ces 2 machines qui ont bien vécues: installation initiale en Lenny, survécu au passage de systemd…
Je crois qu'il faudra prévoir une réinstall from scratch pour la version 12.
# CGNAT ?
Posté par dr191 . En réponse au message Debian/Yunohost, rendre un serveur avec une adresse ipv6 accessible en ipv4. Évalué à 2.
Bonjour,
Ce serait tout de meme surprenant que vous n'ayez pas un accès ipv4 vers internet. Internet n'est que partiellement accessible en ipv6.
Vous devez etre derrière un CGNAT, donc une ipv4 partagée, cf Yunohost forum
Si vous utilisez le routeur du FAI, etes vous sur de ne pas avoir accès à internet ipv4 ? par exemple ipv4.google.com uniquement accessible en ipv4.
Peut etre que votre fai, permet une redirection de port limité. Si c'est vraiment 40 clients par ip, ce n'est sans doute pas le cas.
Autre piste si vous utilisez votre propre modem:
Si c'est comme chez Free ipv4 partagée pour certains, il n'est pas possible de connecter un modem / routeur standard. Il faut impérativement utiliser la box/modem du FAI qui gère cette ip partagée et 1/4 des ports.
Au final, si c'est bien du cgnat massif, un VPN vers un serveur externe accessible en ipv4 qui fera le relai vers votre serveur.
[^] # Re: clonezilla ?
Posté par dr191 . En réponse au message Cloner un disque formaté en HPFS (système de fichier d'OS/2). Évalué à 3.
Bonjour,
Clonezilla ne gère pas ce fs. Mais en mode brut, il doit pouvoir copier le disque tout de meme. L'image sera de taille plus importante car les espaces vides seront aussi copiés mais ca ne devrait pas etre un soucis, je doute que le disque d'un OS/2 soit si imposant que cela.
Clonezilla About