{"partition": "head_middle", "source_domain": "forum.ubuntu-fr.org", "digest": "sha1:TANEQEMIMCCVISWK2UREUXQJBAFZK4BF", "path": "/lustre/fsn1/projects/rech/qgz/uzq54wg/processed_redpajama/base_processing/output/fr/2014-15/000_00012.parquet"}
» Messages recherchés
» De men-go
nombre réponses : 25
Re :	-1	» [résolu] Suppression d'une partition - dual boot à disparu	» Le 02/04/2014, à 11:24
men-go Réponses :	6
Bonjour, En ce qui te concerne c'est trop tard, mais pour ceux qui vont lire cette discussion, je voudrais conseiller qu'avant tout "tripotage" des partitions, sauvegarder le MBR (Master Boot Record) qui dans une table de partitions MSDOS contient la définition de chaque partition, par la commande:sudo dd if=/dev/sda of=nom_de_fichier bs=512 count=1/dev/sda est le disque habituel, mais la procédure fonctionne avec une autre unité. nom_de_fichier peut être quelconque mais évidemment le placer sur une unité externe.Pour restaurer:sudo dd if=nom_de_fichier of=/dev/sda bs=512 count=1Ceci t'aurait permis de retrouver les partitions et y accéder au moins par un live Ubuntu.
Aller à la discussion
Aller au message
Bonjour, Je n'ai jamais eu l'occasion d'utiliser PartedMagic donc je ne sais sais pas ce qu'il vaut. Par contre il existe dans Ubuntu une application: TestDisk qui est capable de récupérer des partitions. TestDisk est aussi capable de recopier des répertoires et/ou des fichiers. Le paquet qui installe cette application contient aussi Photorec. Ceci étant, si TeskDisk récupère tes partitions, tu n'auras besoin de rien d'autre. Si tu ne disposes pas encore d'un vrai système Ubuntu (pas un live), ça peut facilement s'installer sur une clé USB de 8Go. Après installation d'un Ubuntu, installer le paquet "testdisk". Pour le lancer, soumettre dans Terminal la commande: sudo testdisk. Pour tester TestDisk, j'ai remis à zéro le MBR c'est à dire entre autres la table des partitions d'une clé USB contenant 4 partitions primaires: UBUNTU, Linux swap, DATA et home . Il a réussi à retrouver la structure des partitions mais il s'est un peu mélangé les pinceaux, puisque la dernière partition a été considérée comme logique. J'ai pu remettre en place la vraie structure et aussi sauvegarder la totalité de ce contient cette partition càd home (il faut jouer avec les flèches de direction).
Re :	-1	» SSHD (hybride), partitionnement et points de montage	» Le 08/04/2014, à 15:06
Bonjour, N'ayant jamais utilisé un SSHD (je n'en vois pour l'instant pas grand intérêt, ayant lu qu'il ne fallait pas écrire trop souvent sur ce type d'unité) je répondrais sur le montage des différents répertoires systèmes. Le contenu des répertoires dont tu parles peut être copié soit dans des partitions (avec les disques formatés avec une GPT il n'y a pas de problème au niveau du nombre de partitions. Même avec une table MSDOS on peut avoir autant de partitions logiques que l'on désire) soit dans des fichiers préparés pour cela. A titre d'exemple, j'utilise moi-même un petit fichier d'une centaine de Mo que je monte sur /usr/local, ceci pour éviter de contaminer le système d'origine. Linux (ou Unix) donne effectivement à l'utilisateur le choix de dispatcher ou non les différents répertoires systèmes. Il faut juste faire la part des choses entre la performance et la complexité de l'architecture qu'on va mettre en place. Pour la performance, il vaudrait mieux que les répertoires soient dispatchés sur différents disques (et non des partitions). Pour l'architecture, que se passera-t-il s'il faut de temps en temps réinstaller le système ? ou lors des incidents, ne vaut-il pas mieux pour le diagnostic avoir une architecture plus monolithique ? Personnellement je ne dispatche que /home et crée une partition DATA accessible à tous les utilisateurs et tous les systèmes. Les définitions de ces ensembles sont dans /etc/fstab. Pour répondre plus précisément à tes questions, tu peux créer une partition pour chaque répertoire système, y recopier les éléments de chacun (ou les mouvementer) et faire les définitions dans /etc/fstab. Les points de montages sont les mêmes, par exemple si tu veux dispatcher /usr, sachant qu'il faut manipuler soit sur un autre système soit sur un live Ubuntu (ci-dessous, remplacer $USER par l'utilisateur courant et "sys_ubuntu" par le label ou l'uuid adéquat):- Création d'une partition ext4 avec Gparted dont le nom aura pour label ou étiquette par exemple: USR- Monter (si ce n'est déjà fait) avec Nautilus le système à recopier ainsi que la nouvelle partition- Copie de /usr par: sudo cp -a /media/$USER/sys_ubuntu/usr /media/$USER/USR- Modifier /media/$USER/sys_ubuntu/etc/fstab avec par exemple: # USRLABEL=USR /usr ext4 rw,nosuid,nodev,uhelper=hal 0 0 A noter que lorsqu'on monte un système de fichier sur un point de montage quel qu'il soit, le contenu d'origine du répertoire du point de montage est inaccessible pendant la durée du montage.
Bonjour Bruno, Comme je me suis plus focalisé sur le système Ubuntu lui-même, j'avoue qu'au niveau matériel je ne suis la technologie que de loin en loin. C'est pourquoi après avoir bien lu, effectivement, ma remarque est en partie erronée. Concernant les performances des disques, déjà le système Linux maintient un cache en mémoire centrale (voir la commande free). Il suffit pour s'en rendre compte de lancer LibreOffice puis de l'arrêter et de le relancer. On se rend compte que la relance est beaucoup plus rapide que le lancement initial. Je regrette par contre qu'on ne puisse pas agir sur le contenu de ce cache au moment du boot, c'est à dire que l'utilisateur pourrait mettre en cache via un fichier de paramètres les applications qu'il utilise le plus souvent ce qui ferait que même le premier accès serait performant (il existe bien des fonctions C pour gérer le cache système, évidemment inaccessibles à l'utilisateur lambda). Mais il est vrai qu'un cache au niveau du sous-système disque pourrait aussi améliorer les performances et le mieux serait que le cache soit au niveau de contrôleur. Ça existe sur les mainframes mais je ne sais pas si sur les petits systèmes ça existe aussi. L'avantage serait que le contrôleur réponde directement en cas de "hit cache" et qu'il suffirait d'utiliser des disques "normaux" donc moins onéreux. Ceci étant pour les mainframes qui gèrent parfois des dizaines de milliers d'utilisateurs, la milliseconde est très importante puisque les entrées/sorties se comptent aussi parfois en milliers par seconde. En ce