[Megoldva] RAID osszrakasa root mount elott/utan

Linux-kezdő

Udv.

Nos, most nem birok rajonni.
Az a problemam, hogy szoftveres raid-emet kiegeszitettem egy masik tombbel is, RAID1-et hasznalok.
Amin fennakadtam, hogy van olyan tomb, amit a root fs mountolasa elott rak ossze, es van, amit utana.
Ez azert zavar, mert a root-ot is tombbe akarom szervezni, es kinos lenne, ha azt nem rakna ossze rootmount elott.

Szoval: mitol fugg, hogy melyik tombot rakja ossze rootmount elott, es melyiket joval kesobb?

A grub menu.lst-ben nem talaltam semmi erre utalot,
az fstabban 0 0 -ra vegzodik mindket tomb sora,
a /etc/mdadm/mdadm.conf-ban sem lattam semmit, ami miatt ebben kulonboznenek.

Hol kell ravenni, hogy MINDEN tombot a rootmount elott rakjon ossze?
Vagy ha nem is mindet, de egy ADOTT tombot mindenkepp?

  • 940 megtekintés

( Proci85 v | 2009. 12. 29., k – 12:37 )

Elég csak a root tömbbel foglalkozni. Raid autodetectre kell állítani azokat a partíciókat cfdisk/fdisk programmal.
A kernel raid támogatással még init előtt összerakja neked.
A többit ráér az mdadm. Ott már nem muszáj raid autodetectnek lennie.

Nos, itt pont forditva van...

Ami eloszor keszult, meg regebben, az nem raid autodetect - megis osszerakja.

Amit most csinaltam, az raid autodetect - megis csak a boot folyamat egy kesobbi reszen rakja ossze.

Valami masnak kell itt lennie, de nem jovok ra.

Probaltam a grubban editalva a kernelnek parameterkent megadni az md=4,/dev/sda5,/dev/sdb5 parametert, de akkor sem rakta ossze.

Az eredeti, regebbi tomb most fellabu, de nem ez a lenyeg. Alabb a dmesg idevonatkozo resze (sdb8 a jelenlegi root): 


  Vendor: ATA       Model: SAMSUNG HM500LI   Rev: 2TF0
  Type:   Direct-Access                      ANSI SCSI revision: 05
  Vendor: ATA       Model: SAMSUNG HM500JI   Rev: 2AC1
  Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sda: 976773168 512-byte hdwr sectors (500108 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 976773168 512-byte hdwr sectors (500108 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
 sda: sda1 < sda5 sda6 sda7 sda8 sda9 >
sd 0:0:0:0: Attached scsi disk sda
SCSI device sdb: 976773168 512-byte hdwr sectors (500108 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 976773168 512-byte hdwr sectors (500108 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
 sdb: sdb1 < sdb5 sdb6 sdb7 sdb8 sdb9 >
sd 1:0:0:0: Attached scsi disk sdb
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
md: raid1 personality registered for level 1
md: md0 stopped.
md: bind<sda9>
raid1: raid set md0 active with 1 out of 2 mirrors
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
udevd version 125 started
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected an Intel 865 Chipset.
agpgart: Detected 8060K stolen memory.
agpgart: AGP aperture is 128M @ 0xf0000000
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
input: PC Speaker as /class/input/input1
intel_rng: FWH not detected
Real Time Clock Driver v1.12ac
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA]
parport0: Printer, Hewlett-Packard hp LaserJet 3030
ACPI: PCI Interrupt 0000:00:1f.5[B] -> GSI 17 (level, low) -> IRQ 209
PCI: Setting latency timer of device 0000:00:1f.5 to 64
intel8x0_measure_ac97_clock: measured 54017 usecs
intel8x0: clocking to 48000
EXT3 FS on sdb8, internal journal
Probing IDE interface ide0...
Netfilter messages via NETLINK v0.30.
ip_conntrack version 2.4 (4031 buckets, 32248 max) - 224 bytes per conntrack
ip_conntrack_pptp version 3.1 loaded
ip_nat_pptp version 3.0 loaded
device-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialised: dm-devel@redhat.com
md: md1 stopped.
md: bind<sdb5>
md: bind<sda5>
raid1: raid set md1 active with 2 out of 2 mirrors
fuse init (API version 7.7)

( apal v | 2009. 12. 29., k – 15:14 )

Szoval: mitol fugg, hogy melyik tombot rakja ossze rootmount elott, es melyiket joval kesobb?
Ha a root fs raid(1)-en van, akkor erdemes megadni az 


md=0,/dev/sda1,/dev/sdb1

kernelopciot is a grub-ba, es akkor garantaltan mukodik, kernel is tudja mi a dorges, stb. pl deb alatt egy grub bejegyzes az igy nez ki: 


linux   /boot/vmlinuz-2.6.26-2-amd64 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1

szoval volt hogy a deb addig nem volt hajlando feljonni, amig ez az opcio nem volt (de tokugyanaz a deb verzio, masik vason, hasonlo install-parameterek mellett meg feljott... ez nekem is misztikus volt, de a lenyeg, hogy a fenti opcio megnyugatja, es lenyegeben az altalad adott kerdesre is megadja a valaszt).

persze minden particiot (akar utolag is) 0xfd-re at ko"ll tenni, illetve fontos dolog, hogy a raid maga az ne raw legyen, hanem szuperblokkolt. a kernel/md ugyanis onnan szedi a raid felepitesehez szukseges metaadatokat es/vagy a raid aktuallis allapotat. raw raid-del dolgozni szopo, remeljuk nem ez a helyzet nalad...:]

Szoval: mitol fugg, hogy melyik tombot rakja ossze rootmount elott, es melyiket joval kesobb?
Ha a root fs raid(1)-en van, akkor erdemes megadni az

md=0,/dev/sda1,/dev/sdb1

Irtam, hogy probaltam a boot elott a grub menujeben editalva a sort megadni, de nem volt hatasa.

persze minden particiot (akar utolag is) 0xfd-re at ko"ll tenni,

Amint irtam, pont a nem igy megadotttat huzza jelenleg fel rootmount elott, mig a 0xfd-set meg nem, pedig nagyon szeretnem...

illetve fontos dolog, hogy a raid maga az ne raw legyen, hanem szuperblokkolt. a kernel/md ugyanis onnan szedi a raid felepitesehez szukseges metaadatokat es/vagy a raid aktuallis allapotat. raw raid-del dolgozni szopo, remeljuk nem ez a helyzet nalad...:]

Eztetet meg hogy is tudom kideriteni?

Ugy csinaltam azt a tombot, amit nem huz fel, csak az init soran, hogy
- cfdisk-el mindket disken letrehoztam az egyforma meretu particiot
- cfdisk-el mindket particiot beallitottam 0xfd -re
- megcsinaltam a tombot
- mkfs.ext3 /dev/mdN

Ebbol kiderul-e (azon kivul, hogy nyilvan sokan sokkal jobban es maskepp csinaltak volna), hogy szuperblockos vagy raw?

( egymonk | 2009. 12. 29., k – 18:48 )

Ja igen, az eredeti kérdésedre válaszolva:
A kernel először a ramdiszket (initrd) húzza be amiről lefutnak a setup scriptek, töltődnek a modulok, majd belövi a root fs-t végül chrootol rá.
Következésképpen, ha a ramdiszkeden nincsen jól belőve a mdadm.conf akkor nem fogja a összerakni a chroot előtt. Ha debian alapú rendszered van akkor az update-initramfs -u parancs a barátod, ami felpakolja az általad módosított mdadm.confot az initrd fájlba.