Reprise du message précédent :
T'aurais pas installé grub sur autre chose que le disque où t'as installé Debian ?

Si c’était le cas, ça aurait aussi foiré aux redémarrages, non ? Or, il dit que ça redémarrait bien, et que ce n’est qu’après avoir éteint que ça ne voulait plus démarrer.

Faudrait préciser ce qu'il voulait dire par "débranchement du bordel".
C'était une installation sur un disque externe ou un interne ?

C'est ce que j'ai pensé la première fois, j'ai bien fait attention les deux suivantes.

Note : Si j'avais installé le GRUB sur un autre disque, ça aurait dû planter aussi lors d'un reboot simple, non ?

Edit : Changement de page, ounaid

Pas de disque externe, un seul disque interne + clef usb pour l'installation.

Pour le débranchement : littéralement éteindre la machine (poweroff), débrancher le câble d'alim, transporter la machine dans une autre pièce (la première fois, les suivantes je l'ai laissé sur place), rebrancher la machine et la rallumer.

Pas d’erreur concernant la pile CMOS à l’allumage ? Tant qu’à essayer de trouver un truc qui pourrait foirer du moment que tu débranches l’ordi du secteur…

ça sent la pile vide qui te remet le BIOS avec ses valeurs par défaut

Toi aussi ? Faut dire que là, je vois que trois trucs qui pourraient se détraquer du moment qu’il n’y a plus de courant (vu que, même éteint, il y en a qui circule si ça reste branché) :

• la pile CMOS
• la RAM (mais ça aurait causé des plantages à n’importe quel moment, et pas seulement dans ces conditions précises)
• le bloc d’alimentation (sur un fixe)

Dites j'ai une curiosité sur 2 stations HP Z4 toutes neuves (okay c'est du CentOS 7 mais c'est le fournisseur qui installe ça pour faire tourner un logiciel particulier).
Ca tourne sans problème pendant plusieurs heures et d'un coup ça commence à merder. J'ai des "can not allocate memory" ici et là, impossible de faire un swapoff (can not allocate memory) alors que la machine à 12Gb de ram libre et que le swap est vide. Firefox ne se lance plus, quand je tente depuis le terminal, il annonce un problème mémoire.
 
Je n'ai rien dans les logs, rien dans les graphs (grafana récupère pas mal de trucs mais je n'ai rien de parlant là dedans).
 
La seule chose que j'ai changé par rapport au setup d'origine, c'est que j'ai fait un swapfile de 4Gb sur le NVMe plutôt que celui de 64Gb qui se trouvait sur le SATA... mais je doute que ça pose problème.
On a une 20e d'autres machines qui tournent ce type de configuration, c'est la première fois que j'ai ce problème.
 
Alors certes, c'est du Centos7 sur une machine récente mais quand même.
 
Si vous avez une idée, je suis preneur.

Un p'tit coup de memtest ?

ouaip, testé et pas de soucis. BIOS à jour également et le curieux c'est que les 2 machines merdent de la même manière

Tu aurais du docker avec limitations des fois ?

 
non, rien du tout du genre, c'est un setup très simple:
Centos 7
KDE Plasma
Bruker Topspin 4.2.0 (logiciel proprio pour machine d'analyse)
 
NVMe de 256Gb pour le système (200Gb libre)
SATA de 2Tb pour les données (1.8Tb libre)
16Gb RAM

Bordel, j'ai déplacé le swap sur le disque sata pour voir mais on n'est pas mieux

https://leizhilong.github.io/post/c [...] te-memory/
 
?

Pardon pour cette question mille fois posée mais : SSD, swap ou pas swap ? Internet n'est pas d'accord
J'ai un Kingston A400/120G à mettre sur mon vieux laptop (4G Ram).
Il utilise le swap en général sur un update post-install, update noyau, etc. Pas plus de 10M, même s'il reste de la mémoire libre.
- Au pire j'en mets un et ne sera quasi pas utilisé.
- Je n'en mets pas, et il faudra qu'il se débrouille.

 
réponse 3 : zram ; i.e. un espace compressé en RAM qui joue le rôle de swap.

Laisse-le sur le SSD. De toute façon, et de manière générale, un SSD ne s’utilise pas différemment d’un disque dur mécanique, côté utilisateur. Laisse tomber toutes les pseudo-astuces et autres discours appelant à « économiser » l’usage, parce que c’est du bullshit : un SSD utilisé normalement a une durée de vie supérieure à n’importe quel DD mécanique. Et au pire, si tu forces dessus (mais faudra y aller !), tu perdras quoi ? 5 % de capacité au bout de 6 ans ? C’est rien, ça. Clairement, t’embête pas avec ça.

Je vais faire simple du coup, et en mettre un  

L'internet de 2010 sûrement
Le consensus aujourd’hui c'est que globalement les SSD sont largement assez fiables pour supporter un (potentiellement) grand nombre d'IO dû au swap.

Pour mon soucis mémoire, je ne pige pas c'est vraiment curieux. Le soft du fournisseur est clairement codé avec des moufles, ça fait 15 ans qu'ils font des trucs pourris donc ça ne change pas avec cette version mais quand même.
 
Sur quasi toutes les autres machines, les swap sont des partoches et pas des fichiers. Du coup j'ai modifié un coup mon disque pour rajouter une partoche de 8Gb pour ça et j'ai remonté le tout. On verra ce que ça donne, on lance les tests demain.

Je continue ma recherche. Les 2 machines ont maintenant une partition pour le swap.
 
Tant que le logiciel du fournisseur est lancé, impossible de couper le swap
 

 
Je me suis amusé à lister les packages installés sur une autre machine qui n'a pas ce problème et les comparer avec ceux de la machine qui déconne.  
 
Au final, il y a beaucoup de packages 32bits aussi installés sur la machine qui déconne (en plus de la version x64), du coup est-ce que ce problème pourrait venir de là ?

Et il s'alloue combien de RAM ton soft fournisseur ?
C'est peut-être simplement qu'il alloue tellement de mémoire que ça passe pas dans tes 16Gb (GB j'imagine )
Donc tu peux plus virer le swap ni allouer d'autres trucs volumineux.
Et si potentiellement il lock ses pages, lui-même n'est pas swappable.

Bonne question, les mecs ont un soft codé avec les pieds depuis toujours donc aucune idée. C'est un bouzin en java avec des librairies dans tous les coins.
Mais si il s'allouait trop de ram, ça serait visible quelque part non ? parce que là :

pour le swap, j'ai planté un vieux SSD de 60Gb dans le bouzin, c'était plus rapide que de repartitionner le disque

Bizarre y a quasi rien d'alloué là.
Et donc là tout de suite dans cette situation avec rien en swap tu peux quand même pas swapoff ?

non, et dès que je ferme le logiciel, je peux swapoff sans problème.
Au début je pensais que le truc déconnait parce que le swap était dans un fichier mais maintenant que c'est une partition, ça exclu cette possibilité

Nouveau nvme Firecuda 530 dans le portable. Occasion d'installer Spirallinux, une debian stable qui utilise btrfs et des snapshots automatiques à certaines opérations critiques (sudo, apt, etc...)
 
Biensur, j'ai vite ajouté les dépôts testing et unstable, mx main et mx test pour récupérer mx-snapshot (pour créer un snapshot iso de l'os qui fait aussi des snapshots   )
 
Concernant mx-snapshot, j'ai ajouté quelques dossiers à exclure de l'iso, sinon ca s'approche de la boucle infinie quand ca arrive sur le dossier /.snapshots de btrfs   :
 

J'en ai mis un peu plus, au cas où. Et mes ajouts pour mon home

 
Et la ligne de commande pour générer l'iso:

 
Prochaine étape, vérifier que l'iso générée est bien installable sur une autre machine.

Btrfs n'avait pas eu des sérieux soucis de fiabilité ?

C'est le premier truc auquel j'ai pensé, mais :
 
- pas de message d'erreur
- pile testée ok
- le changement de disque dur a magiquement résolu le problème

Je ne sais pas, mais même arch à une partie "is btrfs stable ?", pour l'instant ca va.
J'ai juste au la mauvaise surprise après un gros delete de plus de 500Go de voir que je n'avais toujours pas récupéré d'espace libre. Le home est aussi snapshoté
Bon petite tour dans /home/.snapshots pour faire du ménage, et j'ai réduit le nombre de snasphots conservé par snapper..
 
Autre comportement étrange, je voulais vérifier le taux d'écriture du nvme, en copiant/collant un fichier de 45Go. Eh bah.... aucune réaction dans htop ou le widget plasma activités disques. C'est juste immédiat. Je suppose que c'est une copie fantôme qui est réalisée (le second "fichier" qui pointe sur le même inode ?).
Je vais probablement revoir la taille de home et faire une partoche qui n'est pas gérée/surveillée par snapper.
 
Quand à l'iso de l'os snapshoté, pour l'installant c'est un échec cuisant, il n'arrive pas à booter (antiX/linuxfs introuvale) sur une autre machine. A essayer sans Ventoy.

 
Je n'ai pas trop suivi le truc mais RedHat 8 a sorti le support BTRFS
Après, d'autres distrib l'utilisent quand même donc ce n'est pas super clair leur truc.

L'install du SSD s'est miraculeusement bien passée, le Bios ne l'a pas vu mais Linux le voit sur clé Live mais ... "Disks" me l'affiche à 100° Celsius  
Petit stress mais apparemment c'est un "bug", hddtemp le voit à 9°  

edit : install ok \o/ En effet, c'est plus rapide

Hey

Je tente une petite incursion de teub ici

J'ai une serveur avec deb 9 et de très maigres connaissances autodidactes

J'ai besoin pour faire tourner une instance de minecraft pour les gosses d'actualiser java.

Actuellement je suis en 1.8

J'ai récupéré la version actuelle (1.19) via : https://jdk.java.net/19/ (version linux/x64)

Je récupère un fichier compressé, mais impossible de trouver quoi installer. Si je tente une install du fichier compréssé ça foire, et une fois décompressé, y'a rien d'installable dedans

Je rate probablement un truc gros comme une montagne

Pourriez m'éclairer ?

En notant que mon domaine de compétence, c'est le béton

Thx

ps : darx : en gros je suis a peu près aussi doué sous linux qu'avec un couteau croche

amha, ce serait plus simple d'utiliser le paquet debian de oracle :  
https://download.oracle.com/java/19 [...] 64_bin.deb
 
(cf https://www.oracle.com/java/technologies/downloads/ )
 
à installer (en root ou avec sudo ; en étant dans le dossier où tu as mis le fichier deb) avec un

 
 cf https://computingforgeeks.com/insta [...] ian-linux/ pour configurer les variables d'environnements qui permettront de lancer java facilement (note que tu as aussi une méthode en partant du tar.gz que tu as déjà)

Vachement plus simple avec les bons liens, merci
 
téléchargement et installation sans soucis...
 
mais...
 

 
 
 

 
J'avais dit que j'étais une tanche

C'est dans le deuxième lien, il faut que tu dises au système que ton java est à un autre endroit :
 
ça se fait avec les variables JAVA_HOME pour lui dire où est ton java (qui  doit être dans /usr/lib/jvm/jdk-19/ ) et la variable PATH qui indique au système où il doit aller regarder pour trouver un truc à lancer  
 
exemple chez moi :

 
pour paramétrer ces variables et que ça reste pour tout les utilisateurs, une solution est de créer un fichier dans /etc/profile.d ( nommé par exemple jdk.sh ) avec le contenu :

 
(la deuxième ligne ajoute le chemin vers java au PATH existant)
 
ensuite tu tapes

pour prendre en compte le fichier et ça devrait être bon   (tu peux aussi déconnecter/reconnecter ton utilisateur ou relancer un terminal).

C'est chiant de pas avoir les bases suffisantes pour tout piger du premier coup.

C'est fait mais ça change rien. J'ai vraisemblablement bien java dans /usr/lib/jvm/jdk-19/

J'ai fais la manip pour le fichier, mais j'ai pas de changement...

si tu affiches les variables JAVA_HOME et PATH, tu as bien les bonnes valeurs (i.e. avec le jdk 19) ?

Incapable de dire si la deuxième est bonne ^^'

Si l'autre java (le 8) n'est pas désinstallé, il doit se trouver dans /usr/bin et être appelé avant le 19 (puisque /usr/bin est avant dans la liste des PATH)
 
Si tu n'en n'as pas besoin, essaye de le désinstaller.
 
Sinon, tu vas devoir lancer ton nouveau java en spécifiant le chemin complet :

Bon déjà question con mais pourquoi t'es en debian 9 ?

Effectivement, ça venait de là.

opendjdk-8* effacé, fichier jdk.sh actualisé repris en compte
et java -version sort ce qu'il me faut

Le serveur minecraft semble vouloir se lancer. J'ai d'autres problèmes de config à régler, mais ça à l'air good.

Milles mercis

Probablement parce que chaque modif de mon serveur me prend des heures de défenestration cérébrale haha

Ce que j'ai à faire tourner tourne en deb 9, j'ai pas cherché plus loin ^^'