Raid array borte etter oppgradering til Ubuntu Jaunty

[MirusMentis]

Hadde 3 arrays på filserveren min.

 

md0 - raid0, 2 stk 80gb disker, boot

md1 - raid0, samme disker som over bare andre partisjoner. swap.

md2 - raid5, 4stk 500gb disker, datalagring

 

I går kjørte jeg "do-release-upgrade" alt gikk kjapt og greit, ingen feil.

Så etter en reboot, så var md2 borte.

 

Etter en "mdadm -A -S" så fant den et et nytt array den forsøkte å bygge opp, men klarte vist bare å finne 2 disker. Så da fikk jeg plutselig et nytt array "md_d2"

Dette fikk jeg stoppet ved hjelp av "mdadm --manage --stop /dev/md_d2"

 

Bygde så opp det gamle arrayet, men fikk da beskjed om at den ene disken innehold ext3 filsystem og kunne ikke brukes. satt den som missing og fortsatte.

mdadm --create /dev/md2 --level=5 --chunk=128 --raid-devices=4 missing /dev/sdd1 /dev/sde1 /dev/sdf1

Da fikk jeg bygget arrayet, men all data er borte. Får hvertfall ikke mountet det. Da den ikke kjenner igjen filsystemet.

 

Heldigvis hadde j eg backup av det meste, men utrolig surt.

 

Er det virkelig slik at man må regne med at sånt skjer ved en oppdatering? Det er jo i såfall helt sinnsykt. Føler jeg mistet en god del tillit til linux nå, har vært mye krøll ved oppsettet av denne serveren, men jeg mener jeg virkelig har gitt det en sjanse og gått inn for å få det til å virke.

 

Vel, noen som har meninger til hvorfor dette skjedde, og evt tips til gjenskaping av data?

[jonnor]

Med den nevnte kommando har du sannsynligvis bygget opp et nytt array over det gamle. Og det har du jo ikke opprettet et filsystem på, så det er ikke rart du ikke får mountet.

For å bygge et eksisterende array brukes

mdadm --assemble --scan

(-A -s, alså liten s). Fungerer ikke det, sjekk konfig filen til mdadm. Sjekk at alle diskene er tilgjengelige. Du kan også spesifisere enhetene som skal inkluderes spesifikt.

 

Merk at du har ingen garanti for at enhetsnavn er konstante etter en reboot, og ihvertfall ikke etter en systemoppdatering, bare så det er sagt.

Endret 23. mai 2009 av jonnor

[MirusMentis]

mdadm -A -S var det jeg gjorde. Da laget den et nytt array "md_d2" men klarte ikke bygge det da den bare fant 2 av 4 disker ?

 

enhetsnavnene endret seg, det fant jeg ut etter hvert..

 

mdadm.conf var det noe rart med for den inneholdt kun de to raid0 arrayene, ikke raid5.

 

Uansett har vel insett at data er tapt og at jeg må bygge arrayet på nytt (resyncer as we speak) for å lage filsystemet på nytt så gjør jeg hva?

[Varj]

du surrer med flere raids, og vet ikke hvordan du lager et filsystem?

 

mkfs

 

 

litt offtopic, men interessant:

det er ikke vits å lage raid0 for swap, hvis du legger til begge partisjonene som swap vil linux kjernen automatisk stripe data mellom de, uten bruk av software raid.

[A!1]

Uansett har vel insett at data er tapt og at jeg må bygge arrayet på nytt (resyncer as we speak) for å lage filsystemet på nytt så gjør jeg hva?

 

Dataene hadde ikke vært tapt, hvis du ikke hadde foretatt deg noe... Jeg har hatt mye feil på raid5 oppsettet mitt i det siste... jeg fikk blandt annet bad sectors på to av diskene samtidig. Det skal i utgangspunktet være vanskelig å komme seg fra uten å miste mye data. Jeg kom meg fra det med å miste kun 15 mb data.

 

Du kan sjekke diskene dine for bad blocks med kommandoen badblocks /dev/sd## (der du bytter ut sd## med navnet på partisjonen din). Grunnen til å sjekke partisjon og ikke disk er at du evt kan benytte output fra badblocks til å fikse filsystemet etterpå.

 

Når du vet om du har badblocks eller ikke, kan du opprette arrayet på nytt igjen, med kommandoen:

 

mdadm --create /dev/md2 --assume-clean --level=5 --raid-devices=4 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1

 

Der du bytter ut sdc1, md2 osv med det som passer i forhold til ditt system.

 

Det som er viktig å passe på er at chunksize er det samme som opprinnelig og at du bruker samme paritetsalgoritme. Standard er 64KB og left-symmetric. Det er også viktig at paritsjonen kommer i samme rekkefølge som de opprinnelig gjorde. Det kan du finne ut med mdadm --examine /dev/sdc1 som du må kjøre på alle diskene. Se etter linjen

this 1 8 33 1 active sync /dev/sdc1

Hvor det er det tallet som står i kursiv du skal se på. Den første partisjonen har tallet 0, den andre har 1 osv...

 

Hvis du gjenoppretter arrayet nøyaktig som før vil du ikke miste noe data. Selv om du skulle opprette arrayet feil, er det bare å stoppe arrayet og prøve på nytt, så lenge du ikke har skrevet data til partisjonene etter at feilen oppsto, er du trygg.

[MirusMentis]

Uansett har vel insett at data er tapt og at jeg må bygge arrayet på nytt (resyncer as we speak) for å lage filsystemet på nytt så gjør jeg hva?

 

Dataene hadde ikke vært tapt, hvis du ikke hadde foretatt deg noe... Jeg har hatt mye feil på raid5 oppsettet mitt i det siste... jeg fikk blandt annet bad sectors på to av diskene samtidig. Det skal i utgangspunktet være vanskelig å komme seg fra uten å miste mye data. Jeg kom meg fra det med å miste kun 15 mb data.

 

Du kan sjekke diskene dine for bad blocks med kommandoen badblocks /dev/sd## (der du bytter ut sd## med navnet på partisjonen din). Grunnen til å sjekke partisjon og ikke disk er at du evt kan benytte output fra badblocks til å fikse filsystemet etterpå.

 

Når du vet om du har badblocks eller ikke, kan du opprette arrayet på nytt igjen, med kommandoen:

 

mdadm --create /dev/md2 --assume-clean --level=5 --raid-devices=4 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1

 

Der du bytter ut sdc1, md2 osv med det som passer i forhold til ditt system.

 

Det som er viktig å passe på er at chunksize er det samme som opprinnelig og at du bruker samme paritetsalgoritme. Standard er 64KB og left-symmetric. Det er også viktig at paritsjonen kommer i samme rekkefølge som de opprinnelig gjorde. Det kan du finne ut med mdadm --examine /dev/sdc1 som du må kjøre på alle diskene. Se etter linjen

this 1 8 33 1 active sync /dev/sdc1

Hvor det er det tallet som står i kursiv du skal se på. Den første partisjonen har tallet 0, den andre har 1 osv...

 

Hvis du gjenoppretter arrayet nøyaktig som før vil du ikke miste noe data. Selv om du skulle opprette arrayet feil, er det bare å stoppe arrayet og prøve på nytt, så lenge du ikke har skrevet data til partisjonene etter at feilen oppsto, er du trygg.

 

To late.. Men tar vare på denne info til seinere.

 

chunksize var 128, en kompis som satt opp dette for meg sist.

Arrayet er opprettet og dt har stått i 3-4 timer og rebuildet, men fikk ikke mountet det da det ikke fantes noen superblock

 

mount /dev/md2 /data/test

mount: wrong fs type, bad option, bad superblock on /dev/md2,

missing codepage or helper program, or other error

In some cases useful info is found in syslog - try

dmesg | tail or so

 

Jeg ble nok forvirret av at navnene endret seg. Derfor ble det bare kluss når jeg brukte mdadm --examine sda1, og fikk et raid0 sett når jeg forventet raid5.

 

Uansett, du mener at jeg kunne gjenskapt dette ved å kjøre "mdadm --create " og bygge det på nytt? Var i grunn det jeg gjorde, men fikk da denne info.

 

mdadm --create /dev/md2 --level=5 --chunk=128 --raid-devices=4 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1

mdadm: /dev/sdc1 appears to contain an ext2fs file system

size=1465151808K mtime=Fri May 22 22:44:56 2009

mdadm: /dev/sdc1 appears to be part of a raid array:

level=raid5 devices=4 ctime=Thu Mar 19 20:20:00 2009

mdadm: /dev/sdd1 appears to be part of a raid array:

level=raid5 devices=4 ctime=Thu Mar 19 20:20:00 2009

mdadm: /dev/sde1 appears to be part of a raid array:

level=raid5 devices=4 ctime=Thu Mar 19 20:20:00 2009

mdadm: /dev/sdf1 appears to contain an ext2fs file system

size=1196716352K mtime=Fri May 22 22:44:56 2009

mdadm: /dev/sdf1 appears to be part of a raid array:

level=raid5 devices=4 ctime=Thu Mar 19 20:20:00 2009

Continue creating array? n

mdadm: create aborted.

root@sirius:/home/espen# mdadm --create /dev/md2 --level=5 --chunk=128 --raid-devices=4 missing /dev/sdd1 /dev/sde1 /dev/sdf1

mdadm: /dev/sdd1 appears to be part of a raid array:

level=raid5 devices=4 ctime=Thu Mar 19 20:20:00 2009

mdadm: /dev/sde1 appears to be part of a raid array:

level=raid5 devices=4 ctime=Thu Mar 19 20:20:00 2009

mdadm: /dev/sdf1 appears to contain an ext2fs file system

size=1196716352K mtime=Fri May 22 22:44:56 2009

mdadm: /dev/sdf1 appears to be part of a raid array:

level=raid5 devices=4 ctime=Thu Mar 19 20:20:00 2009

Continue creating array? y

mdadm: array /dev/md2 started.

 

/dev/sdc1 fikk jeg no tull med, så satt den som missing og la den til etterpå.

 

Varj: er klar over mkfs, men når vi satt opp dette sist så brukte kompisen min en annen funksjon for å lage filsystemet. En funksjon i mdadm?

[A!1]

Det går fint å svare ja på å overskrive raidarrayet, men det spiller en rolle hvilken rekkefølge paritsjonene kommer i.

 

Det kan være at sdf1 etter oppgraderingen var sdc1 før. Slike bytter skal allikevel ikke skape trøbbel for mdadm, ettersom det ligger i superblocken på raid-partisjonene hvilket nummer i rekkefølgen den enkelte partisjonen har.

 

Jeg tipper du har fått en lese eller skrivefeil fra en av harddiskene og at mdadm har stoppet arrayet ditt for at du ikke skulle miste data.

 

Det ser ut som du har gjort riktig isåfall, men du skulle ikke lagt til sdc1 før du fant filene dine. Da du la til sdc1, ble nok alt du hadde på sdc1 slettet.

 

Dersom du ikke har opprettet filsystemet på nytt, kan du fortsatt redde dataene. Du kan bruke et degraded array som mangler én disk.

 

Opprett arrayet på nytt hvor du prøver forskjellige rekkefølger på sdd1, sde1, sdf1 og missing. Hvis du poster output fra mdadm --examine /dev/sdf1 slik den er nå, så kan jeg prøve å gjette på hvilken rekkefølgen partisjonene lå i før krasjen. Sørg for at filene dine vises før du legger til sdc1 eller skriver til arrayet.

[MirusMentis]

Det går fint å svare ja på å overskrive raidarrayet, men det spiller en rolle hvilken rekkefølge paritsjonene kommer i.

 

Det kan være at sdf1 etter oppgraderingen var sdc1 før. Slike bytter skal allikevel ikke skape trøbbel for mdadm, ettersom det ligger i superblocken på raid-partisjonene hvilket nummer i rekkefølgen den enkelte partisjonen har.

 

Jeg tipper du har fått en lese eller skrivefeil fra en av harddiskene og at mdadm har stoppet arrayet ditt for at du ikke skulle miste data.

 

Det ser ut som du har gjort riktig isåfall, men du skulle ikke lagt til sdc1 før du fant filene dine. Da du la til sdc1, ble nok alt du hadde på sdc1 slettet.

 

Dersom du ikke har opprettet filsystemet på nytt, kan du fortsatt redde dataene. Du kan bruke et degraded array som mangler én disk.

 

Opprett arrayet på nytt hvor du prøver forskjellige rekkefølger på sdd1, sde1, sdf1 og missing. Hvis du poster output fra mdadm --examine /dev/sdf1 slik den er nå, så kan jeg prøve å gjette på hvilken rekkefølgen partisjonene lå i før krasjen. Sørg for at filene dine vises før du legger til sdc1 eller skriver til arrayet.

 

HVordan kan jeg vise filene når jeg ikke får mountet md`n ?

 

Uansett hadde allt oppe å gikk på nytt array med nytt filsystem i stad, rebootet og nå er denne /md_d2 tilbake.

 

 

cat /proc/mdstat

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]

md_d2 : inactive sde1[2](S)

488383872 blocks

 

md1 : active raid1 sda2[0] sdb2[1]

3927808 blocks [2/2] [uU]

 

md0 : active raid1 sda1[0] sdb1[1]

74220160 blocks [2/2] [uU]

 

unused devices: <none>

 

md2 som jeg nettop laget i stad er borte... i mdadm.conf henvises det kun til md0 og md1.

Hva gjør jeg for å få dette opp å gå igjen. Data er nok tapt da jeg har kjørt "mkfs ext3 /dev/md2"

 

Noen som får noe vettug ut av dette?

ls -l /dev/ | grep md

drwxrwx--- 2 root disk 140 2009-05-23 19:22 md

brw-rw---- 1 root disk 9, 0 2009-05-23 19:22 md0

brw-rw---- 1 root disk 9, 1 2009-05-23 19:21 md1

brw-rw---- 1 root disk 254, 128 2009-05-23 19:22 md_d2

lrwxrwxrwx 1 root root 7 2009-05-23 19:22 md_d2p1 -> md/d2p1

lrwxrwxrwx 1 root root 7 2009-05-23 19:22 md_d2p2 -> md/d2p2

lrwxrwxrwx 1 root root 7 2009-05-23 19:22 md_d2p3 -> md/d2p3

lrwxrwxrwx 1 root root 7 2009-05-23 19:22 md_d2p4 -> md/d2p4

 

mdadm --examine /dev/sdc1

 

mdadm -E /dev/sdc1

/dev/sdc1:

Magic : a92b4efc

Version : 00.90.00

UUID : fcdf2d1a:8a1588ca:4499047c:710dc983 (local to host sirius)

Creation Time : Sat May 23 08:10:05 2009

Raid Level : raid5

Used Dev Size : 488383872 (465.76 GiB 500.11 GB)

Array Size : 1465151616 (1397.28 GiB 1500.32 GB)

Raid Devices : 4

Total Devices : 4

Preferred Minor : 2

 

Update Time : Sat May 23 19:21:18 2009

State : clean

Active Devices : 4

Working Devices : 4

Failed Devices : 0

Spare Devices : 0

Checksum : 9714be14 - correct

Events : 14

 

Layout : left-symmetric

Chunk Size : 128K

 

Number Major Minor RaidDevice State

this 0 8 33 0 active sync /dev/sdc1

 

0 0 8 33 0 active sync /dev/sdc1

1 1 8 49 1 active sync /dev/sdd1

2 2 8 65 2 active sync /dev/sde1

3 3 8 81 3 active sync /dev/sdf1

 

 

 

mdadm --examine /dev/sdd1

 

 

mdadm -E /dev/sdd1

/dev/sdd1:

Magic : a92b4efc

Version : 00.90.00

UUID : fcdf2d1a:8a1588ca:4499047c:710dc983 (local to host sirius)

Creation Time : Sat May 23 08:10:05 2009

Raid Level : raid5

Used Dev Size : 488383872 (465.76 GiB 500.11 GB)

Array Size : 1465151616 (1397.28 GiB 1500.32 GB)

Raid Devices : 4

Total Devices : 4

Preferred Minor : 2

 

Update Time : Sat May 23 19:21:18 2009

State : clean

Active Devices : 4

Working Devices : 4

Failed Devices : 0

Spare Devices : 0

Checksum : 9714be26 - correct

Events : 14

 

Layout : left-symmetric

Chunk Size : 128K

 

Number Major Minor RaidDevice State

this 1 8 49 1 active sync /dev/sdd1

 

0 0 8 33 0 active sync /dev/sdc1

1 1 8 49 1 active sync /dev/sdd1

2 2 8 65 2 active sync /dev/sde1

3 3 8 81 3 active sync /dev/sdf1

 

 

 

/dev/sde1:

 

 

mdadm -E /dev/sde1

/dev/sde1:

Magic : a92b4efc

Version : 00.90.00

UUID : fcdf2d1a:8a1588ca:4499047c:710dc983 (local to host sirius)

Creation Time : Sat May 23 08:10:05 2009

Raid Level : raid5

Used Dev Size : 488383872 (465.76 GiB 500.11 GB)

Array Size : 1465151616 (1397.28 GiB 1500.32 GB)

Raid Devices : 4

Total Devices : 4

Preferred Minor : 2

 

Update Time : Sat May 23 19:21:18 2009

State : clean

Active Devices : 4

Working Devices : 4

Failed Devices : 0

Spare Devices : 0

Checksum : 9714be38 - correct

Events : 14

 

Layout : left-symmetric

Chunk Size : 128K

 

Number Major Minor RaidDevice State

this 2 8 65 2 active sync /dev/sde1

 

0 0 8 33 0 active sync /dev/sdc1

1 1 8 49 1 active sync /dev/sdd1

2 2 8 65 2 active sync /dev/sde1

3 3 8 81 3 active sync /dev/sdf1

 

 

 

/dev/sdf1 :

 

 

 

mdadm -E /dev/sdf1

/dev/sdf1:

Magic : a92b4efc

Version : 00.90.00

UUID : fcdf2d1a:8a1588ca:4499047c:710dc983 (local to host sirius)

Creation Time : Sat May 23 08:10:05 2009

Raid Level : raid5

Used Dev Size : 488383872 (465.76 GiB 500.11 GB)

Array Size : 1465151616 (1397.28 GiB 1500.32 GB)

Raid Devices : 4

Total Devices : 4

Preferred Minor : 2

 

Update Time : Sat May 23 19:21:18 2009

State : clean

Active Devices : 4

Working Devices : 4

Failed Devices : 0

Spare Devices : 0

Checksum : 9714be4a - correct

Events : 14

 

Layout : left-symmetric

Chunk Size : 128K

 

Number Major Minor RaidDevice State

this 3 8 81 3 active sync /dev/sdf1

 

0 0 8 33 0 active sync /dev/sdc1

1 1 8 49 1 active sync /dev/sdd1

2 2 8 65 2 active sync /dev/sde1

3 3 8 81 3 active sync /dev/sdf1

 

 

 

Slenger med litt til som kanskje kan være til nytte

 

cat /proc/partitions

 

 

cat /proc/partitions

major minor #blocks name

 

8 0 78150744 sda

8 1 74220268 sda1

8 2 3927892 sda2

8 16 78150744 sdb

8 17 74220268 sdb1

8 18 3927892 sdb2

9 0 74220160 md0

9 1 3927808 md1

8 32 488386584 sdc

8 33 488384001 sdc1

8 48 488386584 sdd

8 49 488384001 sdd1

8 64 488386584 sde

8 65 488384001 sde1

8 80 488386584 sdf

8 81 488384001 sdf1

 

 

 

mdadm.conf

 

 

mdadm.conf

#

# Please refer to mdadm.conf(5) for information about this file.

#

 

# by default, scan all partitions (/proc/partitions) for MD superblocks.

# alternatively, specify devices to scan, using wildcards if desired.

DEVICE partitions

 

# auto-create devices with Debian standard permissions

CREATE owner=root group=disk mode=0660 auto=yes

 

# automatically tag new arrays as belonging to the local system

HOMEHOST <system>

 

# instruct the monitoring daemon where to send mail alerts

MAILADDR root

 

# definitions of existing MD arrays

ARRAY /dev/md0 level=raid1 num-devices=2 UUID=85bb2bca:eee67971:d2623d69:7d0da5b6

ARRAY /dev/md1 level=raid1 num-devices=2 UUID=7289f108:0ec32d79:79eaf205:f521b840

 

# This file was auto-generated on Fri, 30 Jan 2009 18:53:59 +0000

# by mkconf $Id$

 

 

Endret 23. mai 2009 av semtex

[Varj]

mdadm lager bare logiske devices, enten det er raid eller multipathing den håndterer, du bruker mkfs til å opprette filsystem.

[HawP]

Semtex, det ser ut som om md2 arrayet ditt fortsatt er der, det er nok bare ikke blitt startet fordi mdadm (eller hva som nå forsøkte å starte det) ikke kjente til/klarte å finne alle partisjonene som utgjør arrayet. Litt merkelig egentlig, siden du har HOMEHOST <system> i mdadm.conf, og du neppe har byttet hostname etter at du laget arrayet på nytt... hvis da ikke homehost kun "funker" dersom ingen ARRAY linjer finnes i mdadm.conf ?

 

Uansett... først stopp md_d2: mdadm --stop /dev/md_d2

 

Prøv så: mdadm --assemble /dev/md2 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1

Hvis den så sier at den startet arrayet og det i følge cat /proc/mdstat ser ut til å være operativt, kan du prøve å legge

arrayet til mdadm.conf slik at mdadm "kjenner til" det: mdadm --examine --scan /dev/sdc1 >> /etc/mdadm.conf

 

Du bør da ha fått en linje på slutten av mdadm.conf:

ARRAY /dev/md2........

 

da skal du kunne starte det med: mdadm --assemble /dev/md2 , evt. mdadm --assemble --scan for å starte alle array som er nevnt i mdadm.conf. Og mdadm (eller hvordan nå arrayene dine auto-startes) bør kunne klare å assemble og starte under booting...

[MirusMentis]

Semtex, det ser ut som om md2 arrayet ditt fortsatt er der, det er nok bare ikke blitt startet fordi mdadm (eller hva som nå forsøkte å starte det) ikke kjente til/klarte å finne alle partisjonene som utgjør arrayet. Litt merkelig egentlig, siden du har HOMEHOST <system> i mdadm.conf, og du neppe har byttet hostname etter at du laget arrayet på nytt... hvis da ikke homehost kun "funker" dersom ingen ARRAY linjer finnes i mdadm.conf ?

 

Uansett... først stopp md_d2: mdadm --stop /dev/md_d2

 

Prøv så: mdadm --assemble /dev/md2 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1

Hvis den så sier at den startet arrayet og det i følge cat /proc/mdstat ser ut til å være operativt, kan du prøve å legge

arrayet til mdadm.conf slik at mdadm "kjenner til" det: mdadm --examine --scan /dev/sdc1 >> /etc/mdadm.conf

 

Du bør da ha fått en linje på slutten av mdadm.conf:

ARRAY /dev/md2........

 

da skal du kunne starte det med: mdadm --assemble /dev/md2 , evt. mdadm --assemble --scan for å starte alle array som er nevnt i mdadm.conf. Og mdadm (eller hvordan nå arrayene dine auto-startes) bør kunne klare å assemble og starte under booting...

 

Jeg får assemblet og startet det, men kun som degraded da den ene disken fortsatt vil dil md_d2 arrayet.

 

md2 : active raid5 sdc1[0] sdf1[3] sdd1[1]

1465151616 blocks level 5, 128k chunk, algorithm 2 [4/3] [uU_U]

 

md_d2 : inactive sde1[2](S)

488383872 blocks

 

md1 : active raid1 sda2[0] sdb2[1]

3927808 blocks [2/2] [uU]

 

md0 : active raid1 sda1[0] sdb1[1]

74220160 blocks [2/2] [uU]

 

Fikk kjørt mdadm --stop /dev/md_d2

og så mdadm --add /dev/md2 /dev/sde1

 

Så nå står den å resynker. Så får vi se hvordan det blir etter en reboot om noen timer.

Endret 24. mai 2009 av semtex

[A!1]

Vil anbefale deg å kjøre en badblocks /dev/sde1 for å se om det kan være noe feil på den disken.

[MirusMentis]

prøvde badblocks på en disk i går, men da ble den bare stående å henge i 2-3 timer før jeg drepte prosessen.

 

Hvordan kan jeg finne ut hvilken fysiske disk som har hvilket enhetsnavn?

[A!1]

badblocks gir ingen output med mindre den finner feil. Den bruker gjerne noen timer på å søke gjennom en hel disk.

 

Normalt er SATA1 = sda, SATA2 = sdb osv.

[MirusMentis]

Normalt er SATA1 = sda, SATA2 = sdb osv.

 

Jeg tenkte på at siden enhetsnavnene har endret seg etter update. Så burde jeg kanskje finne ut hvilke disker fysisk som er f.eks sda1 osv.. slik at jeg ved evt diskfeil veit hvilke av diskene jeg skal bytte.

Alle er fysisk like og av samme modell.

[kpolberg]

Kjør hdparm -I /dev/sd[X] da vil du få frem serie.nr på disken. Riktignok må du gjøre dette når en av diskene feiler. Da device navnet skifter ved reboot(kommer litt an på).