Je projette de monter un système multiboot Linux/FreeBSD/Windows et je
cherche à connaître les pièges à éviter notamment concernant le
partitionnement et l'ordre d'installation de ces systèmes.
Pour être plus précis, je dispose d'un disque d'une capacité de 1 To sur
lequel j'aimerai installer les OS suivants :
- Linux (Slackware64)
- FreeBSD (10.0)
- Windows XP (32 bits)
- Windows 7 (64 bits)
Les deux Windows seront des installations minimales pour test et ne sont
pas destinés a grossir démesurément voire disparaîtront.
J'ai prévu de découper le disque de cette manière :
- 400 Go pour Linux
- 500 Go pour FreeBSD
- 50 Go pour XP
- 50 Go pour W7
Ceci dit le système de partitionnement de freeBSD (que je connais à
peine) me laisse perplexe et quelques conseils pour partitionner
efficacement le disque dur dans son ensemble ne sont pas de refus.
Mieux vaut-il partitionner l'ensemble avec FreeBSD ?
GPT ou pas GPT ?
Par ailleurs, vaut il mieux installer les Windows en premier (ce que
j'aurais tendance à faire) ?
Si le disque est partitionné avec FreeBSD, Windows ne va t-il pas
paniquer ?
Bref, toutes ces questions que le noob que je suis cherche à
résoudre. Le but de l'opération étant de se préparer à une future
migration en douceur vers freeBSD.
Merci de vos conseils.
XP fr.comp.os.bsd + FU2 fr.comp.os.linux.configuration
--
Nous voilà de nouveau branchés sur le hasard
Avec des générateurs diesel à la place du c½ur
Et des pompes refoulantes au niveau des idées...
-- H.F. Thiéfaine, Autorisation de délirer
Ceci dit, pour anticiper un peu la future disparition du Linux, j'aimerai avoir quelques pistes me permettant d'ajouter de l'espace à un volume. Typiquement, comment faire pour que l'espace utilisé aujourd'hui par Linux (500 Go) soit rapidement et de manière la plus transparente possible ajouté au FS de freeBSD (qui devrait être ZFS) ?
En ZFS suffit de l'ajouter au pool. Par le passé j'ai pas mal utiliser gconcat(8), qui permet de fusioner des devices en un seul. Par contre c'est pas transparent, il faut sauvegarder les données, concatener les devices puis newfs et restaurer. Ça marche bien ceci dit.
Pour ZFS faut quand même de la RAM et une machine costaud àma.
Doug713705 :
Ceci dit, pour anticiper un peu la future disparition du Linux,
j'aimerai avoir quelques pistes me permettant d'ajouter de l'espace à un
volume. Typiquement, comment faire pour que l'espace utilisé aujourd'hui
par Linux (500 Go) soit rapidement et de manière la plus transparente
possible ajouté au FS de freeBSD (qui devrait être ZFS) ?
En ZFS suffit de l'ajouter au pool.
Par le passé j'ai pas mal utiliser gconcat(8), qui permet de fusioner
des devices en un seul. Par contre c'est pas transparent, il faut
sauvegarder les données, concatener les devices puis newfs et
restaurer. Ça marche bien ceci dit.
Pour ZFS faut quand même de la RAM et une machine costaud àma.
Ceci dit, pour anticiper un peu la future disparition du Linux, j'aimerai avoir quelques pistes me permettant d'ajouter de l'espace à un volume. Typiquement, comment faire pour que l'espace utilisé aujourd'hui par Linux (500 Go) soit rapidement et de manière la plus transparente possible ajouté au FS de freeBSD (qui devrait être ZFS) ?
En ZFS suffit de l'ajouter au pool. Par le passé j'ai pas mal utiliser gconcat(8), qui permet de fusioner des devices en un seul. Par contre c'est pas transparent, il faut sauvegarder les données, concatener les devices puis newfs et restaurer. Ça marche bien ceci dit.
Pour ZFS faut quand même de la RAM et une machine costaud àma.
Bruno Ducrot
On 2014-06-16, Patrick Lamaizière wrote:
Par le passé j'ai pas mal utiliser gconcat(8), qui permet de fusioner des devices en un seul. Par contre c'est pas transparent, il faut sauvegarder les données, concatener les devices puis newfs et restaurer. Ça marche bien ceci dit.
À priori, un growfs(8) devrait pouvoir éviter la phase restauration.
-- Bruno Ducrot
A quoi ca sert que Ducrot hisse des carcasses ?
On 2014-06-16, Patrick Lamaizière wrote:
Par le passé j'ai pas mal utiliser gconcat(8), qui permet de fusioner
des devices en un seul. Par contre c'est pas transparent, il faut
sauvegarder les données, concatener les devices puis newfs et
restaurer. Ça marche bien ceci dit.
À priori, un growfs(8) devrait pouvoir éviter la phase
restauration.
Par le passé j'ai pas mal utiliser gconcat(8), qui permet de fusioner des devices en un seul. Par contre c'est pas transparent, il faut sauvegarder les données, concatener les devices puis newfs et restaurer. Ça marche bien ceci dit.
À priori, un growfs(8) devrait pouvoir éviter la phase restauration.
-- Bruno Ducrot
A quoi ca sert que Ducrot hisse des carcasses ?
Bruno Ducrot
On 2014-06-16, Antoine Leca wrote:
didier gaumet écrivit :
je me demande si l'organisation des 'BSD sur un disque traditionnel MBR (des slices (partitions MBR) dans lesquels sont incluses des partitions logicielles 'BSD) est encore en usage avec un disque GPT?
Réponse à ta question : non.
On peut, mais ce n'est pas du tout conseillé.
-- Bruno Ducrot
A quoi ca sert que Ducrot hisse des carcasses ?
On 2014-06-16, Antoine Leca wrote:
didier gaumet écrivit :
je me demande si l'organisation des 'BSD sur un disque traditionnel MBR
(des slices (partitions MBR) dans lesquels sont incluses des partitions
logicielles 'BSD) est encore en usage avec un disque GPT?
je me demande si l'organisation des 'BSD sur un disque traditionnel MBR (des slices (partitions MBR) dans lesquels sont incluses des partitions logicielles 'BSD) est encore en usage avec un disque GPT?
Réponse à ta question : non.
On peut, mais ce n'est pas du tout conseillé.
-- Bruno Ducrot
A quoi ca sert que Ducrot hisse des carcasses ?
Bruno Ducrot
On 2014-06-16, Bruno Ducrot wrote:
On 2014-06-16, Patrick Lamaizière wrote:
Par le passé j'ai pas mal utiliser gconcat(8), qui permet de fusioner des devices en un seul. Par contre c'est pas transparent, il faut sauvegarder les données, concatener les devices puis newfs et restaurer. Ça marche bien ceci dit.
À priori, un growfs(8) devrait pouvoir éviter la phase restauration.
Ca marche :
# dd if=/dev/zero of=/tmp/dd2 bs24 count000 3000+0 records in 3000+0 records out 3072000 bytes transferred in 0.037584 secs (81736765 bytes/sec) # dd if=/dev/zero of=/tmp/dd2 bs24 count000 3000+0 records in 3000+0 records out 3072000 bytes transferred in 0.037584 secs (81736765 bytes/sec) # mdconfig -a -t vnode /tmp/dd1 md0 # mdconfig -a -t vnode /tmp/dd2 md1 # newfs /dev/md0 newfs /dev/md0 /dev/md0: 2.9MB (6000 sectors) block size 32768, fragment size 4096 using 3 cylinder groups of 1.00MB, 32 blks, 128 inodes. super-block backups (for fsck_ffs -b #) at: 192, 2240, 4288 # gconcat create test /dev/md0 /dev/md1 # mount /dev/concat/test /mnt # growfs /dev/concat/test Device is mounted read-write; resizing will result in temporary write suspension for /mnt. It's strongly recommended to make a backup before growing the file system. OK to grow filesystem on /dev/concat/test, mounted on /mnt, from 3MB to 5.9MB? [Yes/No] Yes super-block backups (for fsck -b #) at: 6336, 8384, 10432
Ceci dit, growfs permet le resize sur un FS monté à partir de FreeBSD 10.0.
-- Bruno Ducrot
A quoi ca sert que Ducrot hisse des carcasses ?
On 2014-06-16, Bruno Ducrot wrote:
On 2014-06-16, Patrick Lamaizière wrote:
Par le passé j'ai pas mal utiliser gconcat(8), qui permet de fusioner
des devices en un seul. Par contre c'est pas transparent, il faut
sauvegarder les données, concatener les devices puis newfs et
restaurer. Ça marche bien ceci dit.
À priori, un growfs(8) devrait pouvoir éviter la phase
restauration.
Ca marche :
# dd if=/dev/zero of=/tmp/dd2 bs24 count000
3000+0 records in
3000+0 records out
3072000 bytes transferred in 0.037584 secs (81736765 bytes/sec)
# dd if=/dev/zero of=/tmp/dd2 bs24 count000
3000+0 records in
3000+0 records out
3072000 bytes transferred in 0.037584 secs (81736765 bytes/sec)
# mdconfig -a -t vnode /tmp/dd1
md0
# mdconfig -a -t vnode /tmp/dd2
md1
# newfs /dev/md0
newfs /dev/md0
/dev/md0: 2.9MB (6000 sectors) block size 32768, fragment size 4096
using 3 cylinder groups of 1.00MB, 32 blks, 128 inodes.
super-block backups (for fsck_ffs -b #) at:
192, 2240, 4288
# gconcat create test /dev/md0 /dev/md1
# mount /dev/concat/test /mnt
# growfs /dev/concat/test
Device is mounted read-write; resizing will result in temporary write suspension for /mnt.
It's strongly recommended to make a backup before growing the file system.
OK to grow filesystem on /dev/concat/test, mounted on /mnt, from 3MB to 5.9MB? [Yes/No] Yes
super-block backups (for fsck -b #) at:
6336, 8384, 10432
Ceci dit, growfs permet le resize sur un FS monté à partir de FreeBSD
10.0.
Par le passé j'ai pas mal utiliser gconcat(8), qui permet de fusioner des devices en un seul. Par contre c'est pas transparent, il faut sauvegarder les données, concatener les devices puis newfs et restaurer. Ça marche bien ceci dit.
À priori, un growfs(8) devrait pouvoir éviter la phase restauration.
Ca marche :
# dd if=/dev/zero of=/tmp/dd2 bs24 count000 3000+0 records in 3000+0 records out 3072000 bytes transferred in 0.037584 secs (81736765 bytes/sec) # dd if=/dev/zero of=/tmp/dd2 bs24 count000 3000+0 records in 3000+0 records out 3072000 bytes transferred in 0.037584 secs (81736765 bytes/sec) # mdconfig -a -t vnode /tmp/dd1 md0 # mdconfig -a -t vnode /tmp/dd2 md1 # newfs /dev/md0 newfs /dev/md0 /dev/md0: 2.9MB (6000 sectors) block size 32768, fragment size 4096 using 3 cylinder groups of 1.00MB, 32 blks, 128 inodes. super-block backups (for fsck_ffs -b #) at: 192, 2240, 4288 # gconcat create test /dev/md0 /dev/md1 # mount /dev/concat/test /mnt # growfs /dev/concat/test Device is mounted read-write; resizing will result in temporary write suspension for /mnt. It's strongly recommended to make a backup before growing the file system. OK to grow filesystem on /dev/concat/test, mounted on /mnt, from 3MB to 5.9MB? [Yes/No] Yes super-block backups (for fsck -b #) at: 6336, 8384, 10432
Ceci dit, growfs permet le resize sur un FS monté à partir de FreeBSD 10.0.
-- Bruno Ducrot
A quoi ca sert que Ducrot hisse des carcasses ?
Bruno Ducrot
On 2014-06-16, Doug713705 wrote:
Le 16-06-2014, Bruno Ducrot nous expliquait dans fr.comp.os.bsd () :
Pour l'heure je viens de terminer la migration de mon système linux actuel depuis mon ancien disque sur le nouveau et il me reste freeBSD a installer sur les 500Go que j'ai laissé libres et non partitionnnés pour ce faire.
Est-ce un disque GPT, ou pas ? Il est probablement plus simple de faire cohabiter Linux et FreeBSD si l'on s'en tient au classique MBR.
J'ai en effet partitionné en MBR, au moins, ça, je connais ;-)
Personnellement, j'installe Linux en premier avec grub2, mais par contre j'installe grub2 non pas sur /dev/sda, mais sur /dev/sda1, qui correspond à une (petite) partition /boot sous Linux.
Puis j'installe FreeBSD avec son boot loader. Mais cette méthode marche surtout lorsque l'on se cantonne à un root UFS classique. Je n'ai pas encore testé comme il faut ZFS root dans cette configuration.
J'ai installé lilo sur le MBR mais même s'il venait a être écrasé par mégarde je saurai le restaurer sans aucun problème.
Ceci dit, à moins que ce soit un mauvais choix, je projetais d'utiliser le bootloader de freeBSD.
Pour le MBR, le boot loader de FreeBSD se contente de te donner le choix de la partition "active" via les touches Fn. Si Lilo n'est pas installé sur ta partition de /boot (linux), le bootloader MBR de FreeBSD ne pourra pas t'aider.
A la limite, tu peux garder lilo sur le MBR, mais il te faut lui faire reconnaître ton FreeBSD. C'est assez simple, et un peu de Google me donne un truc de ce genre :
other=/dev/hda4 table=/dev/hda label=FreeBSD
Par contre, le hda4 montre clairement que c'est un vieux truc, hein..
Ensuite, pour installer le boot loader de FreeBSD sur le MBR, c'est :
# gpart bootcode -b /boot/boot0 ada0
Le prochain épisode le week-end prochain.
Ceci dit, pour anticiper un peu la future disparition du Linux, j'aimerai avoir quelques pistes me permettant d'ajouter de l'espace à un volume. Typiquement, comment faire pour que l'espace utilisé aujourd'hui par Linux (500 Go) soit rapidement et de manière la plus transparente possible ajouté au FS de freeBSD (qui devrait être ZFS) ?
En tout les cas, si tu veux du ZFS root, tu vas devoir installer à la main. Il y a bien la possibilité d'installer en ZFS root à partir de FreeBSD 10.0, mais celà implique que tout OS déjà présent sera effacé.
Y compris les systèmes installés sur les partitions non concernées par l'installation ? WTF ?
C'est assez rustique. A vrai dire, je ne l'ai utilisé qu'une fois, et le résultat ne m'a pas plus. Il y a pas mal de manières de définir les FS ZFS et l'installateur ne donne aucun choix.
Y'ai découpé mon disque comme suit : - sda1 /boot linux - sda2 /boot BSD
^^^^^^^^^^
Aie... Il aurait fallu que quelqu'un te prévienne que /boot est dans la racine, un peu comme /etc.
- sda3 swap (en espérant le partager entre les deux OS, pas grave si pas possible) - sda5 / linux - sda6 /home linux - sda7 /data linux
Restent en queue de disque un espace de 500 Go *non partitionné* (je prévoyais de le faire pendant l'installation de freeBSD) dans lequel j'espérai y mettre freeBSD en ZFS.
Avec MBR, tu n'a pas le choix. Il faut une partition primaire (que l'on nomme 'slice' dans le jargon) dans laquelle on peut définir jusqu'à 8 partitions (au sens FreeBSD).
Bon, ceci dit, rien n'empêche de mettre un 'root' sur une partition d'un slice primaire, et le reste dans une partition secondaire. Je l'ai déjà fait il y a pas mal de temps.
Si tu as un truc pour virtualiser sous ton Linux, je te conseille fortement de t'entraîner avant.
Ça c'est fait, justement, je veux passer à la grandeur nature.
Par contre je n'ai pas essayé de virtualiser un double boot Linux/freeBSD. Ce n'est pas bête.
Lorsque je me sens maso, je fait des tests UEFI, pour Debian et FreeBSD dans une machine virtuelle via qemu. Pour l'instant, j'arrive à pas grand chose. J'ai quelques résultats avec GPT et grub2, mais bon. Ce n'est pas ce que je veux.
Une simple ligne de commande : # zpool add <pool> /dev/<nouveau_device>
Ah, ça c'est bien o/
Normalement, celà devrait rajouter ton << nouveau_device >> en mode stripping, si je me souviens bien. Je ferai quand même quelques tests pour être certain que c'est du stripping, et non du mirroring, et je te répondrai cette semaine.
Merci.
C'est bien du stripping.
A plus,
-- Bruno Ducrot
A quoi ca sert que Ducrot hisse des carcasses ?
On 2014-06-16, Doug713705 wrote:
Le 16-06-2014, Bruno Ducrot nous expliquait dans
fr.comp.os.bsd
(<slrnlpthmu.2jtb.ducrot@poup.poupinou.org>) :
Pour l'heure je viens de terminer la migration de mon système linux
actuel depuis mon ancien disque sur le nouveau et il me reste freeBSD a
installer sur les 500Go que j'ai laissé libres et non partitionnnés pour
ce faire.
Est-ce un disque GPT, ou pas ? Il est probablement plus simple de faire
cohabiter Linux et FreeBSD si l'on s'en tient au classique MBR.
J'ai en effet partitionné en MBR, au moins, ça, je connais ;-)
Personnellement, j'installe Linux en premier avec grub2, mais par contre
j'installe grub2 non pas sur /dev/sda, mais sur /dev/sda1,
qui correspond à une (petite) partition /boot sous Linux.
Puis j'installe FreeBSD avec son boot loader. Mais cette méthode marche
surtout lorsque l'on se cantonne à un root UFS classique. Je n'ai pas
encore testé comme il faut ZFS root dans cette configuration.
J'ai installé lilo sur le MBR mais même s'il venait a être écrasé par
mégarde je saurai le restaurer sans aucun problème.
Ceci dit, à moins que ce soit un mauvais choix, je projetais d'utiliser
le bootloader de freeBSD.
Pour le MBR, le boot loader de FreeBSD se contente de te donner le choix
de la partition "active" via les touches Fn.
Si Lilo n'est pas installé sur ta partition de /boot (linux), le
bootloader MBR de FreeBSD ne pourra pas t'aider.
A la limite, tu peux garder lilo sur le MBR, mais il te faut
lui faire reconnaître ton FreeBSD. C'est assez simple, et
un peu de Google me donne un truc de ce genre :
other=/dev/hda4
table=/dev/hda
label=FreeBSD
Par contre, le hda4 montre clairement que c'est un vieux truc, hein..
Ensuite, pour installer le boot loader de FreeBSD sur le MBR, c'est :
# gpart bootcode -b /boot/boot0 ada0
Le prochain épisode le week-end prochain.
Ceci dit, pour anticiper un peu la future disparition du Linux,
j'aimerai avoir quelques pistes me permettant d'ajouter de l'espace à un
volume. Typiquement, comment faire pour que l'espace utilisé aujourd'hui
par Linux (500 Go) soit rapidement et de manière la plus transparente
possible ajouté au FS de freeBSD (qui devrait être ZFS) ?
En tout les cas, si tu veux du ZFS root, tu vas devoir installer
à la main. Il y a bien la possibilité d'installer en ZFS root à partir
de FreeBSD 10.0, mais celà implique que tout OS déjà présent sera
effacé.
Y compris les systèmes installés sur les partitions non concernées par
l'installation ? WTF ?
C'est assez rustique. A vrai dire, je ne l'ai utilisé qu'une fois, et
le résultat ne m'a pas plus. Il y a pas mal de manières de définir les
FS ZFS et l'installateur ne donne aucun choix.
Y'ai découpé mon disque comme suit :
- sda1 /boot linux
- sda2 /boot BSD
^^^^^^^^^^
Aie... Il aurait fallu que quelqu'un te prévienne que /boot est
dans la racine, un peu comme /etc.
- sda3 swap (en espérant le partager entre les deux OS, pas grave si
pas possible)
- sda5 / linux
- sda6 /home linux
- sda7 /data linux
Restent en queue de disque un espace de 500 Go *non partitionné* (je
prévoyais de le faire pendant l'installation de freeBSD) dans
lequel j'espérai y mettre freeBSD en ZFS.
Avec MBR, tu n'a pas le choix. Il faut une partition primaire (que
l'on nomme 'slice' dans le jargon) dans laquelle on peut définir
jusqu'à 8 partitions (au sens FreeBSD).
Bon, ceci dit, rien n'empêche de mettre un 'root' sur une partition
d'un slice primaire, et le reste dans une partition secondaire. Je
l'ai déjà fait il y a pas mal de temps.
Si tu as un truc pour virtualiser sous ton Linux, je te
conseille fortement de t'entraîner avant.
Ça c'est fait, justement, je veux passer à la grandeur nature.
Par contre je n'ai pas essayé de virtualiser un double boot
Linux/freeBSD. Ce n'est pas bête.
Lorsque je me sens maso, je fait des tests UEFI, pour Debian et
FreeBSD dans une machine virtuelle via qemu. Pour l'instant,
j'arrive à pas grand chose. J'ai quelques résultats avec GPT
et grub2, mais bon. Ce n'est pas ce que je veux.
Une simple ligne de commande :
# zpool add <pool> /dev/<nouveau_device>
Ah, ça c'est bien o/
Normalement, celà devrait rajouter ton << nouveau_device >> en mode
stripping, si je me souviens bien. Je ferai quand même quelques
tests pour être certain que c'est du stripping, et non du
mirroring, et je te répondrai cette semaine.
Le 16-06-2014, Bruno Ducrot nous expliquait dans fr.comp.os.bsd () :
Pour l'heure je viens de terminer la migration de mon système linux actuel depuis mon ancien disque sur le nouveau et il me reste freeBSD a installer sur les 500Go que j'ai laissé libres et non partitionnnés pour ce faire.
Est-ce un disque GPT, ou pas ? Il est probablement plus simple de faire cohabiter Linux et FreeBSD si l'on s'en tient au classique MBR.
J'ai en effet partitionné en MBR, au moins, ça, je connais ;-)
Personnellement, j'installe Linux en premier avec grub2, mais par contre j'installe grub2 non pas sur /dev/sda, mais sur /dev/sda1, qui correspond à une (petite) partition /boot sous Linux.
Puis j'installe FreeBSD avec son boot loader. Mais cette méthode marche surtout lorsque l'on se cantonne à un root UFS classique. Je n'ai pas encore testé comme il faut ZFS root dans cette configuration.
J'ai installé lilo sur le MBR mais même s'il venait a être écrasé par mégarde je saurai le restaurer sans aucun problème.
Ceci dit, à moins que ce soit un mauvais choix, je projetais d'utiliser le bootloader de freeBSD.
Pour le MBR, le boot loader de FreeBSD se contente de te donner le choix de la partition "active" via les touches Fn. Si Lilo n'est pas installé sur ta partition de /boot (linux), le bootloader MBR de FreeBSD ne pourra pas t'aider.
A la limite, tu peux garder lilo sur le MBR, mais il te faut lui faire reconnaître ton FreeBSD. C'est assez simple, et un peu de Google me donne un truc de ce genre :
other=/dev/hda4 table=/dev/hda label=FreeBSD
Par contre, le hda4 montre clairement que c'est un vieux truc, hein..
Ensuite, pour installer le boot loader de FreeBSD sur le MBR, c'est :
# gpart bootcode -b /boot/boot0 ada0
Le prochain épisode le week-end prochain.
Ceci dit, pour anticiper un peu la future disparition du Linux, j'aimerai avoir quelques pistes me permettant d'ajouter de l'espace à un volume. Typiquement, comment faire pour que l'espace utilisé aujourd'hui par Linux (500 Go) soit rapidement et de manière la plus transparente possible ajouté au FS de freeBSD (qui devrait être ZFS) ?
En tout les cas, si tu veux du ZFS root, tu vas devoir installer à la main. Il y a bien la possibilité d'installer en ZFS root à partir de FreeBSD 10.0, mais celà implique que tout OS déjà présent sera effacé.
Y compris les systèmes installés sur les partitions non concernées par l'installation ? WTF ?
C'est assez rustique. A vrai dire, je ne l'ai utilisé qu'une fois, et le résultat ne m'a pas plus. Il y a pas mal de manières de définir les FS ZFS et l'installateur ne donne aucun choix.
Y'ai découpé mon disque comme suit : - sda1 /boot linux - sda2 /boot BSD
^^^^^^^^^^
Aie... Il aurait fallu que quelqu'un te prévienne que /boot est dans la racine, un peu comme /etc.
- sda3 swap (en espérant le partager entre les deux OS, pas grave si pas possible) - sda5 / linux - sda6 /home linux - sda7 /data linux
Restent en queue de disque un espace de 500 Go *non partitionné* (je prévoyais de le faire pendant l'installation de freeBSD) dans lequel j'espérai y mettre freeBSD en ZFS.
Avec MBR, tu n'a pas le choix. Il faut une partition primaire (que l'on nomme 'slice' dans le jargon) dans laquelle on peut définir jusqu'à 8 partitions (au sens FreeBSD).
Bon, ceci dit, rien n'empêche de mettre un 'root' sur une partition d'un slice primaire, et le reste dans une partition secondaire. Je l'ai déjà fait il y a pas mal de temps.
Si tu as un truc pour virtualiser sous ton Linux, je te conseille fortement de t'entraîner avant.
Ça c'est fait, justement, je veux passer à la grandeur nature.
Par contre je n'ai pas essayé de virtualiser un double boot Linux/freeBSD. Ce n'est pas bête.
Lorsque je me sens maso, je fait des tests UEFI, pour Debian et FreeBSD dans une machine virtuelle via qemu. Pour l'instant, j'arrive à pas grand chose. J'ai quelques résultats avec GPT et grub2, mais bon. Ce n'est pas ce que je veux.
Une simple ligne de commande : # zpool add <pool> /dev/<nouveau_device>
Ah, ça c'est bien o/
Normalement, celà devrait rajouter ton << nouveau_device >> en mode stripping, si je me souviens bien. Je ferai quand même quelques tests pour être certain que c'est du stripping, et non du mirroring, et je te répondrai cette semaine.
Merci.
C'est bien du stripping.
A plus,
-- Bruno Ducrot
A quoi ca sert que Ducrot hisse des carcasses ?
Patrick Lamaizière
Bruno Ducrot :
Ceci dit, growfs permet le resize sur un FS monté à partir de FreeBSD 10.0.
Autant dire que je ferais quand même une sauvegarde :-)
Bruno Ducrot :
Ceci dit, growfs permet le resize sur un FS monté à partir de FreeBSD
10.0.
Autant dire que je ferais quand même une sauvegarde :-)
Ceci dit, growfs permet le resize sur un FS monté à partir de FreeBSD 10.0.
Autant dire que je ferais quand même une sauvegarde :-)
De toute façon il faut *toujours* faire une sauvegarde.
-- Les simplifications c'est trop compliqué
Bruno Ducrot
On 2014-06-17, Patrick Lamaizière wrote:
Bruno Ducrot :
Ceci dit, growfs permet le resize sur un FS monté à partir de FreeBSD 10.0.
Autant dire que je ferais quand même une sauvegarde :-)
C'est pourquoi j'ai écrit que l'on pouvait éviter la phase restauration, ce qui suppose que l'on a déjà fait une sauvegarde. Je n'ai peut-être pas été assez clair, et te remercie pour la précision.
-- Bruno Ducrot
A quoi ca sert que Ducrot hisse des carcasses ?
On 2014-06-17, Patrick Lamaizière wrote:
Bruno Ducrot :
Ceci dit, growfs permet le resize sur un FS monté à partir de FreeBSD
10.0.
Autant dire que je ferais quand même une sauvegarde :-)
C'est pourquoi j'ai écrit que l'on pouvait éviter
la phase restauration, ce qui suppose que l'on a déjà
fait une sauvegarde. Je n'ai peut-être pas été assez
clair, et te remercie pour la précision.
Ceci dit, growfs permet le resize sur un FS monté à partir de FreeBSD 10.0.
Autant dire que je ferais quand même une sauvegarde :-)
C'est pourquoi j'ai écrit que l'on pouvait éviter la phase restauration, ce qui suppose que l'on a déjà fait une sauvegarde. Je n'ai peut-être pas été assez clair, et te remercie pour la précision.
