# [partitionnement] optimisé

## jp25

Bonsoir,

Je souhaite installer une gentoo. J'ai un disque dur de 40 Go.

J'aimerais patitionner mon disque dur pour que celui ci soit le plus securisé (au niveau des données et des erreurs ).

Que me conseiller vous comme partitionnement poru tirer le mieux partit de mon disque dur et de ma gentoo ?

Pour infos j'ai un ordinateur portable avec 512 Mo de ram. L'usage de ma gentoo sera la bureautique, les jeux (comme half life 2), la programmation en c/c++/java, et eventuellemnt la photo.

Merci pour votre attention

----------

## kaworu

Salut !

Ce sujet à été déjà maintes fois traité !

Search te donne : [partitionnement]

Tu trouvera surement ton bonheur !

^________^

----------

## TGL

Vaste sujet, qui ferait un excellent Troll Officiel (je vais me permettre de le poster dans la boîte à idées s'il n'y est pas déjà).

Perso, là sur mon laptop (40Go aussi), j'ai en gros ça :

 - une petite partoche primaire de rien du tout (genre 100Mo, et encore c'est très large) pour "Freedos". Bah oui, rien à voir avec Linux, mais autant y penser dès le début (genre pour les MàJ de BIOS, etc.) ; 

 - une grosse partoche primaire de 15Go pour la racine (et la suite c'est en étendu) ; 

 - une autre grosse partoche de 15Go pour mon /var ;

 - le reste pour mon /home (sauf un petit Go à la fin qui est mon swap) ;

 - quant à /tmp, c'est un petit tmpfs, donc un truc volatile dans la RAM.

Quelques remarques, vraiment en vrac :

 - j'ai pas fait de /boot séparé, j'ai jamais compris l'intérêt.

 - je suis tout en EXT3 (enfin sauf Freedos en FAT32 évidemment), j'en suis content, mais d'autres seront contents aussi avec autre chose. Ceci dit, quitte à partitionner, autant se demander si ça ne vaut pas la peine d'avoir plusieurs FS différents, selon ce qu'on sait ou croit de leurs points forts respectifs ; genre y'a des gens  qui vont avoir un /var/tmp en Reiser 3 (because ça bourre bien pour les petits fichiers et donc les compilations), et un /home en XFS (because vachement fiable). (Ces exemples sont peut-être bidons hein, j'y connais pas grand chose aux subtilités des différents FS...)

 - la séparation de /var et de la racine me semble assez importante : le /var (enfin surtout /var/tmp), c'est vraiment des données très mouvantes et des écritures très nombreuses (genre pour les compilations, qui ont lieu dans /var/tmp/portage), donc ça ne se mélange pas forcement bien avec le reste qui est plus statique (niveau fragmentation, et risques de corruption).  À noter que, dans la même optique, mon arbre Portage est aussi dans /var au lieu du /usr/portage habituel (j'ai en fait un /var/portage avec dedans "tree" pour l'arbre, "packages" pour les paquets binaires, "distfiles" pour les fichiers sources et "overlays" pour mes différents overlays - mais bon, on s'en fout, je m'écarte du sujet là).

 - le /home séparé, je pense que c'est pas mal non plus : ça faciliterait un éventuel changement de distrib (beurk) ou réinstallation (beurk aussi) si ça s'avérait nécéssaire un jour, ça limite un peu les risques de casse, et ça permet d'utiliser des options de montage dont je n'ai pas besoin sur le reste du système ("user_xattr" en l'occurrence).

 - le système idéalement tuné est probablement très découpé. Mais il ne faut pas perdre de vue l'inconvénient sur un disque qui n'est pas énorme : parfois on n'a plus nulle part la place de faire ce qu'on voudrait (genre riper un gros DVD), alors que si on pouvait additionner les espaces libres des différentes partitions on l'aurait. Il faut donc trouver un juste milieu.

 - je ne sais pas toujours où mettre mes données du style MP3/OGG (qui sont en général sur un DD externe, mais dont j'embarque souvent 1 ou 2 Go sur le laptop). Souvent, ça va dans un /var/musique, mais parfois pour des questions de place (genre besoin de qlqs Go supplémentaires pour compiler OOo, etc.) je les bouge dans un /musique ou un /home/musique, etc. Bref, j'aimerai bien avoir un DD un peu plus gros, avec un partoche supplémentaire d'une 10aine de Go pour ce genre de données (ça rejoint le pb en cas de rip de DVD, ce genre de choses).

 - pour une machine de type serveur, il n'est pas déraisonnable de séparer aussi un /srv ou assimilé. Ou bien alors, si on a ces données dans /var/www et autres, de virer le /var/tmp sur sa propre partoche. Bref, encore une fois, c'est bien de ne pas avoir des données plutôt statiques et précieuses sur la même partoche que le gros bazar très dynamique et peu important.

----------

## _droop_

 *TGL wrote:*   

> 
> 
>  - une grosse partoche primaire de 15Go pour la racine (et la suite c'est en étendu) ; 
> 
>  - une autre grosse partoche de 15Go pour mon /var ;
> ...

 

Bonjour,

Je ne sais pas ce que tu fais avec ta machine, mais mon / est rempli à 2 go (sans /usr/portage monté à part (environ ~1go). et mon /var à moins de 100mo. (note le /home est aussi à part)

Pour une utilisation desktop ça me parraît vraiment beaucoup les 15 gos...

Voilà.

----------

## truc

juste une remarque:

Hormis les considérations sur la sécurité qui m'échapent encore pas mal.. l'intéret d'une partition boot séparée peut-être d'avoir plusieurs OS (comprendre distrib biensûr  :Laughing: ) . Ainsi tu peux démarrer ce que tu veux sans problème, (pourquoi même ne pas faire tourner une autre distrib avec un noyau gentoo  ?  :Wink:  )

----------

## TGL

 *_droop_ wrote:*   

> Pour une utilisation desktop ça me parraît vraiment beaucoup les 15 gos...

 

Oui et non, enfin ça dépend vraiment de l'usage... Perso j'ai un usage qui a pas mal tendance à faire enfler les choses, parceque j'installe pas mal de trucs divers et variés, entre autres... Genre mon /usr, il fait 6Go avec juste des contenus de paquets installés par portage (par de /usr/portage ou de /usr/src), et pourtant presque sans jeux.  À ça s'ajoutent de plus en plus de symboles de débogage parceque je commence à utiliser split-debug, genre déjà 1 ou 2 Go, etc., et bref ma racine fait en ce moment 10 Go (j'ai fait du nettoyage récemment, viré les docs Java et les OpenCliparts, et donc gagné ~1Go). Bon, oui, tout le monde n'en remplira pas autant, mais ça peut venir vite aussi sur la machine d'un joueur par exemple : les trucs du genre UT200x, ça doit bien faire ses 2Go il me semble. 

Quant au /var, pareil, question d'usage : déjà moi je garde beaucoup de paquets binaires (pour tout ce qui est system, bibliothèques, etc., bref tout ce qui aide à s'en tirer quand une grosse bidouille tourne mal). Paf, 1Go. Et puis je conserve mes distfiles tant qu'ils sont susceptibles de servir encore pour des revision-bump ou autres. Paf, 3Go. Et puis j'ai un petit système de chroot pour des tests, qui fait genre 1Go. Plus l'arbre portage (c'est pas lourd mais ça prends de la place because nombreux fichiers), et du bazar varié genre des trucs en attente de gravure, et puis voilà, en ce moment mon /var fait 9Go (ce qui laisse la place nécéssaire pour faire une compilation d'OOo confortable, plus un peu de rab).

Alors maintenant, je dis pas que c'est l'espace nécéssaire pour tout le monde hein, loin de là, et tu as bien fait de le souligner (je voulais en parler dans mes "remarques en vrac", et j'ai zappé). C'est plus le « qu'est-ce qu'on peut laisser ensemble et qu'est-ce qu'il faut séparer » que je voulais aborder, mais après, les chiffres, là ça dépend vraiment trop des besoins de chacun pour pouvoir donner des réponses universelles. J'ai par exemple une autre machine où moins de 500Mo sont installés sur la racine. (Bon ok, c'est pas un desktop non plus...)

----------

## marvin rouge

 *TGL wrote:*   

> les trucs du genre UT200x, ça doit bien faire ses 2Go il me semble. 

 Et t'es optimiste:

```
$  du -sh /opt/ut2004 /opt/nwn

5,4G    /opt/ut2004

4,8G    /opt/nwn

```

----------

## k-root

 *jp25 wrote:*   

> ...pour que celui ci soit le plus securisé (au niveau des données et des erreurs ).

 

C'est plus une question de system de fichier que de partionement...

un /home avec un fs crypté semble ok.. surtout en cas de vol de portable.

Sinon prevoi 20go pour / (openoffice,eclipse,halflif,gimp... +firefox,etc ...)

----------

## TGL

 *truc wrote:*   

> l'intéret d'une partition boot séparée peut-être d'avoir plusieurs OS (comprendre distrib biensûr ) . 

  Bah ouais, mais même là je vois pas trop l'intérêt... Dans un /boot, on a, en gros, Grub (sa conf et les stages), et des noyaux (+initrd et compagnie). Sur mon plus vieux desktop où cohabitent encore une Gentoo et une Slack' antédiluvienne (qui certes ne boote plus bien souvent, mais bref elle tourne encore), j'ai pas de partoche de boot séparée, et j'avais pourtant trouvé ça simple et confortable quand même du temps où j'étais partagé entre les deux. Chaque distrib a ses noyaux dans son /boot à elle, et quand à la conf de grub, bah ça dépend de ce qu'on a fait au grub-install (à l'origine, c'était celle de la partoche Slack qui était utilisée, jusqu'à ce que je switche). Bon bien sûr, si je voulais changer la conf de grub depuis la Slack, faudrait que je monte la partoche Gentoo. Mais c'est pas franchement plus galère que de monter une partoche /boot amha...

Quant au partage de noyau entre distribs, bof, ça change pas grand chose là non plus : t'as forcement de la duplication pour les /lib/modules/ de toute façon, et à part ça c'est pareil (soit tu duplique aussi les bzImages, soit du gère ça dans la config de grub, où rien n'empêche d'avoir deux entrée pour une même image, avec juste des root=... différents). Mais de toute façon, le partage de noyau, bof bof dès qu'on commence à vouloir utiliser aussi des modules externes installés via les gestionnaires de paquets des distribs en question.

 *marvin rouge wrote:*   

>  *TGL wrote:*   les trucs du genre UT200x, ça doit bien faire ses 2Go il me semble.  Et t'es optimiste:
> 
> ```
> $  du -sh /opt/ut2004 /opt/nwn
> 
> ...

  Fichtre, ouf que j'ai pas la carte graphique pour ça, parceque je ne saurais pas où les mettre...  :Smile: 

----------

## KrysNux

 *Quote:*   

> un /home avec un fs crypté semble ok

 

Quel fs permet de crypter les données ?

Quels sont ses perfs ?

----------

## TGL

 *KrysNux wrote:*   

> Quel fs permet de crypter les données ?

 

C'est pas vraiment au niveau FS que ça se passe, mais plutôt juste en dessous. Le mot clef pour tes Google est "dm-crypt" (qui donne aussi des bons résultats via la page Rechercher, en sélectionnant le forum "Documentation, Tips & Tricks" : tu auras direct plusieurs HOWTO intéressants). Sinon, si tu peux le trouver (pote, bibliothèque, etc.), l'article du Linux Magazine n°77 sur le sujet était très bien. 

Ou bien sinon, une autre solution sympa c'est EncFS. Ça c'est un système de fichiers en user-mode, basé sur FUSE. Il est lui plutôt adapté pour se faire juste un dossier de données cryptées par exemple, mais pas pour faire 100% d'une partoche.

Bref, tu as le choix, selon tes objectifs...

----------

## jp25

Merci pour toutes vos reponses.

J'ai des questions qui subsistent :

-Quel taille pour la swap ? Je dirais 512 mais est-ce suffissant pour un portable?

-Quel taille pour /boot ? Je dirais 256 (c'est beaucoup mais on ne sais jamais)

-Quel taille pour /tmp et est ce util d'en faire une ? La je n'ai aucune idée . J'ai regarder sur le web : certains disent que ça sert a rien d'autre que si. En fait j'aimerais la separer pour tester des programme dedants et ainsi reduire les risques . 

Mais sur le web j'ai vu que que la taille des /tmp pouvais varié de 100 Mo a 10 Go d'ou mon etonnement.

-quel taille pour /var, /opt, / ? Je pensais mettre 15 à 20 GO pour le reste (exepté /home). Je pense que faire une partition speciale pour la compilation des paquets serait bien, mais laquelle creer et de quelle taille ? Et t'il utile utile de faire une /var ou une /opt .

-le reste je pense le mettre pour /home 

Quels sont vos avis? Merci pour votre aide .

----------

## xaviermiller

 *TGL wrote:*   

> - j'ai pas fait de /boot séparé, j'ai jamais compris l'intérêt.

 

J'en ai trouvé un : avec GRUB, si tu scratches / (par exemple en reformatant pour désinstaller un système linux), plus moyen de booter vu que GRUB se charge sur /boot (au contraire de LILO qui est tout petit et tient dans le MBR)

----------

## TTK

 *jp25 wrote:*   

> Merci pour toutes vos reponses.
> 
> J'ai des questions qui subsistent :
> 
> -Quel taille pour la swap ? Je dirais 512 mais est-ce suffissant pour un portable?
> ...

 

J'ai 512 de RAM aussi sur mon portable. En utilisation bureautique il ne swappe jamais. Donc pas besoin d'un gros swap.

Si tu veux utiliser l'hibernation (software suspend2) tu auras le choix entre utiliser ton swap pour le dump de l'image mémoire ou un fichier à part. La seconde solution est meilleure à mon sens .. Donc là encore un gros swap ne sert à rien.

Extrait de mon df -h:

 *Quote:*   

> 
> 
> /dev/hda5             9,2G  7,5G  1,3G  86% /
> 
> /dev/hda6             5,6G  3,6G  1,7G  69% /home
> ...

 

J'ai aussi un /boot de 32 megs que je ne monte pas. Sécurité ...

Dans /misc/stock je mets des rip de DVD, des mp3, mes photos. Tout est en ext3, sauf /usr/portage en xfs "optimisé" pour les petits fichiers (bof en fait, j'aurais du mettre ext3 partout). Je suis en peu limite en /, surtout en cas de compilation open office. Mais comme je le mets plus à jour ...

Le /tmp est un tmpfs. Ca marche bien.

Tshaw

----------

## TGL

 *jp25 wrote:*   

> -Quel taille pour la swap ? Je dirais 512 mais est-ce suffissant pour un portable?

 

Amha, c'est bien pour un usage plutôt sérieuse : tu comptes que tes applis (X, Firefox, GNOME/KDE, etc.) peuvent prendre jusqu'à ~500Mo les mauvais jours. Tu ajoutes 100 Mo pour une éventuelle compilation de mise à jour en arrière plan, plus 100 autres pour les caches d'I/O disque dur, et un marge de sécurité, et te voilà à 1Go, soit 512 de RAM et autant de swap. Maintenant, si tu es succeptible de lancer par la dessus un UT2004 sans fermer les applis, et bah tu peux rajouter 500Mo de swap, qui leur donnera la place de dégager tranquillement le temps où tu joues. Donc dans ce cas, plutôt 1Go de swap au total. Bon bien sûr, c'est très large 95% du temps, mais ça vaut le coup à mon avis pour n'être jamais embêté. C'est pas comme si tu étais à quelques centaines de Mo prêts sur l'occupation de ton disque...

 *Quote:*   

> -Quel taille pour /boot ? Je dirais 256 (c'est beaucoup mais on ne sais jamais)

 

Zero Mo pour moi, mais bon, tout le monde ne le vois pas comme ça.

 *Quote:*   

> -Quel taille pour /tmp et est ce util d'en faire une ? La je n'ai aucune idée . J'ai regarder sur le web : certains disent que ça sert a rien d'autre que si. En fait j'aimerais la separer pour tester des programme dedants et ainsi reduire les risques . 

 

Pour moi, une partoche /tmp ne sert à rien. Ça fait complètement double-usage avec /var/tmp de s'en servir pour des données volumineuses, des tests de logiciels, etc. Le bon usage de /tmp, c'est plutôt des fichiers de lock ou des trucs du genre. Ça tiens en quelques Mo lors d'une utilisation normale, et comme c'est des fichiers qui en plus n'ont aucune raison de survivre à un reboot, un tmpfs (en RAM donc) est parfaitement adapté. 

 *Quote:*   

> Je pense que faire une partition speciale pour la compilation des paquets serait bien, mais laquelle creer et de quelle taille ? 

 

Prends garde à ne pas faire 36 partitions non plus : l'espace de compilation de Portage n'est pas le seul avec des données volatiles, des tonnes d'I/O sur des petits fichiers, etc., bref n'est pas le seul qui doive être séparé de la racine. De là, si tu fais une partoche spéciale pour /var/tmp/portage, ça ne t'épargnera pas la peine d'en faire aussi une pour mettre par exemple l'arbre portage (/usr/portage par défaut) ou bien encore son cache (/var/cache/edb). Bref tu auras quand même, a priori, aussi besoin d'un /var séparé. Or c'est pour un usage et des raisons somme toute très similaires, donc à partir de là, pourquoi les séparer ?

Donc moi je suis plutôt pour juste un /var, dans le quel il y aura tout.

Ou bien une autre solution, c'est d'avoir une partoche séparée pour tout ce qui est relatif à portage (arbre des ebuilds, espace de compilation, distfiles, etc.). Tu la montes en /var/portage, et tu adaptes ton make.conf pour pointer les bons répertoire. Du coup, il ne te reste pas forcement grand chose de pourri dans /var, et tu peux envisager de l'avoir directement sur la partoche racine.

Niveau tailles, dur de te répondre dans l'absolu, mais quelques chiffres qui t'aideront à décider suivant le schema que tu retiens :

 - l'arbre portage, tu comptes bien 600Mo

 - les distfiles, tu comptes facile 2 Go (bien sûr en supprimant tout tout le temps, tu peux rester très en deça, mais c'est pas cool pour les mirroirs parceque ça signifie que tu vas régulièrement re-télécharger des fichiers à cause de révisions mineures sur les ebuilds)

 - l'espace de compilation, il doit pouvoir atteindre au moins 4Go si tu veux compiler OpenOffice

 - un kernel linux compilé avec ses sources (habituellement dans /usr/src, mais c'est aussi qqch qu'il est raisonnable de déplacer plutôt sur une partoche faite pour les données volatiles), c'est 400 Mo

- tes éventuelles bidouilles/tests ou autres, bah ça c'est toi qui sait...

 *Quote:*   

>  Et t'il utile utile de faire une /var ou une /opt .

 

 - /var, cf. juste au dessus.

 - /opt, clairement je dis non. C'est vraiment exactement le même type d'usage que /usr, donc il n'y à aucune raison de plus le séparer de la racine.

----------

## TGL

 *XavierMiller wrote:*   

>  *TGL wrote:*   - j'ai pas fait de /boot séparé, j'ai jamais compris l'intérêt. 
> 
> J'en ai trouvé un : avec GRUB, si tu scratches / (par exemple en reformatant pour désinstaller un système linux), plus moyen de booter vu que GRUB se charge sur /boot (au contraire de LILO qui est tout petit et tient dans le MBR)

 

Bah bof bof encore... Je fais quoi avec mon Grub et mon bzImage, tous seuls sur leur /boot ? Je boot ? Et après, ça m'aide pas beaucoup si le reste est corrompu/effacé... Perso, pour un pépin de ce genre, c'est plutôt vers un LiveCD que je me tourne, histoire de pouvoir réparer les dégâts si c'est une erreur, ou commencer un nouvelle installation si c'était ça le but du jeu. Grub est bien puissant comme boot loader, mais ça n'est pas pour autant un système minimaliste de secours.

----------

## ghoti

 *XavierMiller wrote:*   

>  *TGL wrote:*   - j'ai pas fait de /boot séparé, j'ai jamais compris l'intérêt. 
> 
> J'en ai trouvé un : avec GRUB, si tu scratches / (par exemple en reformatant pour désinstaller un système linux), plus moyen de booter vu que GRUB se charge sur /boot (au contraire de LILO qui est tout petit et tient dans le MBR)

 

On peut défendre la théorie inverse :

Aussi bien grub que lilo possèdent une petite partie sur le mbr et une grosse partie en dehors !  :Wink: 

La différence, c'est que pour y accéder, grub utilise le système de fichiers tandis que lilo utilise des adresses absolues qui sont calculées lorsqu'on fait un lilo -v. Ces adresses sont stockées dans le mbr.

Avec lilo, une suppression accidentelle de la partition /boot, ou même simplement un effacement du noyau n'empêche pas celui-ci de booter (à condition de ne pas réutiliser/reformater l'espace). En effet, bien que la partition soit supprimée et qu'on ne puisse plus utiliser le filesystem, le fichier du noyau existe encore bel et bien sur le disque et est donc accessible par ses adresses absolues.

Par contre - et c'est tout aussi troublant - le fait de manipuler des fichiers dans /boot peut avoir pour conséquence de déplacer les stages et le kernel ailleurs sur le disque et cela, de manière invisible pour l'utilisateur. Bien entendu, cela invalide les adresses absolues stockées dans le mbr et lilo plante ...

(Pour cette raison il faut toujours faire un "lilo -v" lorsqu'on touche à /boot pour quelque raison que ce soit et pas uniquement lorsqu'on change de kernel !)

Vu cette sensibilité de /boot avec lilo, cela justifie peut-être de le protéger à tout prix d'une maladresse. 

Une partition séparée qu'on ne monte qu'en cas de nécessité absolue peut aider à cette protection.

Comme il n'y a pas de troll ici, je n'en dirai pas plus...  :Wink: 

----------

## TGL

 *ghoti wrote:*   

> Vu cette sensibilité de /boot avec lilo, cela justifie peut-être de le protéger à tout prix d'une maladresse. 
> 
> Une partition séparée qu'on ne monte qu'en cas de nécessité absolue peut aider à cette protection.

 

Ah... LILO... je l'avais oublié celui là... Quel étourdi...  :Rolling Eyes: 

Bon, bah oui, effectivement, ton explication est aussi pertiente qu'elle est limpide : si on utilise LILO, la partoche /boot devient soudain parfaitement justifiable. À chacun de voir si c'est plutôt un argument pour elle ou contre lui.

----------

## xaviermiller

On dévie du sujet principal, mais si on ne touche pas aux autres partitions, LILO pourra quand même booter celles-là, tandis que Grub se plante aux stage "1.5 & Co". Me trompé-je ?

Mais bon, rien ne vaut deux CD Live, l'un Linux et l'autre MS-DOS (avec entre autres bootpart pour réactiver un MBR Microsoft)  :Wink: 

----------

## nemo13

 *ghoti wrote:*   

> 
> 
> Une partition séparée qu'on ne monte qu'en cas de nécessité absolue peut aider à cette protection.

 

c'est un incrustation ,remontée de post , charcutage des paroles de ghoti  :Laughing: 

mais là je suis sur le cul.

pour X raisons j'ai séparé mon /boot ; donc jusqu'à présent je ne montais /boot

qu'avec le copain bonessian et la copine parcimonie.

Puis entre hier et aujourd'hui j'ai  :

monté /boot pour préparer une modif de noyau

oublié de la démontée

tout à l'heure une maj de GRUB est passée et :

```
........

-rw-r--r--  1 root root   1624 fév  9 22:12 grub.conf.sample

-rw-r--r--  1 root root   7124 fév  9 22:12 iso9660_stage1_5

-rw-r--r--  1 root root   8576 fév  9 22:12 jfs_stage1_5

lrwxrwxrwx  1 root root      9 fév  9 22:12 menu.lst -> grub.conf

-rw-r--r--  1 root root   7284 fév  9 22:12 minix_stage1_5

-rw-r--r--  1 root root   9556 fév  9 22:12 reiserfs_stage1_5

-rw-r--r--  1 root root  33856 fév  9 22:12 splash.xpm.gz

-rw-r--r--  1 root root    512 fév  9 22:12 stage1

-rw-r--r--  1 root root 105544 fév  9 22:12 stage2

-rw-r--r--  1 root root 105544 fév  9 22:12 stage2_eltorito

-rw-r--r--  1 root root 105544 jan 30 23:42 stage2.old

......
```

tout le rép grub s'est mis à jour et mon fichier menu.lst est devenu un lien vers

grub.conf !

La conclusion suivante est-elle valable  ?

 *Quote:*   

> si /boot est sur une partition séparé
> 
> si une maj de grub passe
> 
> si la partition n'est pas montée
> ...

 

cela me tracasse  :Shocked: 

----------

## yoyo

 *nemo13 wrote:*   

> La conclusion suivante est-elle valable  ?
> 
>  *Quote:*   si /boot est sur une partition séparé
> 
> si une maj de grub passe
> ...

 Soit tranquilisé : *Quote:*   

> $ more /usr/portage/sys-boot/grub/grub-0.96-r2.ebuild 
> 
> # Copyright 1999-2006 Gentoo Foundation
> 
> # Distributed under the terms of the GNU General Public License v2
> ...

 Cela est donc fait automatiquement.

Enjoy !

----------

## nemo13

 *yoyo wrote:*   

> 
> 
> inherit mount-boot eutils flag-o-matic toolchain-funcs
> 
> Enjoy !

 

Merci

( en french pour moi : cela dit-il qu'il monte /boot tout seul comme un grand ? )

----------

## boozo

c'est celà car comme tu peux le constater lors d'un reboot de ta babasse, la version affiché de ton grub à bien changée elle aussi   :Wink: 

PS: quoi ? comment çà ? l'uptime ?   :Mr. Green: 

----------

## TGL

 *nemo13 wrote:*   

>  *yoyo wrote:*   inherit mount-boot eutils flag-o-matic toolchain-funcs 
> 
> ( en french pour moi : cela dit-il qu'il monte /boot tout seul comme un grand ? )

 

Ça le dit pas directement, mais oui. Ce que ça dit directement, c'est que ton ebuild utilises les fonctions de /usr/portage/eclass/mount-boot.eclass. Et si tu regardes ce fichiers, tu vois :

 - une longue fonction qui sert à faire un "mount /boot"

 - une fonction mount-boot_pkg_preinst() qui appelle la précédente. Une fois passée dans l'ebuild grâce au  inherit, elle devient pkg_preinst(), c'est à dire une fonction qui est appellée automatiquement juste avant le merge du paquet.

Donc oui, il y a bien un "mount /boot" (si nécéssaire) juste avant que les fichiers du paquet soient installés sur ton système, et donc pas de problème...

----------

## TGL

 *XavierMiller wrote:*   

> On dévie du sujet principal, mais si on ne touche pas aux autres partitions, LILO pourra quand même booter celles-là, tandis que Grub se plante aux stage "1.5 & Co". Me trompé-je ?

 

Tu ne te trompe pas, mais ça n'est pas pour autant un argument pour « /boot séparé + LILO » vs. « /boot à la racine + GRUB ». Dans le second cas, on est exactement autant en sécurité (ou bien on court les même risques, question de point de vue) :

 - soit la partition racine n'est pas corrompue, et GRUB lui aussi peut booter ;

 - soit elle l'est, et là, en GRUB on boot pas du tout, et en LILO on charge un kernel mais on ne va pas plus loin, ce qui ne nous avance pas à grand chose non plus.

 *Quote:*   

> Mais bon, rien ne vaut deux CD Live, l'un Linux et l'autre MS-DOS (avec entre autres bootpart pour réactiver un MBR Microsoft) 

 

Un MBR Microsoft ? Mais beurk, pour quoi faire ???

Enfin bon, oui, LiveCD ++.

----------

## yoyo

Merci pour ces explications TGL.   :Cool: 

Par contre, est-ce que le "umount" est également fait à la fin de l'emerge ?? Je ne crois pas (si mes lointains souvenirs sont bons). Et dans ce cas, sais-tu pourquoi il n'est pas fait ??

----------

## _droop_

 *yoyo wrote:*   

> Merci pour ces explications TGL.  
> 
> Par contre, est-ce que le "umount" est également fait à la fin de l'emerge ?? Je ne crois pas (si mes lointains souvenirs sont bons). Et dans ce cas, sais-tu pourquoi il n'est pas fait ??

 

Il n'y a pas de umount à la fin de l'emerge.

Je suppose que c'est pour laisser la possibilité à la personne de modifier le fichier de configuration qui se trouve sur /boot/...

Voilà.

----------

## TGL

 *yoyo wrote:*   

> Par contre, est-ce que le "umount" est également fait à la fin de l'emerge ?? 

 

Non, je ne vois rien de tel.

 *Quote:*   

> Et dans ce cas, sais-tu pourquoi il n'est pas fait ??

 

Je sais pas trop... J'imagine que le raisonnement est que :

- quand c'est l'ebuild qui doit monter le /boot, il l'indique avec des einfo, donc l'utilisateur est censé savoir que c'est arrivé (et donc c'est pas vraiment un bug de l'ebuild, qu'on soit d'accord ou non avec ce comportement)

 - puisque l'utilisateur est au courant, libre à lui de démonter le truc tout de suite, ou bien d'aller d'abord jeter un oeil à ce qui s'y est passé (comme l'a fait nemo13, comme quoi ça n'est pas si improbable)

Ou bien le mainteneur n'y a simplement pas pensé, ce qui n'est jamais une hypothèse à écarter non plus  :Smile: 

EDIT : grilled...

Et puis oui, _droop_ a raison : autant dans le cas d'un upgrade on n'a pas forcement à aller toucher à ce qui s'est passé dans /boot, autant dans le cas d'une première install' de Grub, on a vraiment l'obligation d'aller le faire, donc ça fait sens de laisser le truc monté.

----------

## yoyo

 *TGL wrote:*   

> Et puis oui, _droop_ a raison : autant dans le cas d'un upgrade on n'a pas forcement à aller toucher à ce qui s'est passé dans /boot, autant dans le cas d'une première install' de Grub, on a vraiment l'obligation d'aller le faire, donc ça fait sens de laisser le truc monté.

 Je ne suis pas trop d'accord avec ce principe. Tout d'abord parce que "/boot" ne fait pas partie du CONFIG_PROTECT, donc le etc-update (ou équivalent) n'informe pas de la mise à jour nécessaire du menu.lst (ou grub.conf) et donc on peut "oublier" de faire cette mise à jour ou encore écraser le contenu de "/boot" en croyant qu'on est dans le répertoire et pas sur le point de montage (c'est tiré par les cheveux je sais   :Rolling Eyes:  ). Et aussi parce que si on est logique et qu'on dit "il faut monter /boot pour y copier le kernel" alors que l'installation/upgrade de grub le monte tout seul il peut y avoir méprise lors d'une upgrade de noyau (déjà que genkernel fait aussi le montage automatiquement) et on se retrouve à copier le nouveau noyau dans le répertoire et plus sur le point de montage (c'est aussi tiré par les cheveux je sais   :Mr. Green:  ).

Enfin perso, je préfèrerai retrouver mon système comme je l'ai laissé avant l'emerge : c'est-à-dire que si "/boot" était monté il reste monté, et sinon que l'ebuild le démonte à la fin de l'emerge (comme de toute façon, il n'apparaît pas dans "etc-update" ...).

[MODE TROLL ON]encore un double-avantage pour lilo : pas de "/boot" monté à la fin de l'emerge et "etc-update" qui avertit d'une mise à jour nécessaire (puisque le lilo.conf est dans le CONFIG_PROTECT).[MODE TROLL OFF]

----------

## TGL

 *yoyo wrote:*   

> Tout d'abord parce que "/boot" ne fait pas partie du CONFIG_PROTECT, donc le etc-update (ou équivalent) n'informe pas de la mise à jour nécessaire du menu.lst (ou grub.conf) et donc on peut "oublier" de faire cette mise à jour

 

Il n'y a pas de mise à jour de grub.conf à faire. L'ebuild n'installe dans /boot que des stages et des fichiers d'exemple, bref rien qui nécéssite une CONFIG_PROTECTion. 

 *Quote:*   

> ou encore écraser le contenu de "/boot" en croyant qu'on est dans le répertoire et pas sur le point de montage (c'est tiré par les cheveux je sais   ).

 

Si les gens comprenaient qu'il ne sert absolument à rien d'avoir un /boot partitionné quand on utilise Grub, ils arrêteraient de se compliquer la vie inutilement et éviteraient ce genre de bêtise tordue.

 *Quote:*   

> encore un double-avantage pour lilo : pas de "/boot" monté à la fin de l'emerge

 

C'est surtout un avantage du /boot non partitionné : pas de prise de tête inutile, pas de mauvaise question.

 *Quote:*   

> et "etc-update" qui avertit d'une mise à jour nécessaire (puisque le lilo.conf est dans le CONFIG_PROTECT).

 

Tu es averti qu'il y a une nouvelle mise à jour à ignorer. Super...

[/TROLL] aussi   :Laughing: 

----------

## Argian

 *TGL wrote:*   

> Si les gens comprenaient qu'il ne sert absolument à rien d'avoir un /boot partitionné quand on utilise Grub, ils arrêteraient de se compliquer la vie inutilement et éviteraient ce genre de bêtise tordue.

 J'arrive peut-être comme un cheveu dans la soupe mais, avec le système sur une partition en raid0 logiciel et formatée reiser4, la partition /boot, j'en vois l'intérêt et pas qu'un peu: sans ça, aucune possibilité de booter avec grub  :Very Happy: .

Cela dit, je ne suis pas le cas général, loin de là, je faisais juste une petite remarque en faveur de la partition boot  :Razz:  Je ne suis pas sûr non plus qu'on puisse booter un système sur une partion formatée reiser(3/4), xfs, jfs,etc sans /boot séparé même si on n'est pas en raid0

Dois-je [/TROLL] ? j'sais pas  :Razz: 

----------

## TGL

 *Argian wrote:*   

> J'arrive peut-être comme un cheveu dans la soupe mais, avec le système sur une partition en raid0 logiciel et formatée reiser4, la partition /boot, j'en vois l'intérêt et pas qu'un peu

 

Ah, bah voilà enfin un vrai argument pour le /boot spéraré avec Grub. Bien vu !  :Smile: 

 *Quote:*   

> Je ne suis pas sûr non plus qu'on puisse booter un système sur une partion formatée reiser(3/4), xfs, jfs,etc sans /boot séparé même si on n'est pas en raid0

 

De ceux que tu cites, seul Reiser4 pose problème à ma connaissance.

 *Quote:*   

> Dois-je [/TROLL] ? j'sais pas 

 

Nan, ça va, t'avais du neuf, et du bon  :Smile: 

----------

## nemo13

 *TGL wrote:*   

> 
> 
> Ah, bah voilà enfin un vrai argument pour le /boot spéraré avec Grub. 

 

Bonsoir,

il y a aussi le cas des fada qui ont plusieurs distrib linux sur la même machine.

c'est la moindre des précautions d'isoler à minima /boot non ?

A+

----------

## TGL

 *nemo13 wrote:*   

> il y a aussi le cas des fada qui ont plusieurs distrib linux sur la même machine.
> 
> c'est la moindre des précautions d'isoler à minima /boot non ?

 

Je pense au contraire que la précaution, c'est d'éviter à tout prix de le partager : chacun son /boot à la racine sur ça propre partoche, et tu évites que le système de paquets d'une distrib n'écrase ce qui avait été installé par celui de l'autre, ou des horreurs du genre. Évidement, de ces différents /boot, un seul est effectivement utilisé par le Grub installé sur ton MBR. Les autres ne servent qu'à stocker les noyaux et initrds de leurs distribs respéctives. Et ta config fait chaque fois référence à une partition différente pour aller chercher le noyau de la distrib' à booter : 

```
title  Gentoo GNU/Linux

root=(hd0,0)

kernel=(hd0,0)/boot/bzImage root=/dev/hda1 ...

initrd=(hd0,0)/boot/fbsplash-1024x768

...

title  Slackware GNU/Linux

root=(hd0,1)

kernel=(hd0,1)/boot/bzImage root=/dev/hda2 ...

...
```

----------

## nemo13

oui, c'est ce que j'ai fait au bout d'un an!

```
gentoobscur nemo13 # cat /boot/grub/menu.lst

#

timeout 30

color black/cyan yellow/cyan

default 0

# la branche instable est multi-partitions sur sdc

title= gentoobscur : noyau 2.6.14-gentoo-r5 gcc 3.4 UTF8 oui

root (hd2,0) # en clair sdc1

kernel /kernel-2.6.14-gentoo-r5 root=/dev/sdc6 video=vesafb:ywrap,mtrr,1024x768-24@85

# la branche stable évolue sur une seule partition : sdb7

title= gentoobiwan noyau 2.6.14-gentoo-r5 gcc 3.4 UTF8 oui

root (hd1,5) # en clair grub ira chercher son noyau sur sdb6

kernel /boot/kernel-2.6.14-gentoo-r5 root=/dev/sdb7 video=vesafb:ywrap,mtrr,1024x768-24@85

# la plus stable mais figée sur une seule partition : sda7

title= Gentoo SOS : noyau 2.6.11-r6 gcc 3.3.5 UTF8 non

root (hd0,6)

kernel /boot/bzImage root=/dev/sda7 video=vesafb:ywrap,mtrr,1024x768-24@85

title= mandrake 10.1

kernel (hd0,5)/boot/vmlinuz-2.6.8.1-10mdksmp root=/dev/sda6 devfs=nomount acpi=ht resume=/dev/sda5 splash=verbose vga=791

initrd (hd0,5)/boot/initrd-2.6.8.1-10mdksmp.img

title windows XP

root (hd0,0)

chainloader +1

```

c'est sur je suis intoxiqué aux disques dur : chacun le sien ou presque

A+

----------

## jp25

Bonjours,

Pour en revenir au sujet initial :

J'ai pensé partitionner mon disque de la maniere suivante :

- 1 GO pour la swap

- 256 M pour /boot

- 7 Go pour /

- 12 GO pour /var

- 19 Go pour  /home

- 1 Go pour une partition teste

Mais j'avoue ne pas être satisfait par mon choix et je ne vois pas trop quoi faire. 

Est ce que 7 Go c'est suffisant pour / ?

Ma partition /home me semble beaucoup trop grosse .

est ce que 12 Go est la bonne taille pour /var si l'on veut compiler des gros paquet et riper des dvd(il me semble que les paquets que je compilerai seront dans /var non )?

Si j'ai des grosses applications je devrai augmenter la place dans / non?

Merci pour vos conseilles

----------

## bibi.skuk

 *jp25 wrote:*   

> - 256 M pour /boot

 

Je sais pas ce que tu veux faire avec 256 Mo de /boot, mais, avec mes 6 kernels, quelques initrd, grub, et autres joyeusetées, ma partition qui fait 60Mo, est a moitié pleine...

----------

## KrysNux

Autre petit point positif d'avoir un /boot séparé.

Voici ma configuration actuelle:

/boot    ext2

/          reiserfs

/home  reiserfs

Et bien voila, alors que je voulais modifier ma partition / en la divisant en 2, voila que qtparted a merdé sévère => / ko

Donc, je suis bon pour réinstaller gentoo.

Mais, voila l'avantage du /boot séparé : je stocke toujours mon .config (configuration du noyau sur la partition).

Au pire, si on inclut le .config dans le noyau, on peut toujours le récupérer.

=> Je dois réinstaller : long mais il suffit juste de suivre le guide.

Mais je n'ai pas à reconfigurer mon noyau.

Voili voilou.

En attendant, je me frappe la tete contre les murs.

D'ailleurs, je me demande si le problème ne venait pas de reiserfs. J'ai très souvent des erreurs lorsque je le check.

Je vais donc en essayer un autre, surement jfs

=> /boot est resté intact.

=> /home aussi

j'aurais tout du moins mes données.

----------

## Argian

 *KrysNux wrote:*   

> Mais, voila l'avantage du /boot séparé : je stocke toujours mon .config (configuration du noyau sur la partition).
> 
> Au pire, si on inclut le .config dans le noyau, on peut toujours le récupérer.
> 
> => Je dois réinstaller : long mais il suffit juste de suivre le guide.
> ...

 Mouais, enfin, si c'est juste pour ça, ton .config, tu peux aussi le copier dans ton /home plutôt que dans /boot, voire sur une disquette, une clé usb, un cdrom ou un timbre poste (Si si, avec un grand timbre poste, ça peut le faire  :Razz: )

Pour en revenir au sujet, 256 Mo pour /boot, ça m'a aussi l'air un peu excessif (En fait TGL m'a convaincu et si je pouvais me passer d'une partion /boot, je le ferais, mais je ne peux pas  :Very Happy: . Mais même dans ce cas, 30-50 Mo, c'est à mon avis largement suffisant). Sinon, pour le reste, je serais plutôt de l'avis de TGL (Encore lui!) dans son premier post.

----------

## jp25

c'est pas un peu enorme 15 Go pour / alors qu'il y a deja 15 Go pour /var?

Parce que dans cette configuration il ne me reste que 9 Go pour /home .

----------

## KrysNux

Concernant ma partition boot.

j'avais prévu  100Mo et je suis très loin de les utiliser.

50 Mo devraient suffir largement.

Voir meme 30

----------

