Re: Stretch vers Bullseye - Probleme lors du apt full-upgrade
Bonjour Désolé pour ce retour tardif. Je vous confirme que tout est OK, mon système fonctionne normalement et je n'ai pour l'heure rencontré aucun probleme. Oui effectivement, les partitions sont complètement entremêlées et réparties sur 3 partitions. sda1 qui contient / sda2 qui contient sda5 => /boot, sda6 => swap, sda7 => /tmp, sda8 => /usr, sda9 => /var, sda10 => /opt sda3 qui contient /home Néanmoins, il me reste un espace non utilisé en fin de disque. Quand j'aurai un moment, je rajouterai quelques giga sur / afin de ne plus me retrouver en difficulté par manque d'espace. Bonne soirée Cordialement Hugues Le sam. 17 févr. 2024 à 23:47, Michel Verdier a écrit : > Le 17 février 2024 Alban Vidal a écrit : > > > Pour éviter des soucis d'espace disque à l'avenir, je pense qu'il serait > > judicieux de redimensionner un peu les partitions, en en retirant un peu > dans > > le /opt ou /home pour en mettre un peu plus sur la racine (/), 2 ou 3G > par > > exemple. > > Je pense que ce serait pas mal au passage de supprimer des > partitions. Mais comme les partition ssont assez emmêlées je crois que ça > risque d'être coton et que ce sera plus simple de tout sauvegarder et > refaire le formattage complètement. > >
Re: Stretch vers Bullseye - Probleme lors du apt full-upgrade
Re bonjour Je viens d'exécuter le apt full-upgrade. Je pensais que ça allait prendre un peu de temps mais ça a été rapide, tous les paquets étaient déjà à jour :) J'ai redémarré et tout semble fonctionner. J'ai effectué quelques mises a jour et preparé l'upgrade a la version suivante comme specifié (paragraphe 4.7) dans la doc: https://www.debian.org/releases/buster/amd64/release-notes/ch-upgrading.fr.html PROBLEME RESOLU ;-))) UN GRAND MERCI A TOUS POUR VOTRE AIDE ET VOS CONSEILS :)) JE vous souhaite un week end Très cordialement Hugues Le sam. 17 févr. 2024 à 15:31, Hugues MORIN-TRENEULE a écrit : > Salut > > Merci Gilles pour ta confirmation > > J'ai plus qu'a ... ;) > > Bonne journée > Hugues > > Le ven. 16 févr. 2024 à 18:56, Gilles Mocellin < > gilles.mocel...@nuagelibre.org> a écrit : > >> Le vendredi 16 février 2024, 18:43:58 CET Hugues MORIN-TRENEULE a écrit : >> > Salut >> > >> > Merci pour tous ces conseils, je garde ça précieusement pour les >> prochains >> > upgrade car j'ai l'intention d'upgrader jusqu'à la dernière version >> stable. >> > >> > Sinon, j'ai lancé le processus d'upgrade comme nous en avons parlé mais >> > malheureusement avant d'avoir reçu les conseils de Gilles et Alain. >> > Voila un petit compte rendu de ce que j'ai fait et des messages que >> j'ai eu: >> > >> > - ps ne m'a pas afficher de processus apt en train de tourner donc pas >> > besoin du killall. >> > Je n'ai pas non plus exécuté de dpkg-reconfigure (ni meme dpkg >> --configure >> > -a) qui m'a semblé n'être nécessaire que dans le cas ou il y aurait eu >> un >> > processus apt dans le ps >> > J'espère que je n'ai pas créé un probleme en ne le faisant pas. >> > >> > - J'ai ensuite exécuté apt upgrade --without-new-pkgs >> > qui m'a retourné un message d'erreur me signalant que des paquets liés >> au >> > noyau linux-image-4.19.0-25-amd64 était absent >> > et d'exécuter apt --fix-broken install pour résoudre le probleme. >> > >> > - J'ai donc exécuté apt --fix-broken install, qui semble s'être déroulé >> > sans incident. >> > >> > - J'ai RE-exécuté apt upgrade --without-new-pkgs qui m'a listé les >> paquets >> > qui ne sont plus nécessaires. >> > Je les ai retirés avec apt autoremove comme le conseille la commande >> > précédente. >> > >> > Jusque là, tout semble OK :) >> >> En effet ! >> >> > Normalement afin de finir mon upgrade il ne manque plus que le apt >> > full-upgrade à exécuter. >> > >> > Je me suis arrêté là pour l'instant, par manque de temps pour aller plus >> > loin >> > Je n'ai pas encore éteint (ou rebooter) la machine. >> > >> > Est ce que mon oubli du dpkg -configure pourrait engendrer un probleme? >> et >> > si oui comment le corriger avant de passer au full upgrade? >> >> Non, les commandes apt que tu as passé auraient dit qu'il y avait un >> problème >> et qu'il fallait finir les opérations dpkg arrêtées en cours (par le dpkg >> -- >> configure -a). >> >> Tu peux y aller. >> >> > Bonne soirée >> > Hugues >> >> Bonne soirée, tu y es presque ! >> >> >>
Re: Stretch vers Bullseye - Probleme lors du apt full-upgrade
Salut Merci Gilles pour ta confirmation J'ai plus qu'a ... ;) Bonne journée Hugues Le ven. 16 févr. 2024 à 18:56, Gilles Mocellin < gilles.mocel...@nuagelibre.org> a écrit : > Le vendredi 16 février 2024, 18:43:58 CET Hugues MORIN-TRENEULE a écrit : > > Salut > > > > Merci pour tous ces conseils, je garde ça précieusement pour les > prochains > > upgrade car j'ai l'intention d'upgrader jusqu'à la dernière version > stable. > > > > Sinon, j'ai lancé le processus d'upgrade comme nous en avons parlé mais > > malheureusement avant d'avoir reçu les conseils de Gilles et Alain. > > Voila un petit compte rendu de ce que j'ai fait et des messages que j'ai > eu: > > > > - ps ne m'a pas afficher de processus apt en train de tourner donc pas > > besoin du killall. > > Je n'ai pas non plus exécuté de dpkg-reconfigure (ni meme dpkg > --configure > > -a) qui m'a semblé n'être nécessaire que dans le cas ou il y aurait eu un > > processus apt dans le ps > > J'espère que je n'ai pas créé un probleme en ne le faisant pas. > > > > - J'ai ensuite exécuté apt upgrade --without-new-pkgs > > qui m'a retourné un message d'erreur me signalant que des paquets liés au > > noyau linux-image-4.19.0-25-amd64 était absent > > et d'exécuter apt --fix-broken install pour résoudre le probleme. > > > > - J'ai donc exécuté apt --fix-broken install, qui semble s'être déroulé > > sans incident. > > > > - J'ai RE-exécuté apt upgrade --without-new-pkgs qui m'a listé les > paquets > > qui ne sont plus nécessaires. > > Je les ai retirés avec apt autoremove comme le conseille la commande > > précédente. > > > > Jusque là, tout semble OK :) > > En effet ! > > > Normalement afin de finir mon upgrade il ne manque plus que le apt > > full-upgrade à exécuter. > > > > Je me suis arrêté là pour l'instant, par manque de temps pour aller plus > > loin > > Je n'ai pas encore éteint (ou rebooter) la machine. > > > > Est ce que mon oubli du dpkg -configure pourrait engendrer un probleme? > et > > si oui comment le corriger avant de passer au full upgrade? > > Non, les commandes apt que tu as passé auraient dit qu'il y avait un > problème > et qu'il fallait finir les opérations dpkg arrêtées en cours (par le dpkg > -- > configure -a). > > Tu peux y aller. > > > Bonne soirée > > Hugues > > Bonne soirée, tu y es presque ! > > >
Re: Stretch vers Bullseye - Probleme lors du apt full-upgrade
Salut
Merci pour tous ces conseils, je garde ça précieusement pour les prochains
upgrade car j'ai l'intention d'upgrader jusqu'à la dernière version stable.
Sinon, j'ai lancé le processus d'upgrade comme nous en avons parlé mais
malheureusement avant d'avoir reçu les conseils de Gilles et Alain.
Voila un petit compte rendu de ce que j'ai fait et des messages que j'ai eu:
- ps ne m'a pas afficher de processus apt en train de tourner donc pas
besoin du killall.
Je n'ai pas non plus exécuté de dpkg-reconfigure (ni meme dpkg --configure
-a) qui m'a semblé n'être nécessaire que dans le cas ou il y aurait eu un
processus apt dans le ps
J'espère que je n'ai pas créé un probleme en ne le faisant pas.
- J'ai ensuite exécuté apt upgrade --without-new-pkgs
qui m'a retourné un message d'erreur me signalant que des paquets liés au
noyau linux-image-4.19.0-25-amd64 était absent
et d'exécuter apt --fix-broken install pour résoudre le probleme.
- J'ai donc exécuté apt --fix-broken install, qui semble s'être déroulé
sans incident.
- J'ai RE-exécuté apt upgrade --without-new-pkgs qui m'a listé les paquets
qui ne sont plus nécessaires.
Je les ai retirés avec apt autoremove comme le conseille la commande
précédente.
Jusque là, tout semble OK :)
Normalement afin de finir mon upgrade il ne manque plus que le apt
full-upgrade à exécuter.
Je me suis arrêté là pour l'instant, par manque de temps pour aller plus
loin
Je n'ai pas encore éteint (ou rebooter) la machine.
Est ce que mon oubli du dpkg -configure pourrait engendrer un probleme? et
si oui comment le corriger avant de passer au full upgrade?
Bonne soirée
Hugues
Le mar. 13 févr. 2024 à 17:31, zithro a écrit :
> On 13 Feb 2024 10:31, Hugues MORIN-TRENEULE wrote:
> > @zithro / Cyril: je me suis trompé en écrivant, j'upgrade de bien de
> > Stretch à Buster ;-)
>
> Tant mieux ;)
> C'est toujours bon de préciser pour les futurs lecteurs !
>
>
> > Donc je récapitule pour voir si j'ai bien compris: - ps pour trouver
> > le PID d'apt - killall -9 "PID d'apt" - dpkg-reconfigure - apt
> > upgrade --without-new-pkgs (=> Cette commande met à niveau les
> > paquets qui peuvent l'être sans entraîner l'installation ou la
> > suppression d'autres paquets. ) - apt full-upgrade
> >
> > Ça vous semble correct ?
>
> Oui ça devrait aller, lis bien les docs officiels de MàJ, à chaque
> update majeur de version il y a des particularités (paquets obsolètes,
> etc).
> Quand tu changes les sources, pense à enlever les backports, si tu les
> utilises.
> Si c'est une install avec GUI, essaie de faire l'update depuis
> tty1/tty6, pas depuis X (vt7). Le serveur X -peut- redémarrer et te
> perdre la fenêtre d'upgrade (donc le stopper en plein milieu).
> Il est aussi recommandé d'utiliser "screen", pour parer à ce genre de
> problèmes (lancer avec "screen -R upgrade", et récup avec la même
> commande si ça coupe. Tu peux changer "upgrade" en hugues ou w/e).
> La commande "script" est aussi recommandée, pour tout enregistrer.
>
> J'ajoute quelques commandes qui peuvent être utiles avant de lancer
> l'upgrade. Elles sont aussi recommandées dans les "Release Notes", afin
> de partir sur une base saine avant l'upgrade.
> Certaines commandes sont équivalentes et donneront le même résultat.
> Quant à quoi faire du résultat ... ça dépend ! Pas de recette miracle.
> Mais ce n'est ni parce que tu n'as rien, ni parce que tu as des
> résultats que c'est un gage de réussite (:
>
> # lister les paquets obsolètes et "not-from-Debian"
> apt list '~o'
> # les purger - ATTENTION, purge=remove conf files
> apt purge '~o'
> apt list '?narrow(?installed, ?not(?origin(Debian)))'
> apt-forktracer | sort
>
> # vérif les paquets, surtout ceux en "hold"
> dpkg --audit
> dpkg --get-selections | grep 'hold$'
> apt-mark showhold
>
> # liens symboliques dans /etc qui pointent nulle part
> symlinks -r /etc | grep dangling
>
> # trouver les anciens fichiers config (ie. de paquets supprimés ou
> d'anciennes versions de paquets mis à jour)
> # (cette commande est affichée sur 2 lignes dans ce mail)
> find /etc -name '*.dpkg-*' -o -name '*.ucf-*' -o -name '*.merge-error'
> -o -name '*.old*'
> # equivalent
> dpkg -l | grep ^rc
> # les purger - ATTENTION, perte de données
> apt purge $(dpkg -l | awk '/^rc/ { print $2 }')
>
> Sinon, quelques paquets à installer avant l'upgrade si t'aimes bien tout
> check :
> deborphan
> apt-forktracer
> apt-listbugs
> apt-listchanges
>
> Bref, tu as presque toutes les armes, "pick your poison" comme disent
> les ricains !
> Perso, je préfère mettre toutes les chances de mon côté donc je lance
> toutes les commandes sur toutes les machines.
> Certains risquent de dire que c'est too much. A toi de voir ;)
>
> --
> ++
> zithro / Cyril
>
>
Re: Stretch vers Bullseye - Probleme lors du apt full-upgrade
Bonjour Merci à tous pour votre aide :) @zithro / Cyril: je me suis trompé en écrivant, j'upgrade de bien de Stretch à Buster ;-) Donc je récapitule pour voir si j'ai bien compris: - ps pour trouver le PID d'apt - killall -9 "PID d'apt" - dpkg-reconfigure - apt upgrade --without-new-pkgs (=> Cette commande met à niveau les paquets qui peuvent l'être sans entraîner l'installation ou la suppression d'autres paquets. ) - apt full-upgrade Ça vous semble correct ? Très cordialement Hugues Le mar. 13 févr. 2024 à 09:34, Michel Verdier a écrit : > Le 12 février 2024 Hugues MORIN-TRENEULE a écrit : > > > Avec le recul, aujourd'hui, je ne ferai que des partitions pour /home, > /var > > et /opt. > > /home et /opt il faut voir selon tes applis. Mais si /var est saturé ça > bloque tout le système à cause des logs qui ne peuvent plus se faire. > > > Est ce que cela vous semble suffisant pour l'upgrade? > > Oui bien mieux, 1.1Go pour / me parait suffisant. > > > Et dans l'affirmative, que faut-il faire ensuite? > > Recommence avec le apt upgrade --without-new-pkgs > S'il reste des packages non configurés apt te le dira et te donnera la > commande à passer pour finir la configuration précédente. > >
Re: Stretch vers Bullseye - Probleme lors du apt full-upgrade
Salut Merci pour l'info Malheureusement même si j'entrevois de quoi tu parles, je ne sais pas trop comment faire en pratique. Donc si je comprends bien, maintenant que j'ai fait de la place, il faut que je relance la commande apt full-upgrade Mais avant cela, je dois killer le pid de apt et faire un dpkg-reconfigure. Pour trouver le pid d'apt, c'est à l'aide de la commande ps? Et apres kill "n° de pid" Est ce qu'il y a autre chose a faire pour killer le processus d'apt? Ensuite dpkg-reconfigure et enfin apt full-upgrade Est ce que cela vous semble OK Très cordialement Hugues Le lun. 12 févr. 2024 à 18:49, Alain RICHARD a écrit : > J’ai fait récemment un apt full-upgrade de Debian 12 à Debian 13 (Trixie) > et mon Pc s’est éteint (fausse manœuvre) et après avoir rebooté, le système > m’a pas laissé recommencer la même commande. J’ai du killer le Pid de apt > et faire un dpkg —reconfigure -à et ça a été. > > > Le 12 févr. 2024 à 17:14, Hugues MORIN-TRENEULE a > écrit : > > > Salut > > > C'est un système qui à l'origine avait été installé en Wheezy ou Jessie et > que j'ai upgradé. > Je n'avais pas autant de connaissance que maintenant et il m'avait semblé > plus judicieux de faire une partition par montage. > Je me disais que ca serait surement plus simple de restaurer le système en > cas de crash avec cette manière de faire. > Avec le recul, aujourd'hui, je ne ferai que des partitions pour /home, > /var et /opt. > > > Sinon concernant le "ménage", j'ai supprimé les anciens kernel dans /boot. > J'ai supprimé aussi les dossiers modules concernés dans /lib/module. > > Voila le nouvel etat de mon systeme de fichiers: > > df -TPh > Filesystem Type Size Used Avail Use% Mounted on > udev devtmpfs 2.0G 0 2.0G 0% /dev > tmpfs tmpfs 396M 7.5M 389M 2% /run > /dev/sda1 ext4 1.8G 661M 1.1G 39% / > /dev/sda8 ext4 28G 7.2G 19G 28% /usr > tmpfs tmpfs 2.0G 0 2.0G 0% /dev/shm > tmpfs tmpfs 5.0M 4.0K 5.0M 1% /run/lock > tmpfs tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup > /dev/sdc1 ext4 916G 583G 287G 68% /mnt/data2 > /dev/sdb1 fuseblk 299G 285G 14G 96% /mnt/data > /dev/sda10 ext4 28G 2.7G 24G 11% /opt > /dev/sda7 ext4 1.8G 72K 1.7G 1% /tmp > /dev/sda9 ext4 19G 6.5G 11G 38% /var > /dev/sda3 ext4 73G 5.0G 65G 8% /home > /dev/sda5 ext4 920M 232M 625M 28% /boot > tmpfs tmpfs 396M 0 396M 0% /run/user/0 > /dev/sdd1 vfat 7.5G 366M 7.2G 5% /root/corsair > > df -i > Filesystem Inodes IUsedIFree IUse% Mounted on > udev 502193490 5017031% /dev > tmpfs506243848 5053951% /run > /dev/sda1122160 15831 106329 13% / > /dev/sda8 1831424 311408 1520016 18% /usr > tmpfs506243 1 5062421% /dev/shm > tmpfs506243 4 5062391% /run/lock > tmpfs506243 16 5062271% /sys/fs/cgroup > /dev/sdc1 61054976 13288 610416881% /mnt/data2 > /dev/sdb1 14184328 6185 141781431% /mnt/data > /dev/sda10 1831424797 18306271% /opt > /dev/sda7122160 28 1221321% /tmp > /dev/sda9 1220608 18510 12020982% /var > /dev/sda3 4890624 68947 48216772% /home > /dev/sda5 61056392606641% /boot > tmpfs506243 11 5062321% /run/user/0 > /dev/sdd1 0 00 - /root/corsair > > du -h -d 1 > 2.7G ./opt > 417M ./root > 6.5G ./var > 0 ./sys > 16K ./lost+found > 16M ./etc > 7.5M ./run > 12K ./media > 4.0K ./lib64 > 5.0G ./home > 7.2G ./usr > 13M ./sbin > 12M ./bin > 68K ./tmp > 564M ./lib > 868G ./mnt > 6.1M ./lib32 > 4.0K ./srv > 232M ./boot > 0 ./dev > 4.0K ./.cache > 0 ./proc > 890G . > > Est ce que cela vous semble suffisant pour l'upgrade? > > Et dans l'affirmative, que faut-il faire ensuite? > Je n'en ai pas la moindre idée et je ne voudrai pas exécuter de commande > qui pourrait faire empirer le probleme. > > Très cordialement > Hugues > > > Le lun. 12 févr. 2024 à 13:22, Michel Verdier a écrit : > >> Le 12 février 2024 Hugues MORIN-TRENEULE a écrit : >> >> > J'ai effectivement vu ce message mais je n'en avais pas compris la >> raison. >> > Néanmoins, au vue de df -TPh, je m’aperçois que ma partition racine et >> > /boot son bien "chargées". >> > Est ce que le problème pourrait provenir de la? >> >> Le message repéré par Alban porte sur /lib donc
Re: Stretch vers Bullseye - Probleme lors du apt full-upgrade
Salut C'est un système qui à l'origine avait été installé en Wheezy ou Jessie et que j'ai upgradé. Je n'avais pas autant de connaissance que maintenant et il m'avait semblé plus judicieux de faire une partition par montage. Je me disais que ca serait surement plus simple de restaurer le système en cas de crash avec cette manière de faire. Avec le recul, aujourd'hui, je ne ferai que des partitions pour /home, /var et /opt. Sinon concernant le "ménage", j'ai supprimé les anciens kernel dans /boot. J'ai supprimé aussi les dossiers modules concernés dans /lib/module. Voila le nouvel etat de mon systeme de fichiers: df -TPh Filesystem Type Size Used Avail Use% Mounted on udev devtmpfs 2.0G 0 2.0G 0% /dev tmpfs tmpfs 396M 7.5M 389M 2% /run /dev/sda1 ext4 1.8G 661M 1.1G 39% / /dev/sda8 ext4 28G 7.2G 19G 28% /usr tmpfs tmpfs 2.0G 0 2.0G 0% /dev/shm tmpfs tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup /dev/sdc1 ext4 916G 583G 287G 68% /mnt/data2 /dev/sdb1 fuseblk 299G 285G 14G 96% /mnt/data /dev/sda10 ext4 28G 2.7G 24G 11% /opt /dev/sda7 ext4 1.8G 72K 1.7G 1% /tmp /dev/sda9 ext4 19G 6.5G 11G 38% /var /dev/sda3 ext4 73G 5.0G 65G 8% /home /dev/sda5 ext4 920M 232M 625M 28% /boot tmpfs tmpfs 396M 0 396M 0% /run/user/0 /dev/sdd1 vfat 7.5G 366M 7.2G 5% /root/corsair df -i Filesystem Inodes IUsedIFree IUse% Mounted on udev 502193490 5017031% /dev tmpfs506243848 5053951% /run /dev/sda1122160 15831 106329 13% / /dev/sda8 1831424 311408 1520016 18% /usr tmpfs506243 1 5062421% /dev/shm tmpfs506243 4 5062391% /run/lock tmpfs506243 16 5062271% /sys/fs/cgroup /dev/sdc1 61054976 13288 610416881% /mnt/data2 /dev/sdb1 14184328 6185 141781431% /mnt/data /dev/sda10 1831424797 18306271% /opt /dev/sda7122160 28 1221321% /tmp /dev/sda9 1220608 18510 12020982% /var /dev/sda3 4890624 68947 48216772% /home /dev/sda5 61056392606641% /boot tmpfs506243 11 5062321% /run/user/0 /dev/sdd1 0 00 - /root/corsair du -h -d 1 2.7G ./opt 417M ./root 6.5G ./var 0 ./sys 16K ./lost+found 16M ./etc 7.5M ./run 12K ./media 4.0K ./lib64 5.0G ./home 7.2G ./usr 13M ./sbin 12M ./bin 68K ./tmp 564M ./lib 868G ./mnt 6.1M ./lib32 4.0K ./srv 232M ./boot 0 ./dev 4.0K ./.cache 0 ./proc 890G . Est ce que cela vous semble suffisant pour l'upgrade? Et dans l'affirmative, que faut-il faire ensuite? Je n'en ai pas la moindre idée et je ne voudrai pas exécuter de commande qui pourrait faire empirer le probleme. Très cordialement Hugues Le lun. 12 févr. 2024 à 13:22, Michel Verdier a écrit : > Le 12 février 2024 Hugues MORIN-TRENEULE a écrit : > > > J'ai effectivement vu ce message mais je n'en avais pas compris la > raison. > > Néanmoins, au vue de df -TPh, je m’aperçois que ma partition racine et > > /boot son bien "chargées". > > Est ce que le problème pourrait provenir de la? > > Le message repéré par Alban porte sur /lib donc ton / > qui n'a que 127Mo de libre. La taille des modules varie selon les > kernels. Chez moi ça prend dans les 80Mo. Et il faut compter des fichiers > temporaires pendant l'installation. Déjà fais peut-être le ménage dans > les kernels que tu n'utilise pas, ton /boot semble pas mal rempli. Ce > n'est pas gênant pour /boot qui a de la marge mais ça libérera aussi de > la place sur / > > > /dev/sda1 ext4 1.8G 1.6G 127M 93% / > > /dev/sda8 ext4 28G 7.2G 19G 28% /usr > > /dev/sda10 ext4 28G 2.7G 24G 11% /opt > > /dev/sda7 ext4 1.8G 72K 1.7G 1% /tmp > > /dev/sda9 ext4 19G 6.5G 11G 38% /var > > /dev/sda3 ext4 73G 5.0G 65G 8% /home > > /dev/sda5 ext4 920M 379M 478M 45% /boot > > Pourquoi avoir découpé sda en autant de partitions ? Ca n'augmente pas la > sécurité et tu perds plein de place sur certaines alors que d'autres > saturent. > >
Re: Stretch vers Bullseye - Probleme lors du apt full-upgrade
Bonjour J'ai effectivement vu ce message mais je n'en avais pas compris la raison. Néanmoins, au vue de df -TPh, je m’aperçois que ma partition racine et /boot son bien "chargées". Est ce que le problème pourrait provenir de la? Voila le résultat des commandes demandées: df -TPh Filesystem Type Size Used Avail Use% Mounted on udev devtmpfs 2.0G 0 2.0G 0% /dev tmpfs tmpfs 396M 7.5M 389M 2% /run /dev/sda1 ext4 1.8G 1.6G 127M 93% / /dev/sda8 ext4 28G 7.2G 19G 28% /usr tmpfs tmpfs 2.0G 0 2.0G 0% /dev/shm tmpfs tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup /dev/sdc1 ext4 916G 583G 287G 68% /mnt/data2 /dev/sdb1 fuseblk 299G 285G 14G 96% /mnt/data /dev/sda10 ext4 28G 2.7G 24G 11% /opt /dev/sda7 ext4 1.8G 72K 1.7G 1% /tmp /dev/sda9 ext4 19G 6.5G 11G 38% /var /dev/sda3 ext4 73G 5.0G 65G 8% /home /dev/sda5 ext4 920M 379M 478M 45% /boot tmpfs tmpfs 396M 0 396M 0% /run/user/0 df -i Filesystem Inodes IUsedIFree IUse% Mounted on udev 502193473 5017201% /dev tmpfs506243823 5054201% /run /dev/sda1122160 3689185269 31% / /dev/sda8 1831424 311408 1520016 18% /usr tmpfs506243 1 5062421% /dev/shm tmpfs506243 4 5062391% /run/lock tmpfs506243 16 5062271% /sys/fs/cgroup /dev/sdc1 61054976 13288 610416881% /mnt/data2 /dev/sdb1 14184328 6185 141781431% /mnt/data /dev/sda10 1831424797 18306271% /opt /dev/sda7122160 28 1221321% /tmp /dev/sda9 1220608 18509 12020992% /var /dev/sda3 4890624 68947 48216772% /home /dev/sda5 61056412606441% /boot tmpfs506243 11 5062321% /run/user/0 Très cordialement Hugues Le lun. 12 févr. 2024 à 08:19, Alban Vidal a écrit : > Bonjour Hugues, > > Dans les logs il ressort le message "failed to write (No space left on > device)" qui signifie qu'il n'y a plus d'espace libre. > > Peux-tu nous transmettre le retour des commandes suivantes : > df -TPh > df -i > > Cordialement, > Alban > > > Le 12 février 2024 08:00:00 GMT+01:00, Hugues MORIN-TRENEULE < > mor...@gmail.com> a écrit : > >> Bonjour a tous >> >> >> Je reviens vers vous car je ne sais pas comment m'y prendre pour réparer >> un crash lors d'un apt full-upgrade lors d'un passage de Stretch a Bullseye. >> >> Il y a quelques temps vos conseils et explications mon permis de de >> mettre a jours mon Stretch afin de le préparer à l'upgrade vers Bullseye >> (cf "Mise à jours et Update Stretch - Problème de dépôt" sur la liste => >> https://lists.debian.org/debian-user-french/2023/08/msg00289.html) >> >> En résumé, j'ai oublié de faire l'upgrade de mon stretch en temps et en >> heure. Quand j'ai voulu le faire, les dépôts de mon sources.list n'étaient >> plus valide. Votre aide m'a permis d'avoir les bons dépôts et de mettre a >> jours mon Stretch à sa dernière version avant de lancer l'upgrade. >> Jusque là aucun probleme. >> >> Une fois a jour, j'ai lancé la procédure d'upgrade de Stretch à Bullseye >> en suivant pas à pas la procedure decrite par debian.org: >> >> https://www.debian.org/releases/bookworm/amd64/release-notes/ch-upgrading.fr.html >> >> Tout s'est bien passé jusqu'au apt full-upgrade (paragraphe 4.4.6). >> J'ai fait les contrôles demandés, fait les sauvegardes. >> J'ai utilisé a plusieurs reprises les procédures d'upgrade de debian.org >> sans jamais rencontrer de probleme, c'est la 1ere fois que j'ai un crash >> lors de celle-ci et je ne sais pas trop que faire car je ne maitrise pas du >> tout le sujet. >> J'ai bien entendu tenté de faire quelques recherches mais cela ne m'a >> conduit a rien de concluant, soit ça n'a rien à voir, soit je ne comprends >> pas ce que je lis... >> >> Le probleme est survenu à environ 45% de l'installation. >> Voila le dernier message en console: >> [...] >> Selecting previously unselected package libnss-systemd:amd64. >> Preparing to unpack .../345-libnss-systemd_241-7~deb10u10_amd64.deb ... >> Unpacking libnss-systemd:amd64 (241-7~deb10u10) ... >> Errors were encountered while processing: >> >> >> /tmp/apt-dpkg-install-H5Vafy/261-linux-image-4.19.0-25-amd64_4.19.289-2_amd64.deb >> E: Sub-process /usr/bin/dpkg returned an error code (1) >> >> >> J'ai trouvé 2 messages d'erreurs avant le crash définiti
Stretch vers Bullseye - Probleme lors du apt full-upgrade
Bonjour a tous Je reviens vers vous car je ne sais pas comment m'y prendre pour réparer un crash lors d'un apt full-upgrade lors d'un passage de Stretch a Bullseye. Il y a quelques temps vos conseils et explications mon permis de de mettre a jours mon Stretch afin de le préparer à l'upgrade vers Bullseye (cf "Mise à jours et Update Stretch - Problème de dépôt" sur la liste => https://lists.debian.org/debian-user-french/2023/08/msg00289.html) En résumé, j'ai oublié de faire l'upgrade de mon stretch en temps et en heure. Quand j'ai voulu le faire, les dépôts de mon sources.list n'étaient plus valide. Votre aide m'a permis d'avoir les bons dépôts et de mettre a jours mon Stretch à sa dernière version avant de lancer l'upgrade. Jusque là aucun probleme. Une fois a jour, j'ai lancé la procédure d'upgrade de Stretch à Bullseye en suivant pas à pas la procedure decrite par debian.org: https://www.debian.org/releases/bookworm/amd64/release-notes/ch-upgrading.fr.html Tout s'est bien passé jusqu'au apt full-upgrade (paragraphe 4.4.6). J'ai fait les contrôles demandés, fait les sauvegardes. J'ai utilisé a plusieurs reprises les procédures d'upgrade de debian.org sans jamais rencontrer de probleme, c'est la 1ere fois que j'ai un crash lors de celle-ci et je ne sais pas trop que faire car je ne maitrise pas du tout le sujet. J'ai bien entendu tenté de faire quelques recherches mais cela ne m'a conduit a rien de concluant, soit ça n'a rien à voir, soit je ne comprends pas ce que je lis... Le probleme est survenu à environ 45% de l'installation. Voila le dernier message en console: [...] Selecting previously unselected package libnss-systemd:amd64. Preparing to unpack .../345-libnss-systemd_241-7~deb10u10_amd64.deb ... Unpacking libnss-systemd:amd64 (241-7~deb10u10) ... Errors were encountered while processing: /tmp/apt-dpkg-install-H5Vafy/261-linux-image-4.19.0-25-amd64_4.19.289-2_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) J'ai trouvé 2 messages d'erreurs avant le crash définitif: [...] Selecting previously unselected package linux-image-4.19.0-25-amd64. Preparing to unpack .../261-linux-image-4.19.0-25-amd64_4.19.289-2_amd64.deb ... Unpacking linux-image-4.19.0-25-amd64 (4.19.289-2) ... dpkg: error processing archive /tmp/apt-dpkg-install-H5Vafy/261-linux-image-4.19.0-25-amd64_4.19.289-2_amd64.deb (--unpack): cannot copy extracted data for './lib/modules/4.19.0-25-amd64/kernel/fs/jbd2/jbd2.ko' to '/lib/modules/4.19.0-25-amd64/kernel/fs/jbd2/jbd2.ko.dpkg-new': failed to write (No space left on device) dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Preparing to unpack .../262-linux-image-amd64_4.19+105+deb10u20_amd64.deb ... Unpacking linux-image-amd64 (4.19+105+deb10u20) over (4.9+80+deb9u17) ... Preparing to unpack .../263-lnav_0.8.4-5_amd64.deb ... [...] et [...] Unpacking nautilus-extension-gnome-terminal (3.30.2-2) ... Preparing to unpack .../276-network-manager-openvpn_1.8.10-1_amd64.deb ... Unpacking network-manager-openvpn (1.8.10-1) over (1.2.8-2) ... dpkg: warning: unable to delete old directory '/etc/NetworkManager/VPN': Directory not empty Preparing to unpack .../277-network-manager-openvpn-gnome_1.8.10-1_amd64.deb ... Unpacking network-manager-openvpn-gnome (1.8.10-1) over (1.2.8-2) ... Preparing to unpack .../278-openvpn_2.4.7-1+deb10u1_amd64.deb ... [...] J'ai sauvegardé tous les log après le crash et tout ce qui s'affichait en console. J'ai aussi à dispo le script enregistré lors de l'upgrade. Je n'ai rien fait de plus depuis le crash si ce n'est d'allumer la machine pour faire la sauvegarde des log. Je dois avouer ne pas savoir du tout ce qu'il faut faire pour réparer, je suis dans une impasse. Toute aide sera la bienvenue ;-) Très cordialement Hugues
Re: Mise à jours et Update Stretch - Problème de dépôt
Salut Bon ... Un peu beaucoup de temps est passé mais j'ai enfin pu faire cet upgrade. J'ai tout d'abord vérifié les dépôts enregistrés dans mon source.list afin de savoir quel paquet dépend d'eux. Il en résulte que le dépôt volatile n'a effectivement aucune utilité (sur mon système). J'ai ensuite checker les dépôt archive.debian. org afin de vérifier s'il contenait des mises à jour mais il n'y en avait pas. J'ai poursuivi avec les dépôts ELTS que cite Daniel en suivant la procédure qu'il a donné. Mon Stretch étant alors à jour j'ai commencé l'upgrade vers Buster. La mise à niveau minimale du système avec apt-get upgrade s'est déroulé sans probleme J'ai alors lancé dans la foulée la mise à niveau complète avec apt full-upgrade... Et la ... c'est le drame, au environ de 45% il y a eu des erreurs (une histoire de suppression de /etc/init) Mon système ne fonctionne plus depuis, il bloque au démarrage. J'ai suivi pas à pas la méthode du site Debian: https://www.debian.org/releases/buster/amd64/release-notes/ch-upgrading.fr.html Je ne pense pas que l'erreur soit liée aux mises à jours faites par le dépôt ELTS. A moins que l'un d'entre vous voit une corrélation entre les mises à jours faites avec le dépôt ELTS et le crash de mon update, je pense que ce sujet peut-être clôturé. Par contre, je dois avouer mon incompétence totale pour réparer et remettre en route mon système. Je vais faire quelques recherches pour trouver une solution mais mon niveau risque de ne pas être suffisant pour comprendre ce que je lis. Après avoir réunir mes fichiers de log et l'enregistrement de mon upgrade, il y a de forte chance que j'ouvre un nouveau sujet pour avoir un peu d'aide pour réparer Merci à tous Très cordialement Hugues Le jeu. 31 août 2023, 16:18, Daniel SAUVARD a écrit : > Bonjour. > > Depuis l'année dernière, Debian n'assure plus le support de Stretch (fin > du support LTS). Un support partiel reste possible via le projet > Extended Long Term Support (ELTS, https://wiki.debian.org/LTS/Extended ; > pour 5 ans, soit jusqu'au 2027-06-30). Il faut supprimer les dépôts > Debian (qui ne sont à priori plus accessibles) et les remplacer par ceux > de Freexian). > > En pratique : > - Éditer le fichier source.list et désactiver les dépôts Debian. > - Ajouter la clé de l'archive Freexian. > # wget > > https://deb.freexian.com/extended-lts/pool/main/f/freexian-archive-keyring/freexian-archive-keyring_2022.06.08_all.deb > && dpkg -i freexian-archive-keyring_2022.06.08_all.deb >Contrôler la clé avec « # apt-key finger | less », en comparant > l'empreinte avec celle indiquée sur la page > https://www.freexian.com/lts/extended/docs/how-to-use-extended-lts/. > - Activer les dépôts Freexian, par exemple en créant le fichier > /etc/apt/sources.list.d/extended-lts.list, contenant : > # ELTS archive > deb http://deb.freexian.com/extended-lts stretch-lts main >Nota Le serveur n'utilise pas les dépôts contrib et non-free. > - Mettre à jour du système : > # apt update > # apt upgrade >Redémarrer le système si le noyau a été mis à jour. > > Cordialement, > Daniel Sauvard > > > > Le 29/08/2023 à 13:53, Hugues MORIN-TRENEULE a écrit : > > Salut à tous > > > > J'ai fait une boulette, je n'ai pas upgradé . > > A force de me procrastiner l'upgrade d'une machine sous Stretch dont je > > me sers occasionnellement, je me trouve un peu embêter aujourd'hui. > > > > En voulant faire un petit check des mises à jour, je me suis aperçu que > > les dépôts Stretch enregistrés dans mon source.list n'existe plus: > > # deb cdrom:[Debian GNU/Linux 9.2.1 _Stretch_ - Official amd64 NETINST > > 20171013-13:07]/ stretch main > > > > #deb cdrom:[Debian GNU/Linux 9.2.1 _Stretch_ - Official amd64 NETINST > > 20171013-13:07]/ stretch main > > > > deb http://ftp.fr.debian.org/debian/ <http://ftp.fr.debian.org/debian/> > > stretch main contrib non-free > > deb-src http://ftp.fr.debian.org/debian/ > > <http://ftp.fr.debian.org/debian/> stretch main contrib non-free > > > > deb http://security.debian.org/debian-security > > <http://security.debian.org/debian-security> stretch/updates main > > contrib non-free > > deb-src http://security.debian.org/debian-security > > <http://security.debian.org/debian-security> stretch/updates main > > contrib non-free > > > > # stretch-updates, previously known as 'volatile' > > deb http://ftp.fr.debian.org/debian/ <http://ftp.fr.debian.org/debian/> > > stretch-updates main contrib non-free > > deb-src http://ftp.fr.debian.org/debian/ > > <http://ftp.fr.debian.org/debian/> stretch-updates main contrib non-free > > > > J'aimerai upgrader cet
Re: Comment superposer par programme, du texte sur un PDF ?
Salut Pour la manipulation des PDF, j'utilise pdftk ( https://doc.ubuntu-fr.org/pdftk) Apres un peu d'habitude, il est facile a utiliser. Je n'ai jamais teste mais il peut mettre un filigrame sur un document PDF. Bonne journée Hugues Le lun. 20 nov. 2023 à 10:01, Olivier a écrit : > Bonjour, > > Je travaille régulièrement des plan d'architecte au format PDF sur > lesquels je souhaite superposer par programme des symboles ou du texte > (extraits d'un fichier CSV). > > J'ai découvert que le format SVG avait l'air bien adapté à la > production par programme d'un dessin mais je n'ai pas l'impression > s'il soit possible d'y intégrer "un fond de carte". > > Que conseillez-vous pour produire ces cartes ? > > Slts > >
Re: Mise à jours et Update Stretch - Problème de dépôt
Bonjour Merci à tous pour vos réponses et vos conseils, maintenant ... yapluka ;-) Je vais faire des upgrade successif car je tiens a garder la configuration de certains programme. Concernant les dépôts "security" et "volatile", je ne sais quels sont les paquets qui en dépendent. Je vais commencer par vérifier cela et je desactiverai le cas échéant. Pour les archives de la liste (ou si je rencontre un probleme), je posterai le résultat des upgrade. Bonne journée Très cordialement Hugues Le mar. 29 août 2023 à 15:03, Michel Verdier a écrit : > Le 29 août 2023 Hugues MORIN-TRENEULE a écrit : > > > Concernant les dépôts "security" et "volatile", existe-t-il aussi des > > dépôts archive que je pourrai utiliser? > > Le mieux est de les commenter durant les upgrade et de les rebrancher > seulement quand tout est stabilisé pour un ultime upgrade. C'est > d'ailleurs ce qui est préconisé pour l'upgrade bullseye -> bookworm. > > Et n'oublie pas l'upgrade en 2 temps. > > > https://www.debian.org/releases/bookworm/amd64/release-notes/ch-upgrading.fr.html#minimal-upgrade > >
Mise à jours et Update Stretch - Problème de dépôt
Salut à tous J'ai fait une boulette, je n'ai pas upgradé . A force de me procrastiner l'upgrade d'une machine sous Stretch dont je me sers occasionnellement, je me trouve un peu embêter aujourd'hui. En voulant faire un petit check des mises à jour, je me suis aperçu que les dépôts Stretch enregistrés dans mon source.list n'existe plus: # deb cdrom:[Debian GNU/Linux 9.2.1 _Stretch_ - Official amd64 NETINST 20171013-13:07]/ stretch main #deb cdrom:[Debian GNU/Linux 9.2.1 _Stretch_ - Official amd64 NETINST 20171013-13:07]/ stretch main deb http://ftp.fr.debian.org/debian/ stretch main contrib non-free deb-src http://ftp.fr.debian.org/debian/ stretch main contrib non-free deb http://security.debian.org/debian-security stretch/updates main contrib non-free deb-src http://security.debian.org/debian-security stretch/updates main contrib non-free # stretch-updates, previously known as 'volatile' deb http://ftp.fr.debian.org/debian/ stretch-updates main contrib non-free deb-src http://ftp.fr.debian.org/debian/ stretch-updates main contrib non-free J'aimerai upgrader cette machine (tout d'abord vers buster) mais avant cela il faudrait que je mette à jours les paquets de stretch pour ne pas avoir de soucis avec les upgrade a venir. Pour le dépot principal (http://ftp.fr.debian.org/debian/ stretch) , en cherchant, j'ai trouvé le depot archive Debian: http://archive.debian.org/debian Est ce que vous pourriez me confirmer qu'il me permettra de mettre les paquets de stretch à jours jusqu'à leur dernière version. Concernant les dépôts "security" et "volatile", existe-t-il aussi des dépôts archive que je pourrai utiliser? Je ne maitrise pas bien tout ce qui est en lien avec les dépôts et les mise à jours donc je suis ouvert à vos suggestions et conseils. Bonne journée Cordialement Hugues
Re: Utilitaire Debian pour récupérer SMS Androïd
Salut Je n'ai pas de connaissance particulière concernant l'opération que vous voulez faire mais je pense que vouloir "connecter" directement le mobile à votre Debian n'est pas la solution la plus simple pour transferer des sms. Vous devriez essayer de trouver une solution à partir d'android. Soit en transférant vos sms de votre ancien mobile au nouveau, soit en générant un fichier contenant vos sms que vous pourrez transférer via USB. Ce fichier devra bien sûr être utilisable et lisible sur le système sur lequel vous le transférer, que ce soit Debian ou Android ( ou meme windows ). Apres une petite recherche rapide, j'ai trouvé ces 3 liens qui me semble etre de bonne piste: https://linuxfr.org/users/raphj/journaux/sauvegarde-des-sms-mms-et-du-journal-d-appels-sous-android https://f-droid.org/fr/packages/com.zegoggles.smssync/ https://www.frandroid.com/comment-faire/tutoriaux/449088_comment-transferer-ses-sms-sur-son-nouveau-smartphone-android En esperant que ca vous aidera Bonne journée Hugues Le jeu. 6 juil. 2023 à 10:34, Thierry a écrit : > Bonjour à tous. > > Le besoin est dans le sujet. > En détail, j'ai un vieux téléphone sous Android V6.0, sur lequel il est > impossible d'installer quoi que ce soit (pb de compatibilité). J'ai pu > récupérer facilement les photos, fichiers, etc.. par transfert de > fichiers, mais je ne vois pas comment récupérer les SMS/MMS. Il y a un > gros historique que je voudrais conserver. > Tout ce que j'ai pu trouver sur le web sont des utilitaires Windows > payants, ou des applis Android à installer (ce qui n'est plus possible) > > Merci pour vos suggestions. > > >
Re: Libreoffice enregistrer fichier dans NAS
Salut C'est bizarre que ca ne fonctionne pas chez toi Mon libreoffice est : Version: 6.1.5.2 Build ID: 1:6.1.5-3+deb10u8 Threads CPU : 8; OS : Linux 4.19; UI Render : par défaut; VCL: gtk3; Locale : fr-FR (fr_FR.UTF-8); Calc: group threaded Il faut peut etre que tu installes des paquets supplementaires pour prendre en charge le montage de dossier distant avec samba. Ca fait longtemps que je l'ai fait, je ne me rappelle plus tres bien, mais il me semble que j'avais rencontré une difficulté comme ca. J'ai les paquets suivants qui sont installés sur mon systeme, c'est peut etre juste un de ces paquets qui te manque: i A samba-libs - bibliothèques principales de Samba i A libwbclient0 - bibliothèque cliente Samba winbind i cifs-utils - utilitaires du système de fichier CIFS i A libsmbclient - bibliothèque partagée pour la communication avec des serveurs SMB/CIFS i A ntfs-3g - pilote de lecture et écriture NTFS pour FUSE i A fuse - système de fichier en espace utilisateur i A gvfs-fuse - système de fichiers virtuel en espace utilisateur – serveur fuse Je crois que j'avais du utiliser ce tuto pour mettre en place cette maniere de fonctionner avec mon NAS: https://doc.ubuntu-fr.org/samba Bonne soiree Hugues Le mar. 2 mai 2023 à 17:47, Frederic Zulian a écrit : > Bjr, > > Au final, je viens de découvrir que l'on peut enregistrer/ouvrir des > fichiers distants avec > Libreofifice :Version: 7.4.5.1 > > Fichier --> ouvrir distant --> choisir le service (éditer/ajouter ssh, > ftp, smb, ...). > > Parce que smb dans mon fstab ce n'est pas top. > Il me demande ID et mot de passe puis : mount error(95): Operation not > supported > > Ligne dans /etc/fstab //192.168.1.79/export/Lettres /media/documents >cifs > > credentials=/root/.smbcredentials,iocharset=utf8,gid=1000,uid=1000,vers=1.0,_netdev > 0 0 > > > Frédéric ZULIAN > > > Le ven. 28 avr. 2023 à 09:12, Michel Verdier a écrit : > >> Le 27 avril 2023 Frederic Zulian a écrit : >> >> >> # Monter NAS >> >> //192.168.0.XXX/Repertoire/mnt/MON_NAS_MOUNT cifs >> >> >> credentials=/root/.smbcredentials,iocharset=utf8,gid=1000,uid=1000,vers=1.0,_netdev >> >>0 0 >> >> Dans ta commande mount on voit que ce point de montage n'est pas >> monté. Dolphin doit le faire à la volée mais libreoffice ne sait pas >> faire ça. Donc ton problème est que le point de montage ne se fait >> pas (sans doute au boot). Commence par le faire manuellement pour voir si >> tu as des warnings, ou regarde dans tes logs. Ça peut venir de la version >> cifs (vs version sur ton NAS) ou autre chose. >> >>
Re: Libreoffice enregistrer fichier dans NAS
Salut Mes connaissances sont bien moins avancées que les tiennes et donc mes solutions sont un peu triviales. Je n'utilise ni recoll ni locate car je ne connaissais pas avant que tu n'en parles. Quand je cherche un fichier soit j'utilise find soit j'utilise la recherche de caja (je suis sous mate) dans l'explorateur de fichier. Je n'utilise que tres peu la recherche de fichier, donc le temps de recherche m'importe peu. Juste pour info mon nas DLink DNS-320L qui a déjà plusieurs années (7 ou 8). Bonne journée Hugues Le jeu. 27 avr. 2023 à 23:10, Frederic Zulian a écrit : > Hmm, j'ai accès aux fichiers stockés sur le NAS. Cela ne pose pas de > problème. > > Par contre, recoll refuse de les indexer à partir d'un PC distant. locate > fonctionne pour retrouver un fichier, mais > ce n'est pas particulièrement pratique > > Comment procèdes-tu pour retrouver un fichier stocké sur ton NAS ? > > Frédéric ZULIAN > -- > Pour la santé de votre ordinateur, préférez les logiciels libres. > https://www.april.org/ > > > > Le jeu. 27 avr. 2023 à 18:43, Hugues MORIN-TRENEULE a > écrit : > >> Salut >> >> J'utilise quotidiennement mon NAS comme si c'etait un disque local sans >> aucun probleme. >> J'utilise Samba pour acceder au NAS >> Voila ce que j'ai et qui fonctionne chez moi: >> >> # Monter NAS >> //192.168.0.XXX/Repertoire/mnt/MON_NAS_MOUNT cifs >> >> credentials=/root/.smbcredentials,iocharset=utf8,gid=1000,uid=1000,vers=1.0,_netdev >>0 0 >> >> credentials=/root/.smbcredentials contient le login/mdp pour avoir acces >> au NAS >> >> J'espere que ca pourra t'aider un peu >> >> Cordialement >> Hugues >> >> >> Le jeu. 27 avr. 2023 à 16:59, Frederic Zulian a >> écrit : >> >>> Bonjour, >>> >>> Lorsque je tente d'enregistrer un fichier à partir de libre-office sur >>> un partage de mon NAS. >>> J'ai un message d'erreur : "Pas de point de montage." >>> >>> Pourtant j'accède à mes partages sur mon NAS* avec, par exemple, Dolphin >>> sans pb. >>> >>> Un cat /etc/fstab montre que les partitions (lettres et photos) sont >>> bien présentes : >>> >>> # / was on /dev/sdc1 during installation >>> UUID=6f9136f0-b63f-4665-a3f9-4d5c929de219 / ext4 >>>errors=remount-ro 0 1 >>> # swap was on /dev/sdc5 during installation >>> UUID=5161aff4-db4f-409a-93c8-5e05e1f43756 noneswapsw >>> 0 0 >>> /dev/sr0/media/cdrom0 udf,iso9660 user,noauto 0 0 >>> # >>> [openmediavault] >>> /dev/disk/by-uuid/7c90f245-23c5-4c0d-8273-95adf22ae13f >>> /srv/dev-disk-by-uuid-7c90f245-23c5-4c0d-8273-95adf22ae13f >>> ext4 >>> >>> defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl >>> 0 2 >>> /dev/disk/by-uuid/17360400-f430-4b4d-b096-0a767c99f96f >>> /srv/dev-disk-by-uuid-17360400-f430-4b4d-b096-0a767c99f96f >>> ext4 >>> >>> defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl >>> 0 2 >>> /srv/dev-disk-by-uuid-7c90f245-23c5-4c0d-8273-95adf22ae13f/Lettres/ >>> /export/Lettres nonebind,nofail 0 0 >>> /srv/dev-disk-by-uuid-7c90f245-23c5-4c0d-8273-95adf22ae13f/Photos/ >>> /export/Photos nonebind,nofail 0 0 >>> /fred/ /export/frednonebind,nofail 0 0 >>> # <<< [openmediavault] >>> $ >>> >>> *NAS = opnemediavault, répertoires partagés avec samba et NFS. >>> >>> Une idée ? >>> >>> Frédéric ZULIAN >>> -- >>> Pour la santé de votre ordinateur, préférez les logiciels libres. >>> https://www.april.org/ >>> >>>
Re: Libreoffice enregistrer fichier dans NAS
Salut J'utilise quotidiennement mon NAS comme si c'etait un disque local sans aucun probleme. J'utilise Samba pour acceder au NAS Voila ce que j'ai et qui fonctionne chez moi: # Monter NAS //192.168.0.XXX/Repertoire/mnt/MON_NAS_MOUNT cifs credentials=/root/.smbcredentials,iocharset=utf8,gid=1000,uid=1000,vers=1.0,_netdev 0 0 credentials=/root/.smbcredentials contient le login/mdp pour avoir acces au NAS J'espere que ca pourra t'aider un peu Cordialement Hugues Le jeu. 27 avr. 2023 à 16:59, Frederic Zulian a écrit : > Bonjour, > > Lorsque je tente d'enregistrer un fichier à partir de libre-office sur un > partage de mon NAS. > J'ai un message d'erreur : "Pas de point de montage." > > Pourtant j'accède à mes partages sur mon NAS* avec, par exemple, Dolphin > sans pb. > > Un cat /etc/fstab montre que les partitions (lettres et photos) sont bien > présentes : > > # / was on /dev/sdc1 during installation > UUID=6f9136f0-b63f-4665-a3f9-4d5c929de219 / ext4 >errors=remount-ro 0 1 > # swap was on /dev/sdc5 during installation > UUID=5161aff4-db4f-409a-93c8-5e05e1f43756 noneswapsw > 0 0 > /dev/sr0/media/cdrom0 udf,iso9660 user,noauto 0 0 > # >>> [openmediavault] > /dev/disk/by-uuid/7c90f245-23c5-4c0d-8273-95adf22ae13f > /srv/dev-disk-by-uuid-7c90f245-23c5-4c0d-8273-95adf22ae13f > ext4 > > defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl > 0 2 > /dev/disk/by-uuid/17360400-f430-4b4d-b096-0a767c99f96f > /srv/dev-disk-by-uuid-17360400-f430-4b4d-b096-0a767c99f96f > ext4 > > defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl > 0 2 > /srv/dev-disk-by-uuid-7c90f245-23c5-4c0d-8273-95adf22ae13f/Lettres/ > /export/Lettres nonebind,nofail 0 0 > /srv/dev-disk-by-uuid-7c90f245-23c5-4c0d-8273-95adf22ae13f/Photos/ > /export/Photos nonebind,nofail 0 0 > /fred/ /export/frednonebind,nofail 0 0 > # <<< [openmediavault] > $ > > *NAS = opnemediavault, répertoires partagés avec samba et NFS. > > Une idée ? > > Frédéric ZULIAN > -- > Pour la santé de votre ordinateur, préférez les logiciels libres. > https://www.april.org/ > >
Re: quel espace laisser à Windows
Bonjour Sur mon portable, j'ai un disque de 128Go pour W10 ou j'ai 86Go de libre Il y a 2 ou 3 logiciels installe mais rien de gourmand. Je pense qu'avec 50/60Go ca devrai le faire Bonne journee Hugues Le jeu. 2 févr. 2023 à 10:23, elguero eric a écrit : > bonjour à tous, > > je viens de recevoir un nouvel ordinateur > et pour la première fois depuis longtemps > j'ai dû l'acheter avec Windows installé. Du > coup je me demande si je ne vais pas le > laisser (car je le laisserai quand je partirai > à la retraite, bientôt peut-être...) > > Mais comme je ne compte pas l'utiliser je > voudrais lui laisser le moins d'espace disque > possible, d'autant que je n'ai qu'un disque de 500Gb. > > quelqu'un sait-il quel est l'espace disque minimal > dans lequel Win10 Pro peut tourner? > > e.e. > >
Re: Copier 300GB d'un disque dur a un autre
Salut Merci Hamster pour cette explication très complète, je comprends mieux a quoi sert sync et son importance dans le cadre de manipulation de fichier. La copie de fichier viens de ce finir avec succès :-))) sent 305,600,616,450 bytes received 113,919 bytes 67,083,905.25 bytes/sec total size is 305,525,656,835 speedup is 1.00 J'ai utilisé rsync (sans oublier le sync ;-) #rsync -aPv /mnt/data/projet /mnt/data2/ && sync Tout semble fonctionner correctement sur le nouveau disque. Il n'y a plus qu'à le remplir :D Je vous adresse a tous un TRES GRAND MERCI :) pour votre aide, vos conseils et votre assistance, et en particulier à Hamster pour sa disponibilité. Très cordialement Hugues Le ven. 16 sept. 2022 à 13:04, hamster a écrit : > Le 16/09/2022 à 11:49, Hugues MORIN-TRENEULE a écrit : > > Salut > > > > Dans la commande > > rsync -aPv /xxx/yyy/source /vvv/zzz/destination && sync > > > > Le "sync" correspond bien à cette commande: > > http://manpagesfr.free.fr/man/man8/sync.8.html > > <http://manpagesfr.free.fr/man/man8/sync.8.html> > > J'ai compris qu'elle permettait de s'assurer que le contenu en > > mémoire soit bien inscrit sur le disque mais je ne comprends pas bien > > pourquoi on l'appelle après rsync? > > Quelle est sa fonction dans le processus de copie? > > Dans un disque mécanique, il y a une tete le lecture qui bouge. Plus on > la fait bouger, plus le mécanisme s'use. C'est donc une bonne idée > d'économiser les mouvements de cette tete de lecture. > > Un moyen simple de le faire, c'est de ne pas aller écrire chaque chose a > écrire au fur et a mesure mais de les grouper. Il y a donc une mémoire > cache. Quand tu écris quelque chose sur le disque, en fait c'est pas > écrit directement sur le disque mais dans la mémoire cache. Quand cette > mémoire cache est pleine, tout son contenu est écrit en une fois sur le > disque. Et puis ca recommence. > > Comme le système fait beaucoup de toutes petites écritures (a savoir > rajouter une ligne dans un fichier de log) le fait de grouper ainsi les > écritures fait économiser beaucoup de mouvements de la tete de lecture, > et prolonge d'autant la durée de vie du disque. > > Mais ca a aussi un défaut : quand tu écris quelque chose sur le disque, > en fait ca s'écrit pas, ca attend que le cache soit plein pour s'écrire > vraiment. Typiquement si tu écris un gros fichier, ca remplit le cache, > ca l'écrit sur le disque, ca re-remplit le cache, ca l'écrit sur le > disque, etc… un certain nombre de fois. Et puis arrive la fin du > fichier. Le dernier morceau du fichier n'est pas assez gros pour remplir > le cache, alors il est pas écrit tout de suite. Et tu te retrouve > pendant un certain temps avec un fichier qui est écrit sur le disque, > sauf la toute fin. Combien de temps dure ce "certain temps" ? Jusqu'a ce > que tu ait écrit suffisamment d'autres trucs pour finir de remplir le > cache. > > La commande sync force l'écriture de ce qui est dans le cache, meme si > il n'est pas plein. Tu peux la lancer a la main, et elle est aussi > lancée automatiquement quand tu démonte un truc. C'est pour ca qu'il ne > faut pas débrancher un disque externe sans l'éjecter au préalable. Quand > tu éjecte le disque externe, ca lance sync pour vider le cache et ca le > démonte. Tu peux alors le débrancher sans qu'il n'y ait le dernier bout > du dernier fichier écrit qui reste oublié dans le cache. > > PS : les clef USB, les cartes mémoire, les disque SSD (tout ce qui est > de la mémoire flash en fait) n'ont pas de tete de lecture qui bouge. > Grouper ainsi les écritures n'économise en rien leur usure. Dans ce cas, > le cache est plus une source d'ennui qu'autre chose. Ca oblige a faire > une action manuelle pour prévenir le système qu'on va débrancher. Ca > fait des fichiers corrompus en cas de débranchement intempestif. Qui n'a > jamais eu de faux contact dans une prise USB ??? > > Et puis ca empeche de faire une barre de progression réaliste pour les > trucs avec une vitesse d'écriture un peu lente. > > Tu a peut etre remarqué que quand tu écris un gros fichier sur une clef > USB, au début la barre de progression avance super vite. Tu te dis > "super, ca va pas durer longtemps". Et puis la barre de progression > ralentit brusquement et sur la fin du fichier elle avance comme un > escargot, pendant que tu fulmine en disant "et alors, qu'est-ce que ca > attend, ca allait vite au début". Quand la copie est enfin terminée, tu > fais "ejecter la clef" et la ca se met a te faire poireauter encore un > bon moment avant de te dire "ca y est, vous pouvez retirer la clef sans > risque". > > Tout ca c'est la faute du cache. Au début ca va sup
Re: Copier 300GB d'un disque dur a un autre
Salut Dans la commande rsync -aPv /xxx/yyy/source /vvv/zzz/destination && sync Le "sync" correspond bien à cette commande: http://manpagesfr.free.fr/man/man8/sync.8.html J'ai compris qu'elle permettait de s'assurer que le contenu en mémoire soit bien inscrit sur le disque mais je ne comprends pas bien pourquoi on l'appelle après rsync? Quelle est sa fonction dans le processus de copie? Cordialement Hugues Le ven. 16 sept. 2022 à 10:51, Hugues MORIN-TRENEULE a écrit : > Salut > > Merci pour l'explication > C'est ce que je supputais sans pouvoir le formuler aussi clairement et > précisément que tu l'as fait. > > Même si ce n'est pas optimal, ça fera tres bien l'affaire pour > l'utilisation que j'en ai :-) > > Allez, je passe à la copie ;-) > > Cordialement > Hugues > > Le jeu. 15 sept. 2022 à 22:47, hamster a écrit : > >> Le 15/09/2022 à 21:02, Hugues MORIN-TRENEULE a écrit : >> > Bonsoir >> > >> > Vous m'avez tous déjà bien aidé à sortir d'une sacrée galère dont je >> > cherchais la solution depuis un bout de temps ;-) >> > Merci :) >> > >> > Sinon, est ce que ce problème de taille de secteur logique/physique qui >> > n'est pas optimal, peut être un problème important? >> > Ou est-ce juste une optimisation qui devrait être faite mais qui n'a >> pas >> > de conséquence importante sur le système et la sécurité du stockage de >> > données? >> >> Pas important du tout. Ca ralentit un peu la vitesse d'ecriture et ca >> fait un peu plus travailler le disque, c'est tout. Tu peux très bien >> vivre avec. >> >> Si t'a envie de comprendre : le secteur c'est la plus petite quantité >> qu'on peut manipuler sur le disque. On peut lire ou ecrire un secteur, >> ou meme plusieurs secteurs, mais pas un demi secteur. >> >> Historiquement, les disques avaient des secteurs de 512 octets. Les >> disques récents sont devenus plus gros et ca fait un grand nombre de >> secteurs, alors les secteurs ont été agrandis a 4096 octets (8 fois plus >> grands). >> >> Quand tu a un formattage 512 sur un disque 4096, le microcontroleur >> intégré dans le disque se charge de gerer le truc. >> >> Si tu veux lire un secteur de 512, le microcontroleur va lire le secteur >> 4096 qui contiens ce que tu demande, puis il découpe ce qu'il a lu en 8 >> et te donne le bon morceau. >> >> Si tu veux ecrire un secteur de 512, le microcontroleur calcule dans >> quel secteur 4096 la zone que tu veux écrire va tomber, il lit ce >> secteur 4096, il remplace la bonne zone 512 par ce que tu veux écrire >> puis il re-ecrit le secteur 4096. >> >> Bon, c'est quand meme rare qu'on ecrive juste un secteur 512. Ca arrive >> surtout au début ou a la fin d'un fichier, donc au total ca fait une >> grande quantité de secteurs 4096 écris (par groupes de 8 secteurs 512) >> et un petit nombre de fois ou il fait cette gymnastique. >> >>
Re: Copier 300GB d'un disque dur a un autre
Salut Merci pour l'explication C'est ce que je supputais sans pouvoir le formuler aussi clairement et précisément que tu l'as fait. Même si ce n'est pas optimal, ça fera tres bien l'affaire pour l'utilisation que j'en ai :-) Allez, je passe à la copie ;-) Cordialement Hugues Le jeu. 15 sept. 2022 à 22:47, hamster a écrit : > Le 15/09/2022 à 21:02, Hugues MORIN-TRENEULE a écrit : > > Bonsoir > > > > Vous m'avez tous déjà bien aidé à sortir d'une sacrée galère dont je > > cherchais la solution depuis un bout de temps ;-) > > Merci :) > > > > Sinon, est ce que ce problème de taille de secteur logique/physique qui > > n'est pas optimal, peut être un problème important? > > Ou est-ce juste une optimisation qui devrait être faite mais qui n'a pas > > de conséquence importante sur le système et la sécurité du stockage de > > données? > > Pas important du tout. Ca ralentit un peu la vitesse d'ecriture et ca > fait un peu plus travailler le disque, c'est tout. Tu peux très bien > vivre avec. > > Si t'a envie de comprendre : le secteur c'est la plus petite quantité > qu'on peut manipuler sur le disque. On peut lire ou ecrire un secteur, > ou meme plusieurs secteurs, mais pas un demi secteur. > > Historiquement, les disques avaient des secteurs de 512 octets. Les > disques récents sont devenus plus gros et ca fait un grand nombre de > secteurs, alors les secteurs ont été agrandis a 4096 octets (8 fois plus > grands). > > Quand tu a un formattage 512 sur un disque 4096, le microcontroleur > intégré dans le disque se charge de gerer le truc. > > Si tu veux lire un secteur de 512, le microcontroleur va lire le secteur > 4096 qui contiens ce que tu demande, puis il découpe ce qu'il a lu en 8 > et te donne le bon morceau. > > Si tu veux ecrire un secteur de 512, le microcontroleur calcule dans > quel secteur 4096 la zone que tu veux écrire va tomber, il lit ce > secteur 4096, il remplace la bonne zone 512 par ce que tu veux écrire > puis il re-ecrit le secteur 4096. > > Bon, c'est quand meme rare qu'on ecrive juste un secteur 512. Ca arrive > surtout au début ou a la fin d'un fichier, donc au total ca fait une > grande quantité de secteurs 4096 écris (par groupes de 8 secteurs 512) > et un petit nombre de fois ou il fait cette gymnastique. > >
Re: Copier 300GB d'un disque dur a un autre
Bonsoir Vous m'avez tous déjà bien aidé à sortir d'une sacrée galère dont je cherchais la solution depuis un bout de temps ;-) Merci :) Sinon, est ce que ce problème de taille de secteur logique/physique qui n'est pas optimal, peut être un problème important? Ou est-ce juste une optimisation qui devrait être faite mais qui n'a pas de conséquence importante sur le système et la sécurité du stockage de données? En fonction de votre avis, je passerai à l'étape suivante, à savoir la copie des 300Gb. Bonne soirée Cordialement Hugues Le jeu. 15 sept. 2022 à 19:04, hamster a écrit : > Le 15/09/2022 à 18:50, Hugues MORIN-TRENEULE a écrit : > > Par contre, ça rien changer au niveau de la taille des secteurs > > logique/physique: > > > > Disque /dev/sdc : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs > > Unités : secteur de 1 × 512 = 512 octets > > Taille de secteur (logique / physique) : 512 octets / 4096 octets > > taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets > > Type d'étiquette de disque : gpt > > Identifiant de disque : 10976883-90A9-412E-A78E-EF579FA75262 > > Ah, en effet. > > Heu, désolé mais je saurai pas t'aider plus sur ce coup. > >
Re: Copier 300GB d'un disque dur a un autre
Salut Merci Steve mais j'ai finalement utilisé GParted et lors de la création de la partition on peut faire le choix du format de partition (msdos, gpt, aix, mac,etc...) Par contre, ça rien changer au niveau de la taille des secteurs logique/physique: Disque /dev/sdc : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 4096 octets taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets Type d'étiquette de disque : gpt Identifiant de disque : 10976883-90A9-412E-A78E-EF579FA75262 Périphérique DébutFin Secteurs Taille Type /dev/sdc1 2048 1953523711 1953521664 931,5G Système de fichiers Linux C'est bizarre ... je ne trouve rien qui pourrait mener à une solution sur le net. Sur le forum Ubuntu, j'ai trouvé une personne se posant la même question: https://forum.ubuntu-fr.org/viewtopic.php?id=1000191 Mais ca n'a pas l'air de mener à une solution Est ce que ca pourrait provenir du modèle du disque? Seagate Barracuda 1To ST1000DM010-2EP102 (CC46) Cordialement Hugues Le jeu. 15 sept. 2022 à 16:57, steve a écrit : > Salut, > > Pour convertir de MBR vers GPT, il faut utiliser le programme gdisk. > > https://www.explorelinux.com/convert-disk-mbr-to-gpt-on-linux/ > > Rien de bien sorcier. > > Bon courage. > > steve >
Re: Copier 300GB d'un disque dur a un autre
Salut > Je me demande si ce n’est pas lié au format du partitionnement (ancien style msdos / nouveau format GPT) ? La, je dois avouer que ça dépasse mes compétences et je ne sais pas comment basculer de l'un à l'autre lors du partionnement/formatage Je vais essayer de repartitionner et formater avec GParted. Ça fonctionne pour Hamster, ca devrait fonctionner pour moi aussi. Cordialement Hugues Le jeu. 15 sept. 2022 à 08:58, Frédéric BOITEUX a écrit : > Bonjour, > > > > Vu que c’est fdisk qui te sort l’info, c’est plutôt lié aux > partitionnement qu’aux systèmes de fichiers que les partitions contiennent… > > > > Je me demande si ce n’est pas lié au format du partitionnement (ancien > style msdos / nouveau format GPT) ? > > > > Cdlt, > > Fred. > > > > *De :* Hugues MORIN-TRENEULE > *Envoyé :* mercredi 14 septembre 2022 22:19 > *À :* Liste Debian > *Objet :* Re: Copier 300GB d'un disque dur a un autre > > > > Salut > > > > Oui, je l'ai fait un peu à la "va vite" en utilisant l'interface > graphique... > > > > Je viens de reprendre tout ca proprement > > D'abord avec un fdisk /dev/sdc pour creer sdc1 > > Puis pour formater > > # mkfs.ext4 -b 4096 /dev/sdc1 > mke2fs 1.43.4 (31-Jan-2017) > En train de créer un système de fichiers avec 244190390 4k blocs et > 61054976 i-noeuds. > UUID de système de fichiers=efe88182-8ed2-4057-b1db-b2135c0bb300 > Superblocs de secours stockés sur les blocs : > 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, > 4096000, 7962624, 11239424, 2048, 23887872, 71663616, 78675968, > 10240, 214990848 > > Allocation des tables de groupe : complété > Écriture des tables d'i-noeuds : complété > Création du journal (262144 blocs) : complété > Écriture des superblocs et de l'information de comptabilité du système de > fichiers : complété > > > > # fdisk -l > [...] > Disque /dev/sdc : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs > Unités : secteur de 1 × 512 = 512 octets > Taille de secteur (logique / physique) : 512 octets / 4096 octets > taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets > Type d'étiquette de disque : dos > Identifiant de disque : 0x334ead1d > > Périphérique Amorçage DébutFin Secteurs Taille Id Type > /dev/sdc1 2048 1953525167 1953523120 931,5G 83 Linux > > Tout semble ok, sauf la taille du bloc logique comme le signale Hamster: > > Taille de secteur (logique / physique) : 512 octets / 4096 octets > > > > J'ai beau chercher dans les man (mkfs, fdisk) et sur le net, je ne trouve > pas comment faire pour passer la partition logique a 4096 (ou alors je suis > passé à côté car je n'ai pas compris ce que j'ai lu). > > > > Cordialement > > Hugues > > > > > > Le mer. 14 sept. 2022 à 13:40, hamster a écrit : > > Le 14/09/2022 à 12:59, Hugues MORIN-TRENEULE a écrit : > > Disque /dev/sdc : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs > > Unités : secteur de 1 × 512 = 512 octets > > Taille de secteur (logique / physique) : 512 octets / 4096 octets > > taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets > > Je vois l'avant derniere ligne : > "Taille de secteur (logique / physique) : 512 octets / 4096 octets" > Il s'agit d'un disque 4K. Le formatage que tu a fait est fonctionnel > mais pas optimal. Tu aurais interet a faire un formatage 4K pour avoir > sur cette ligne : > "Taille de secteur (logique / physique) : 4096 octets / 4096 octets" > >
Re: Copier 300GB d'un disque dur a un autre
Salut Oui, je l'ai fait un peu à la "va vite" en utilisant l'interface graphique... Je viens de reprendre tout ca proprement D'abord avec un fdisk /dev/sdc pour creer sdc1 Puis pour formater # mkfs.ext4 -b 4096 /dev/sdc1 mke2fs 1.43.4 (31-Jan-2017) En train de créer un système de fichiers avec 244190390 4k blocs et 61054976 i-noeuds. UUID de système de fichiers=efe88182-8ed2-4057-b1db-b2135c0bb300 Superblocs de secours stockés sur les blocs : 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 2048, 23887872, 71663616, 78675968, 10240, 214990848 Allocation des tables de groupe : complété Écriture des tables d'i-noeuds : complété Création du journal (262144 blocs) : complété Écriture des superblocs et de l'information de comptabilité du système de fichiers : complété # fdisk -l [...] Disque /dev/sdc : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 4096 octets taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets Type d'étiquette de disque : dos Identifiant de disque : 0x334ead1d Périphérique Amorçage DébutFin Secteurs Taille Id Type /dev/sdc1 2048 1953525167 1953523120 931,5G 83 Linux Tout semble ok, sauf la taille du bloc logique comme le signale Hamster: Taille de secteur (logique / physique) : 512 octets / 4096 octets J'ai beau chercher dans les man (mkfs, fdisk) et sur le net, je ne trouve pas comment faire pour passer la partition logique a 4096 (ou alors je suis passé à côté car je n'ai pas compris ce que j'ai lu). Cordialement Hugues Le mer. 14 sept. 2022 à 13:40, hamster a écrit : > Le 14/09/2022 à 12:59, Hugues MORIN-TRENEULE a écrit : > > Disque /dev/sdc : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs > > Unités : secteur de 1 × 512 = 512 octets > > Taille de secteur (logique / physique) : 512 octets / 4096 octets > > taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets > > Je vois l'avant derniere ligne : > "Taille de secteur (logique / physique) : 512 octets / 4096 octets" > Il s'agit d'un disque 4K. Le formatage que tu a fait est fonctionnel > mais pas optimal. Tu aurais interet a faire un formatage 4K pour avoir > sur cette ligne : > "Taille de secteur (logique / physique) : 4096 octets / 4096 octets" > >
Re: Copier 300GB d'un disque dur a un autre
Salut Oui ça doit être ça, merci Cela peut il poser un problème de ne pas créer sdc1? Cordialement Hugues Le mer. 14 sept. 2022 à 13:15, Jérémy Prego a écrit : > bonjour, > > Peut être parce que tu as créé directement le système de fichier sur sdc ? > et pas sur sdc1 ? > > Si sdc1 n'existe pas, il faut le créer avec fdisk ou gparted, et ajouter > une nouvelle partition ... > > pour créer ton système de fichier, quel commande as tu effectué ? > > mkfs.ext4 /dev/sdc ou mkfs.ext4 /dev/sdc1 ? > > Jerem > Le 14/09/2022 à 12:59, Hugues MORIN-TRENEULE a écrit : > > Bonjour > > Ca y est le nouveau disque est installé et formaté en ext4 > > Par contre un truc me parait bizarre, fdisk -l ne me fait pas > apparaître la partition sdc1 a l'instar des autres disques. > Est ce normal? > > # smartctl -H /dev/sdcsmartctl 6.6 2016-05-31 r4324 > [x86_64-linux-4.9.0-19-amd64] (local build) > Copyright (C) 2002-16, Bruce Allen, Christian Franke, > www.smartmontools.org > > === START OF READ SMART DATA SECTION === > SMART overall-health self-assessment test result: PASSED > > # fdisk -l > Disque /dev/sdb : 298,1 GiB, 320072933376 octets, 625142448 secteurs > Unités : secteur de 1 × 512 = 512 octets > Taille de secteur (logique / physique) : 512 octets / 512 octets > taille d'E/S (minimale / optimale) : 512 octets / 512 octets > Type d'étiquette de disque : dos > Identifiant de disque : 0xd28ed28e > > Périphérique Amorçage Début Fin Secteurs Taille Id Type > /dev/sdb1* 2048 625139711 625137664 298,1G 7 HPFS/NTFS/exFAT > > > Disque /dev/sda : 298,1 GiB, 320072933376 octets, 625142448 secteurs > Unités : secteur de 1 × 512 = 512 octets > Taille de secteur (logique / physique) : 512 octets / 512 octets > taille d'E/S (minimale / optimale) : 512 octets / 512 octets > Type d'étiquette de disque : dos > Identifiant de disque : 0x883a2be2 > > Périphérique Amorçage Début Fin Secteurs Taille Id Type > /dev/sda1* 2048 3905535 3903488 1,9G 83 Linux > /dev/sda2 3907582 173826047 16991846681G 5 Étendue > /dev/sda3 173826048 330076159 156250112 74,5G 83 Linux > /dev/sda5 3907584 5859327 1951744 953M 83 Linux > /dev/sda6 5861376 13672447 7811072 3,7G 82 partition > d'échang > /dev/sda7 13674496 17577983 3903488 1,9G 83 Linux > /dev/sda8 17580032 76171263 5859123228G 83 Linux > /dev/sda9 76173312 115232767 39059456 18,6G 83 Linux > /dev/sda10115234816 173826047 5859123228G 83 Linux > > Les entrées de la table de partitions ne sont pas dans l'ordre du disque. > > > Disque /dev/sdc : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs > Unités : secteur de 1 × 512 = 512 octets > Taille de secteur (logique / physique) : 512 octets / 4096 octets > taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets > > > Cordialement > Hugues > > Le mar. 13 sept. 2022 à 19:59, Hugues MORIN-TRENEULE a > écrit : > >> Salut >> >> J'irai pas m'embêter à remplacer la carte contrôleur, ça vaut pas le coup >> au vue du prix du disque (50 euro) et du risque. >> A l'occasion, je ferai 2 ou 3 tests pour voir s' il repart sinon >> sûrement poubelle. >> Ça sera l'occasion d'apprendre 2 ou 3 trucs de plus sur les HD même si >> j'arrive pas le reparer ;-) >> >> Merci Error404 pour l'idée de remplacer le câble SATA. >> C'est tout bête mais on passe facilement à côté de ce genre de truc... >> qui peut être la cause de GROOO PROBLÈMES =) >> >> Bonne soiree >> Hugues >> >> Le mar. 13 sept. 2022 à 12:53, hamster a écrit : >> >>> Le 13/09/2022 à 11:24, Hugues MORIN-TRENEULE a écrit : >>> > J'ai lancé badblock durant la nuit, au matin il m'avait listé la quasi >>> > totalité des blocs comme défectueux !!??? O_o >>> > Le resultat etait un truc du style (9954621654/0/0) >>> > J'ai essayé de réparer ce matin, sans succès :( >>> > >>> > Certes ce disque était un peu vieux mais il n'avait jamais ete utilisé. >>> > Je pense que les essais de copie successif l'on peut être endommagé. >>> > Ce n'est peut être que des dommages logiques qui peuvent se réparer >>> avec >>> > un formatage bas niveau. >>> >>> Si badblocks te sort des erreurs, c'est pas un problème logiciel. C'est >>> bien que ce disque est mort. >>> >>> Vu qu'il te sort tous les blocs defectueux sur un disque neuf, il se >>> peut que le problème soit ailleurs que sur le plateau du disque, par >>> exemple le controleur du disque qui est mort, par exemple parce qu'il >>> s'est pris une décharge d'électricité statique. >>> >>> A la rigueur tu peux essayer de remplacer la carte electronique du >>> disque si t'arrive a en trouver une vraiment identique. >>> >>> > Dans le doute, et pour ne pas prendre de risque, je viens de racheter >>> un >>> > HDD neuf pour le remplacer. >>> >>> Sage décision. >>> >>> >
Re: Copier 300GB d'un disque dur a un autre
Bonjour Ca y est le nouveau disque est installé et formaté en ext4 Par contre un truc me parait bizarre, fdisk -l ne me fait pas apparaître la partition sdc1 a l'instar des autres disques. Est ce normal? # smartctl -H /dev/sdcsmartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.9.0-19-amd64] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED # fdisk -l Disque /dev/sdb : 298,1 GiB, 320072933376 octets, 625142448 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 512 octets taille d'E/S (minimale / optimale) : 512 octets / 512 octets Type d'étiquette de disque : dos Identifiant de disque : 0xd28ed28e Périphérique Amorçage Début Fin Secteurs Taille Id Type /dev/sdb1* 2048 625139711 625137664 298,1G 7 HPFS/NTFS/exFAT Disque /dev/sda : 298,1 GiB, 320072933376 octets, 625142448 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 512 octets taille d'E/S (minimale / optimale) : 512 octets / 512 octets Type d'étiquette de disque : dos Identifiant de disque : 0x883a2be2 Périphérique Amorçage Début Fin Secteurs Taille Id Type /dev/sda1* 2048 3905535 3903488 1,9G 83 Linux /dev/sda2 3907582 173826047 16991846681G 5 Étendue /dev/sda3 173826048 330076159 156250112 74,5G 83 Linux /dev/sda5 3907584 5859327 1951744 953M 83 Linux /dev/sda6 5861376 13672447 7811072 3,7G 82 partition d'échang /dev/sda7 13674496 17577983 3903488 1,9G 83 Linux /dev/sda8 17580032 76171263 5859123228G 83 Linux /dev/sda9 76173312 115232767 39059456 18,6G 83 Linux /dev/sda10115234816 173826047 5859123228G 83 Linux Les entrées de la table de partitions ne sont pas dans l'ordre du disque. Disque /dev/sdc : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 4096 octets taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets Cordialement Hugues Le mar. 13 sept. 2022 à 19:59, Hugues MORIN-TRENEULE a écrit : > Salut > > J'irai pas m'embêter à remplacer la carte contrôleur, ça vaut pas le coup > au vue du prix du disque (50 euro) et du risque. > A l'occasion, je ferai 2 ou 3 tests pour voir s' il repart sinon > sûrement poubelle. > Ça sera l'occasion d'apprendre 2 ou 3 trucs de plus sur les HD même si > j'arrive pas le reparer ;-) > > Merci Error404 pour l'idée de remplacer le câble SATA. > C'est tout bête mais on passe facilement à côté de ce genre de truc... qui > peut être la cause de GROOO PROBLÈMES =) > > Bonne soiree > Hugues > > Le mar. 13 sept. 2022 à 12:53, hamster a écrit : > >> Le 13/09/2022 à 11:24, Hugues MORIN-TRENEULE a écrit : >> > J'ai lancé badblock durant la nuit, au matin il m'avait listé la quasi >> > totalité des blocs comme défectueux !!??? O_o >> > Le resultat etait un truc du style (9954621654/0/0) >> > J'ai essayé de réparer ce matin, sans succès :( >> > >> > Certes ce disque était un peu vieux mais il n'avait jamais ete utilisé. >> > Je pense que les essais de copie successif l'on peut être endommagé. >> > Ce n'est peut être que des dommages logiques qui peuvent se réparer >> avec >> > un formatage bas niveau. >> >> Si badblocks te sort des erreurs, c'est pas un problème logiciel. C'est >> bien que ce disque est mort. >> >> Vu qu'il te sort tous les blocs defectueux sur un disque neuf, il se >> peut que le problème soit ailleurs que sur le plateau du disque, par >> exemple le controleur du disque qui est mort, par exemple parce qu'il >> s'est pris une décharge d'électricité statique. >> >> A la rigueur tu peux essayer de remplacer la carte electronique du >> disque si t'arrive a en trouver une vraiment identique. >> >> > Dans le doute, et pour ne pas prendre de risque, je viens de racheter >> un >> > HDD neuf pour le remplacer. >> >> Sage décision. >> >>
Re: Copier 300GB d'un disque dur a un autre
Salut J'irai pas m'embêter à remplacer la carte contrôleur, ça vaut pas le coup au vue du prix du disque (50 euro) et du risque. A l'occasion, je ferai 2 ou 3 tests pour voir s' il repart sinon sûrement poubelle. Ça sera l'occasion d'apprendre 2 ou 3 trucs de plus sur les HD même si j'arrive pas le reparer ;-) Merci Error404 pour l'idée de remplacer le câble SATA. C'est tout bête mais on passe facilement à côté de ce genre de truc... qui peut être la cause de GROOO PROBLÈMES =) Bonne soiree Hugues Le mar. 13 sept. 2022 à 12:53, hamster a écrit : > Le 13/09/2022 à 11:24, Hugues MORIN-TRENEULE a écrit : > > J'ai lancé badblock durant la nuit, au matin il m'avait listé la quasi > > totalité des blocs comme défectueux !!??? O_o > > Le resultat etait un truc du style (9954621654/0/0) > > J'ai essayé de réparer ce matin, sans succès :( > > > > Certes ce disque était un peu vieux mais il n'avait jamais ete utilisé. > > Je pense que les essais de copie successif l'on peut être endommagé. > > Ce n'est peut être que des dommages logiques qui peuvent se réparer avec > > un formatage bas niveau. > > Si badblocks te sort des erreurs, c'est pas un problème logiciel. C'est > bien que ce disque est mort. > > Vu qu'il te sort tous les blocs defectueux sur un disque neuf, il se > peut que le problème soit ailleurs que sur le plateau du disque, par > exemple le controleur du disque qui est mort, par exemple parce qu'il > s'est pris une décharge d'électricité statique. > > A la rigueur tu peux essayer de remplacer la carte electronique du > disque si t'arrive a en trouver une vraiment identique. > > > Dans le doute, et pour ne pas prendre de risque, je viens de racheter un > > HDD neuf pour le remplacer. > > Sage décision. > >
Re: Copier 300GB d'un disque dur a un autre
Bonsoir Merci hamster. J'ai lancé un smartctl long, je pensais que ça prendrait quelques heures mais ca c'est fini rapidement. Je vais arrêter les tests sur ce disque et me concentrer sur l'autre. Concernant le disque de destination, ça a l'air d'être la catastrophe. J'ai viré la partition NTFS, refait une partition ext4 et reformaté. J'ai refait un smartctl long => Échec ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 184 End-to-End_Error0x0032 098 098 099Old_age Always FAILING_NOW 2 J'ai lancé badblock durant la nuit, au matin il m'avait listé la quasi totalité des blocs comme défectueux !!??? O_o Le resultat etait un truc du style (9954621654/0/0) J'ai essayé de réparer ce matin, sans succès :( Certes ce disque était un peu vieux mais il n'avait jamais ete utilisé. Je pense que les essais de copie successif l'on peut être endommagé. Ce n'est peut être que des dommages logiques qui peuvent se réparer avec un formatage bas niveau. Dans le doute, et pour ne pas prendre de risque, je viens de racheter un HDD neuf pour le remplacer. Je vous tiens au courant dés que je le reçois et que je l'ai remplacé Cordialement Hugues Le lun. 12 sept. 2022 à 20:36, hamster a écrit : > Le 12/09/2022 à 19:53, Hugues MORIN-TRENEULE a écrit : > > A ce stade, il semblerait qu'il y ait un problème sur le disque de > > destination. > > https://www.partitionwizard.com/partitionmanager/end-to-end-error.html > > <https://www.partitionwizard.com/partitionmanager/end-to-end-error.html> > > > > Je vais lancer le test du HD source durant la nuit > > Ca depend de quel test. > > Si c'est interroger smartctl, ok, mais ca ne prend pas toute la nuit. > > Mais si ce disque a des soucis materiels, il faut éviter au maximum de > le faire travailler : il peut rendre l'ame totalement d'un moment a > l'autre. La priorité est donc d'en extraire le maximum de données utiles. > > Si tu parle de le tester plus longuement, c'est que tu crains qu'il ait > des soucis. Fais-en d'abord une copie avec ddrescue. Quand tes données > seront copiées, tu pourra investiguer plus longuement la santé > materielle du disque. Par exemple avec badblocks. Ce genre de test le > fait beaucoup travailler, si il meurt pendant le test au moins t'aura > copié les données avant. > > Par contre pour le disque destination c'est le bon moment de faire un > test approfondi, avant d'y écrire des trucs dessus. > >
Re: Copier 300GB d'un disque dur a un autre
Salut Merci à tous pour vos explications, j'y vois un peu plus clair. @hamster: ce sont des disques SATA branché directement sur la CM de la tour Et pour le cheval tu es vraiment sur ;-) :D :D :D Je vais commencer par vérifier et corriger le HD source et formater la destination en ext4. Ça éliminera déjà un certains nombres de problèmes potentiels. Puis je retenterai une copie avec rsync. Voila déjà ce que donne un test rapide avec smartctl. Le disque source semble ok mais je vais quand même le tester plus longuement: # smartctl -H /dev/sdb smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.9.0-19-amd64] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED Avant reformatage j'ai cette erreur qui apparait sur le disque de destination smartctl -H /dev/sdc smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.9.0-19-amd64] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED Please note the following marginal Attributes: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 184 End-to-End_Error0x0032 098 098 099Old_age Always FAILING_NOW 2 A ce stade, il semblerait qu'il y ait un problème sur le disque de destination. https://www.partitionwizard.com/partitionmanager/end-to-end-error.html Je vais lancer le test du HD source durant la nuit cordialement Hugues
Re: Copier 300GB d'un disque dur a un autre
Salut Merci à tous pour votre aide :) Comme je vous le disais, j'ai essayé plusieurs solutions. cp, rsync et dd ont aussi planté sur la copie NTFS a NTFS. cp est une commande assez banale et quotidienne mais en ce qui concerne rsync et dd, je ne les connais pas bien et j'ai pu faire une erreur de paramétrage en les utilisant. A l'origine, j'avais choisi NTFS afin de garder une certaine "portabilité" entre linux et windows. Aujourd'hui, je n'utilise plus du tout windows, je n'ai même plus de machine démarrant dessus. Donc la solution de copie sous windows sera compliqué à mettre en œuvre, toujours faisable mais compliqué. Cette "portabilité" n'ayant plus d'intérêt pour moi, pensez vous qu'en formatant le disque de destination en ext4 cela fonctionnerait? Et quelle commande me conseillerez vous pour la copie cp, dd ou rsync? Question subsidiaire, je la pose mais j'y crois pas trop, ça serait trop simple ;-) Est ce qu'il existe un moyen de changer le type de partition sans altérer les données, passer de NTFS a ext4? Très cordialement Hugues Le lun. 12 sept. 2022 à 13:27, antoine.valmer a écrit : > > Si tu veux faire une bonne copie de NTFS vers NTFS en gardant bien > > toutes les métadonnées, fais la sous windows et non pas sous linux : > > Sages décision et action. > >
Copier 300GB d'un disque dur a un autre
Bonjour a tous Je viens vers vous car malgré plusieurs essais, je n'arrive pas à copier 300GB de fichier d'un disque dur à un autre. Tous mes essais jusqu'à présent se sont soldés par des erreurs assez graves: impossible de lire le disque de destination, problème de propriétaire ou d'autorisations enfin bon que des trucs super angoissant où l'on se demande si on a pas tout perdu :-( J'ai besoin de copier ces fichiers/dossiers car le HD qui les contient est presque plein (90%). Au niveau technique, la machine est assez ancienne et tourne encore sous Stretch. Le HD source est un SATA de 320GB contenant une partition NTFS (sdb1) et un espace non alloué de 1,4MB (je ne me rappelle plus pourquoi c'est la ca...). Le HD de destination est un SATA de 1TB ne contenant qu'une partition NTFS (sdc1). Les 2 partitions sont montées par fstab, sdb1 en /mnmt/data et sdc1 en /mnt/data2. Ma dernière tentative d'hier avec la commande: cp -R --preserve=all /mnt/data/mondossier /mnt/data2/ c'est soldé par une catastrophe: La copie s'est arrêtée à environ 159GB, Ma console était remplie de message d'erreur du type "problème d'entrée/sortie: impossible de lire le fichier" Sur les 2 HD après un ls -al, on voyait que les droits et les nom de user/group était remplacé par des ? J'ai alors redémarré la machine, celle-ci a bloqué durant le démarrage a cause de sdc1 qui n'était plus montable. J'ai modifié le fstab en commentant le montage sdc1 et la machine a démarré. Les ? ont disparu de la partition sdb1 (HD Source). Concernant sdc1, voici le message d'erreur au montage: # mount -t ntfs /dev/sdc1 /mnt/data2/ $MFTMirr does not match $MFT (record 0). Failed to mount '/dev/sdc1': Erreur d'entrée/sortie NTFS is either inconsistent, or there is a hardware fault, or it's a SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows then reboot into Windows twice. The usage of the /f parameter is very important! If the device is a SoftRAID/FakeRAID then first activate it and mount a different device under the /dev/mapper/ directory, (e.g. /dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation for more details. J'ai pu résoudre ce problème avec ntfsfix Pour diagnostiquer # ntfsfix -n /dev/sdc1 Mounting volume... $MFTMirr does not match $MFT (record 0). FAILED Attempting to correct errors... Processing $MFT and $MFTMirr... Reading $MFT... OK Reading $MFTMirr... OK Comparing $MFTMirr to $MFT... FAILED Correcting differences in $MFTMirr record 0...OK Processing of $MFT and $MFTMirr completed successfully. Setting required flags on partition... OK Going to empty the journal ($LogFile)... OK $MFTMirr does not match $MFT (record 0). Remount failed: Input/output error puis pour réparer # ntfsfix /dev/sdc1 Mounting volume... $MFTMirr does not match $MFT (record 0). FAILED Attempting to correct errors... Processing $MFT and $MFTMirr... Reading $MFT... OK Reading $MFTMirr... OK Comparing $MFTMirr to $MFT... FAILED Correcting differences in $MFTMirr record 0...OK Processing of $MFT and $MFTMirr completed successfully. Setting required flags on partition... OK Going to empty the journal ($LogFile)... OK Checking the alternate boot sector... OK NTFS volume version is 3.1. NTFS partition /dev/sdc1 was processed successfully. Voila pour ma mésaventure d'hier. J'ai eu le même type de problème à chaque fois que j'ai tenté de copier ces fichiers/dossiers. Je me rappelle plus exactement les solutions que j'ai déjà essayées mais j'en ai tenté plusieurs, dd entre autre qui avait buggé aussi Je ne dois pas être le seul a avoir eu ce problème de copie mais mes recherches ne m'ont pas conduit à une solution. Je me tourne donc vers vous pour avoir un peu d'aide car je ne vois pas de solution. Très cordialement Hugues
