Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Pages : 1
je possède sid sur le nvme (mp600)
et bullseye sur le ssd (sda , présentement)
et c'est bullseye qui me pose souci .
pas moyen de redimensionner le swap .
pas moyen de déplacer de l'espace libre
gparted ne fonctionne pas
fdisk sème la pagaille
bref , je sais pas faire .
un coup de main ?
merci .
ma ram :
note : bullseye installé avec l'image netinstall
Dernière modification par Debian Alain (19-05-2021 18:09:43)
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par vv222 (01-06-2021 14:44:39)
Almanet doLys de l'open source : mon tuto pour optimiser / finaliser une install
Manjaro Xfce - Debian Xfce - Yunohost - Xebian Et vous ?
61 convertis IRL (n'ont pas eu le choix...).
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Almanet doLys de l'open source : mon tuto pour optimiser / finaliser une install
Manjaro Xfce - Debian Xfce - Yunohost - Xebian Et vous ?
61 convertis IRL (n'ont pas eu le choix...).
Hors ligne
#SUPPRIMER SWAP
c'est un peu à l'envers, supprime l'existante et crée en une nouvelle, l'exemple est pour 10G
Pourquoi ?
Parce que le noyau ne sait pas vraiment utiliser un fichier normal comme swap. Donc il doit cartographier les blocs occupés par le fichier pour ensuite y accéder directement sans passer par le système de fichiers. Non seulement cela viole l'abstraction du système de fichiers, mais cela ne fonctionne pas avec tous les types de systèmes de fichiers (notamment btrfs avant le noyau 5.0) ni tous les types de fichiers (fichier creux ou copy-on-write par exemple) pour lesquels la cartographie est impossible ou instable.
En tous cas systemd-swap évite deux choses :
- bloquer en permanence une partition, on sait pas pourquoi
- avoir une taille trop grande ou trop petite pour ce machin bloqué
C'est une fausse impression car l'espace nécessaire au swap doit être disponible en cas de besoin. Que se passerait-il si le système a besoin d'ajouter du swap alors qu'il n'y a plus d'espace disque disponible ?
Dernière modification par raleur (20-05-2021 06:51:07)
Il vaut mieux montrer que raconter.
Hors ligne
Une autre variante est d'installer zram-tools à partir de synaptic mais le commentaire #6 devrait répondre à ta demande.
soit tu fais une installation en manuel (ou en auto)
tu supprime proprement ton swap (désactivé (démonter) et partition supprimer )
tu réduit sda2 a la valeur que tu désire (moi je mettrais un peu plus que 27.9G sur un disque de 1T0 )
tu créer ta partition /home pour qu'il te reste 32G pour le swap
tu créer ta partition de swap
tu modifie ton fichier /etc/fstab et met a jour tes UUID si besoin
ps: sur un ssd que le swap soit en fin de disque aucune importance (pas comme sur un DD mécanique )
nota : c'est un souci de l'iso RC1 de bullseye qui fait un swap de 1G quelque soit la quantité de mémoire installé
avec gparted aucun souci pour réduire une partition système , la ton swap est coincer entre la partition système et et la partition /home
sur une installation dans" tout un disque" (mode débutant ) je l'ai fait sans problème
pour le /home je pense qu'il est facile de le déplacer de la partition système vers la nouvelle partition /home créer
ps: ça te fera un peu de travaux pratique sur "gparted" 
deux liens pour déplacer le /home
=> https://doc.ubuntu-fr.org/tutoriel/deplacer_home
=> https://www.debian-fr.org/t/comment-dep … home/54403
quand tout est prêt , le mode recovery pour copier ton home dans newhome ( a faire de préférence sur une installation neuve )
ou a l'aide d un "live"
ps: moi j'utilise toujours l iso de buster en mode minimal (moins de soucis) et je firmware-nonfree et full-upgrade vers testing
et ensuite j'installe le bureau
mais bon si tu dis que avec ton matériel buster ne fonctionne pas
dèrnière solution attendre que l'iso DVD1 de testing passe en stable .
Dernière modification par anonyme (20-05-2021 01:12:16)
tu réduit sda2 a la valeur que tu désire (moi je mettrais un peu plus que 27.9G sur un disque de 1T0 )
tu créer ta partition /home pour qu'il te reste 32G pour le swap
La partition /home existe déjà, et réduire / de 32 Go n'est pas possible.
ur un ssd que le swap soit en fin de disque aucune importance (pas comme sur un DD mécanique )
Exactement. Donc à mon avis le plus simple est de supprimer la partition de swap actuelle, réduire la partition /home par la droite et créer une nouvelle partition de swap à la fin du SSD. Eventuellement agrandir la partition racine avec l'espace de l'ancienne partition de swap. Les alternatives sont :
- supprimer la partition /home après sauvegarde, puis recréation et restauration de /home
- réduire la partition /home par la gauche avec gparted, ce qui implique le déplacement de tout son contenu. C'est plus rapide sur un SSD mais reste lourd.
Note : on ne peut pas redimensionner un swap stricto sensu. On doit redimensionner la partition et la reformater avec le même UUID, label... (ce que fait implicitement gparted).
Il vaut mieux montrer que raconter.
Hors ligne
Donc à mon avis le plus simple est de supprimer la partition de swap actuelle, réduire la partition /home par la droite et créer une nouvelle partition de swap à la fin du SSD.
oui , je pense . mais là ... repos . je verrai plus tard .
notes : ah oui , reste la solution de LVM . mais je l'utilise rarement .
Pour l'agrandir, je suppose ?
oui .
trouvé : https://lecrabeinfo.net/redimensionner- … linux.html
j'attends vos avis .
Dernière modification par Debian Alain (20-05-2021 17:43:59)
Hors ligne
plus de 17 heures pour déplacer 40,000 Mo , c'est trop
Non, pour déplacer 800 Go. Néanmoins un SSD n'est pas affecté par les allers-retours incessants des têtes de lecture/écriture comme le serait un disque dur pour réaliser cette opération, donc un débit effectif < 800 Go / 17 h = 13 Mo/s est très faible pour un SSD.
si qqun a une astuce en cli . rapide
Je ne connais qu'un seul programme en ligne de commande capable de déplacer une partition et son contenu, sfdisk avec l'option --move-data. Jamais utilisée en revanche.
reste la solution de LVM . mais je l'utilise rarement
Et il faut y penser au moment de l'installation. Après, quand on en a besoin, c'est trop tard.
Il vaut mieux montrer que raconter.
Hors ligne
-->les cahiers du debutant<-- WikiDF-->Découvrir les principales commandes Linux<--
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde
Hors ligne
je comprend pas comment tu peux avoir le même soucis si tu as tout réinstallé
pardon croutons , j'ai pas été clair .
première tentative : post #1 ,
puis Gparted (17 heures) : résultat : à peine .
arrêt gparted puis poweroff brutal .
partition abîmée (normal)
deuxième tentative : post #11 ,
tout réinstallé sans redimensionnement .
pas encore lancé gparted .
Debian Alain a écrit :
plus de 17 heures pour déplacer 40,000 Mo , c'est trop
Non, pour déplacer 800 Go. Néanmoins un SSD n'est pas affecté par les allers-retours incessants des têtes de lecture/écriture comme le serait un disque dur pour réaliser cette opération, donc un débit effectif < 800 Go / 17 h = 13 Mo/s est très faible pour un SSD.
(râleur) et pour réduire (cas présent) de 100 Go sur la gauche (à peu près) sdb4 ?
tu prévois combien de temps ? à la louche ...
un débit effectif < 800 Go / 17 h = 13 Mo/s est très faible pour un SSD.
et pour une clé usb 2.0/3.0 ? , c'est lent ?
Dernière modification par Debian Alain (21-05-2021 07:17:41)
Hors ligne
)
Dernière modification par Croutons (21-05-2021 09:19:01)
-->les cahiers du debutant<-- WikiDF-->Découvrir les principales commandes Linux<--
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde
Hors ligne
un débit effectif < 800 Go / 17 h = 13 Mo/s est très faible pour un SSD.
et pour une clé usb 2.0/3.0 ? , c'est lent ?
Hélas non. L'expérience récente m'a rappelé que si l'USB 3 peut améliorer la vitesse de lecture des clés USB, la vitesse d'écriture reste médiocre et dans cet ordre de grandeur.
Il vaut mieux montrer que raconter.
Hors ligne
Parce que le noyau ne sait pas vraiment utiliser un fichier normal comme swap. Donc il doit cartographier les blocs occupés par le fichier pour ensuite y accéder directement sans passer par le système de fichiers. Non seulement cela viole l'abstraction du système de fichiers, mais cela ne fonctionne pas avec tous les types de systèmes de fichiers (notamment btrfs avant le noyau 5.0) ni tous les types de fichiers (fichier creux ou copy-on-write par exemple) pour lesquels la cartographie est impossible ou instable.
Merci pour tes réponses
Bon, effectivement, je n'ai d'expérience que sur ext4.
Jamais eu d'incidents par contre sur 60+ installs (je n'utilise pas l'hibernation dont je n'ai jamais compris l'intérêt : quand je n'utilise pas un ordi longtemps, eh ben je l'éteins.
nam1962 a écrit :En tous cas systemd-swap évite deux choses :
- bloquer en permanence une partition, on sait pas pourquoi
- avoir une taille trop grande ou trop petite pour ce machin bloqué
C'est une fausse impression car l'espace nécessaire au swap doit être disponible en cas de besoin. Que se passerait-il si le système a besoin d'ajouter du swap alors qu'il n'y a plus d'espace disque disponible ?
Il y aurait une différence avec une partition swap trop petite ? En dehors du fait que l'espace libre, quand correctement réfléchit est largement supérieur à la taille d'une partition swap, chez moi, on parle de 60Go d'espace libre (12Go de RAM)
Almanet doLys de l'open source : mon tuto pour optimiser / finaliser une install
Manjaro Xfce - Debian Xfce - Yunohost - Xebian Et vous ?
61 convertis IRL (n'ont pas eu le choix...).
Hors ligne
Il y aurait une différence avec une partition swap trop petite ?
Non, donc ce n'est pas mieux.
En dehors du fait que l'espace libre, quand correctement réfléchit est largement supérieur à la taille d'une partition swap, chez moi, on parle de 60Go d'espace libre
Une partie de cet espace "libre" doit être disponible pour l'agrandissement du swap donc tu ne peux pas en disposer librement. De ce point de vue il n'y a pas vraiment d'avantage par rapport à une partition de swap.
Il vaut mieux montrer que raconter.
Hors ligne
donc a partir de sda je travaille sur sdb4 et sdb3 avec gparted
ps: le swap est de 7,7Go environ il est maintenant de 15Go maintenant (mémoire installé 16Go)
le log de gparted
pour sda4
le log pour le swap
a priori rien modifier dans le fstab
ma partition "document" n'est pas monter (il faut que je le fasse pour archiver et changer son nom , elle est vide en ext4 )
je comprend pas pourquoi tu a autant de soucis
je pourrai l'utiliser pour déplacer mon /home de sdb2 vers sdb4 aussi
remarque:
ma ram est de 14,6Gio pour un swap de 15,6Gio
Dernière modification par anonyme (21-05-2021 15:57:46)
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Qu'entends-tu par "RAM Intel" ? A ma connaissance Intel ne fabrique plus de RAM depuis des décennies
celle là : https://www.amazon.fr/gp/product/B07RW6 … UTF8&psc=1
ram compatible intel
par opposition à celle là : https://www.topachat.com/pages/detail2_ … 19301.html
ram compatible AMD.
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
pour Asus la fréquence mémoire (sans OC ) est de 2666Mhz sur la série X570 (si je me suis pas tromper )
un exemple pour une FuryX DDR4
la fréquence de base 2400 , XPM est un profil intel a choisir dans le bios
ps: pour que la barrette fonctionne bien sa tension a 3200 passe de 1.2V a 1.35V
sinon tu a bien placer tes barrettes et bien verrouiller
Asus a un utilitaire dans le bios pour voir la configuration des barrettes actuelle
tu commence par une barrette par exemple
=> https://www.corsair.com/fr/fr/Cat%C3%A9 … tech-specs
Dernière modification par anonyme (22-05-2021 16:05:05)
Dernière modification par Debian Alain (22-05-2021 16:54:08)
Hors ligne
Pages : 1