Du sollst das ja auch in einer Live-Session machen. Das Du nix dazu installieren kannst habe ich nicht überlesen.
Gruß Taomon
Supporter
Anmeldungsdatum: Beiträge: 8432 Wohnort: Digiworld |
Du sollst das ja auch in einer Live-Session machen. Das Du nix dazu installieren kannst habe ich nicht überlesen. Gruß Taomon |
(Themenstarter)
Anmeldungsdatum: Beiträge: 100 |
Hallo zusammen, ich habe das System wie vorgeschlagen in den grafischen (iihh 😉 ) Live Modus hochgeladen. Es hat mich tatsaechlich einiges an Überwindung gekostet,sodass ich gewartet habe, bis ich mal ein paar Stunden wirkliche Ruhe habe 😉 Ich hoffe ihr seid mir nicht böse um die lange Verzögerung: Deutet es bitte nicht als Desinteresse. Die Partitionsausgabe hat mich etwas verwirrt. Angeschlossen sind 4x2TB SATA HDDs und 1x16GB USB Stick auf dem sich das OS befindet. Und jetzt natuerlich der zweite 16 GB USB Stick fuer das Live System Im Anhang ein Bild, welches /dev/sda1 zeigt ubuntu@ubuntu:~$ cat /proc/partitions major minor #blocks name 7 0 1820752 loop0 7 1 88964 loop1 7 2 35472 loop2 7 3 144260 loop3 7 4 2376 loop4 7 5 13300 loop5 7 6 14840 loop6 7 7 3796 loop7 8 0 15602688 sda 8 1 11717632 sda1 8 2 1 sda2 8 5 3881984 sda5 8 16 15626240 sdb 8 17 15625216 sdb1 8 32 1953514584 sdc FSCK hat jede Menge Fehler ausgegeben. Ich kann die Bedeutung der einzelnen Fehler nicht nachvollziehen, aber laut log sieht es so aus, als waeren sie bereinigt worden. Die recht hohe Anzahl finde ich ziemlich beunruhigend. Ich waere dankbar über einen Hinweis, worin der Ursprung dieser Fehler liegen koennte . ubuntu@ubuntu:~$ sudo umount /dev/sda1 ubuntu@ubuntu:~$ fsck /dev/sda1 fsck from util-linux 2.31.1 e2fsck 1.44.1 (24-Mar-2018) fsck.ext2: Permission denied while trying to open /dev/sda1 You must have r/w access to the filesystem or be root ubuntu@ubuntu:~$ sudo fsck /dev/sda1 fsck from util-linux 2.31.1 e2fsck 1.44.1 (24-Mar-2018) /dev/sda1 contains a file system with errors, check forced. Pass 1: Checking inodes, blocks, and sizes Inodes that were part of a corrupted orphan linked list found. Fix<y>? yes Inode 142865 was part of the orphaned inode list. FIXED. Deleted inode 390944 has zero dtime. Fix<y>? yes Inode 451937 has corrupt extent header. Clear inode<y>? yes Inode 451937, i_blocks is 32, should be 0. Fix<y>? yes Inode 451939 was part of the orphaned inode list. FIXED. Inode 451939 has corrupt extent header. Clear inode<y>? yes Inode 451939, i_blocks is 56, should be 0. Fix<y>? yes Inode 451940 has corrupt extent header. Clear inode<y>? yes Inode 451940, i_blocks is 72, should be 0. Fix<y>? yes Inode 517473 has a extra size (1056) which is invalid Fix<y>? yes to all Inode 517473, i_blocks is 274877906944, should be 0. Fix? yes Inode 517475, i_blocks is 16777224, should be 8. Fix? yes Inode 517476 has a bad extended attribute block 16. Clear? yes Inode 517476, i_size is 70368744686136, should be 512000. Fix? yes Inode 517476, i_blocks is 2147484648, should be 1000. Fix? yes Running additional passes to resolve blocks claimed by more than one inode... Pass 1B: Rescanning for multiply-claimed blocks Multiply-claimed block(s) in inode 270380: 2358400--2358524 Multiply-claimed block(s) in inode 451938: 1833653--1833655 Multiply-claimed block(s) in inode 451973: 1833653--1833654 Multiply-claimed block(s) in inode 459921: 1833655 Multiply-claimed block(s) in inode 517476: 2358400--2358524 Pass 1C: Scanning directories for inodes with multiply-claimed blocks Pass 1D: Reconciling multiply-claimed blocks (There are 5 inodes containing multiply-claimed blocks.) File /boot/initrd.img-4.4.0-67-generic (inode #270380, mod time Sun Dec 9 23:24:36 2018) has 125 multiply-claimed block(s), shared with 1 file(s): /var/cache/apt/archives/automake1.11_1%3a1.11.6-3_all.deb (inode #517476, mod time Fri Oct 24 08:09:35 2014) Clone multiply-claimed blocks? yes File /lib/modules/4.4.0-45-generic/kernel/drivers/media/dvb-frontends/tda8261.ko (inode #451938, mod time Wed Oct 19 16:35:20 2016) has 3 multiply-claimed block(s), shared with 2 file(s): /usr/src/linux-headers-4.4.0-47/drivers/net/can/softing/Kconfig (inode #459921, mod time Sun Jan 10 23:01:32 2016) /lib/modules/4.4.0-45-generic/kernel/drivers/media/dvb-frontends/lgdt330x.ko (inode #451973, mod time Wed Oct 19 16:35:19 2016) Clone multiply-claimed blocks? yes File /lib/modules/4.4.0-45-generic/kernel/drivers/media/dvb-frontends/lgdt330x.ko (inode #451973, mod time Wed Oct 19 16:35:19 2016) has 2 multiply-claimed block(s), shared with 1 file(s): /lib/modules/4.4.0-45-generic/kernel/drivers/media/dvb-frontends/tda8261.ko (inode #451938, mod time Wed Oct 19 16:35:20 2016) Multiply-claimed blocks already reassigned or cloned. File /usr/src/linux-headers-4.4.0-47/drivers/net/can/softing/Kconfig (inode #459921, mod time Sun Jan 10 23:01:32 2016) has 1 multiply-claimed block(s), shared with 1 file(s): /lib/modules/4.4.0-45-generic/kernel/drivers/media/dvb-frontends/tda8261.ko (inode #451938, mod time Wed Oct 19 16:35:20 2016) Multiply-claimed blocks already reassigned or cloned. File /var/cache/apt/archives/automake1.11_1%3a1.11.6-3_all.deb (inode #517476, mod time Fri Oct 24 08:09:35 2014) has 125 multiply-claimed block(s), shared with 1 file(s): /boot/initrd.img-4.4.0-67-generic (inode #270380, mod time Sun Dec 9 23:24:36 2018) Multiply-claimed blocks already reassigned or cloned. Pass 2: Checking directory structure Entry 'stv0297.ko' in /lib/modules/4.4.0-45-generic/kernel/drivers/media/dvb-frontends (451920) has deleted/unused inode 451937. Clear? yes Entry 'lg2160.ko' in /lib/modules/4.4.0-45-generic/kernel/drivers/media/dvb-frontends (451920) has deleted/unused inode 451939. Clear? yes Entry 'mb86a16.ko' in /lib/modules/4.4.0-45-generic/kernel/drivers/media/dvb-frontends (451920) has deleted/unused inode 451940. Clear? yes i_faddr for inode 517473 (/usr/src/linux-headers-4.4.0-70-generic/include/config/ata/over/eth.h) is 512, should be zero. Clear? yes i_file_acl_hi for inode 517473 (/usr/src/linux-headers-4.4.0-70-generic/include/config/ata/over/eth.h) is 32, should be zero. Clear? yes Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Block bitmap differences: -1353229 +1647276 +1647542 +1647624 +1648090 +1648463 +1648480 +1648912 +1649013 +1649300 +1649415 +1649482 +1649592 +1649691 +1649734 +1649996 +1650312 +1650364 +1650451 +(1650456--1650457) +1650501 +1651329 +1652207 +1652272 +1652324 +1652451 +1652528 +1652589 +1652921 +1653043 +1653079 +(1653202--1653203) +1653276 +1654452 +1654520 +1655471 +1655715 +1655761 +1655797 +1656161 +1656225 +1656342 +1656557 +1656590 +1656696 +1656829 +1656991 +1657264 +1657798 +1658062 +1658115 +1659226 +1659284 +1659315 +1659340 +1659345 +1659606 +1659934 +1660306 +1660320 +1660558 +1660604 +1660871 +1661236 +1661335 +1661981 +1662053 +1662055 +1662089 +1662219 +1662435 +1662462 +1662806 +1662848 +1663032 +1663082 +1663342 +1663411 +1663421 +1663522 +1663529 +1663647 +1663787 +1663794 +1663891 +1664117 +1664204 +1664206 +1664358 +1664439 +1664463 +1664643 +1664649 +1665071 +1665390 +1665843 +1665901 +1665950 +1666002 +1666030 +1666149 +1666246 +1666264 +1666401 +1666899 +1667071 +1667272 +1667293 +1667311 +(1667398--1667399) +1667594 +1667610 +1667752 +1667770 +1667981 +1668096 +1668327 +1668652 +1668757 +1669119 +1669153 +1669386 +1669488 +1669548 +1669559 +1669589 +1669725 +1669948 +1670026 +1670153 +1670314 +1670355 +1670402 +1670610 +1670646 +1671024 +1671060 +1671181 +1671217 +1671331 +1671379 +1671704 +1671786 +(1671824--1671825) +1671937 +1672041 +1672154 +1672213 +1672296 +1672393 +1672430 +1672451 +1672478 +1672919 +1673047 +1673415 +1673501 +1673659 +1673937 +1673951 +1674198 +1674317 +1674472 +1674595 +1674708 +1674713 +1674752 +1674896 +1674924 +1675096 +1675109 +1675267 +1675287 +1675361 +1675504 +(1675691--1675692) +1675719 +1676186 +1676272 +1676491 +1676547 +1676556 +1676635 +1676827 +1676935 +1676993 +1677066 +1677076 +1677132 +1677201 +1677410 +1677565 +1677574 +1677626 +1677754 +1678017 +1678059 +1678087 +1678165 +1678219 +1678274 +1678335 +1678630 +1678668 +1678744 +1678830 +1678936 +1678977 +1678982 +1679029 +1679053 +1679133 +1679149 +1679216 +1679295 +1679425 +1680033 +1680582 +1680729 +1681579 +1681967 +1682262 +1682363 +1682446 +1682516 +1682905 +1683119 +1683334 +1683462 +1683661 +1683711 +1684129 +1684941 +1685219 +1685277 +1685336 +1685351 +1685518 +1685664 +1685685 +1686314 +1686391 +1686405 +1686562 +1686657 +1687091 +1687327 +1687407 +1687504 +1687536 +1687967 +1688005 +1688072 +1688305 +1688325 +1688388 +1688535 +1688736 +1688793 +1689049 +1689243 +1689326 +1689345 +1689386 +1689431 +1689628 +1689817 +1690141 +1690203 +1690328 +1690405 +1690636 +1690641 +1690651 +1690653 +1690682 +1690690 +1691009 +1691226 +1691343 +1691357 +1691448 +1691725 +1691851 +1691889 +1691891 +1691900 +1692280 +1692307 +1692314 +1692342 +1692345 +1692597 +1692743 +1692891 +1693102 +1693457 +1693507 +1693531 +1693624 +1693699 +1693827 +1693853 +1693875 +1693970 +1694007 +1694137 +1694171 +1694743 +1694881 +1694890 +1694913 +1695049 +1695055 +1695157 +1695360 +1695362 +1695404 +1695972 +1695977 +1696033 +1696392 +1696406 +1696428 +1696587 +1697289 +1698771 +1699324 +1699342 +1699499 +1699746 +1699822 +1699887 +1700065 +1700471 +1700549 +1700724 +1700948 +1700966 +1701366 +1701945 +1702139 +1702184 +1702281 +1702348 +1702639 +1702677 +1703352 +1703597 +1703735 +1703778 +1703853 -(1833525--1833527) -(1833532--1833542) -(1847738--1847746) -(2350208--2350332) Fix? yes Free blocks count wrong for group #1 (683, counted=555). Fix? yes Free blocks count wrong for group #41 (5646, counted=5647). Fix? yes Free blocks count wrong for group #55 (14, counted=28). Fix? yes Free blocks count wrong for group #56 (2, counted=11). Fix? yes Free blocks count wrong for group #71 (3372, counted=3497). Fix? yes Free blocks count wrong (154101, counted=154122). Fix? yes Inode bitmap differences: -142865 -390944 +399336 +399340 +399846 +400193 +401280 +401615 +402139 +402146 +402508 +402575 +402742 +402907 +403020 +403031 +403143 +403214 +403345 +403381 +403529 +403571 +403762 +404154 +404966 +405022 +405158 +405252 +405515 +405695 +405975 +406129 +406224 +406239 +406382 +406870 +406895 +406950 -451937 -(451939--451940) +456344 +456434 +457138 +457576 +457683 +457825 +458528 +458671 +458975 +459117 +459337 +459762 +460426 +460862 +461275 +461385 +461401 +461568 +461671 +461948 +462223 +462381 +462435 +462559 +462606 +462795 +462860 +463348 +463353 +463617 +463929 +464178 +464181 +464315 +464649 +464798 +464812 +465253 +465314 +465434 +466002 +466128 +466460 +466617 +466821 +467078 +467434 +467696 +467743 +468045 +468202 +468268 +468779 +468911 +468960 +469499 +469717 +470097 +470135 +470169 +470174 +470242 +470495 +470630 +470706 +470922 +471419 +471616 +471969 +472238 +472336 +504944 +505244 +505480 +505526 +505568 +505694 +506247 +506296 +506756 +507271 +507392 +507427 +507655 +508007 +508733 +509294 +509451 +509860 +510234 +510287 +510393 +510433 +511049 +511236 +511557 +511563 +511786 +511812 +512459 +512498 +512535 +512637 +512644 +512868 Fix? yes Free inodes count wrong for group #17 (0, counted=1). Fix? yes Free inodes count wrong for group #48 (0, counted=1). Fix? yes Free inodes count wrong for group #55 (0, counted=3). Fix? yes Free inodes count wrong (1076, counted=1081). Fix? yes /dev/sda1: ***** FILE SYSTEM WAS MODIFIED ***** /dev/sda1: 731879/732960 files (0.2% non-contiguous), 2775286/2929408 blocks Hier die smart Ausgabe: Sieht erstmal gut aus 😉 ubuntu@ubuntu:~$ sudo smartctl -H /dev/sda1 smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.0-29-generic] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org === START OF READ SMART DATA SECTION === SMART Health Status: OK Ich starte nun wieder das OS und melde die Ergebnisse ... OK, das ging gewaltig in die Hose: Das Betriebssystem startet gar nicht mehr. Es erscheint nach dem Einschalten und dem Logo des Mainboardherstellers nur noch ein blinkender Cursor in der oberen lnken Ecke. Das war´s ( Siehe Video 😢 ) Ich hoffe ihr habt noch eine rettende Idee und ratet mir nicht dazu das System komplett neu zu installieren. ☹ Zumindest würde ich gerne noch einmal auf das Raid zugreifen. [EDIT] : Sorry, sehe gerade, dass die Anhänge nicht hochgeladen wurden. Fehler: "Dieses Feld ist zwingend erforderlich." Obwohl alles ausgefüllt ist... 🙄 Viele Grüße und viel Spass beim feiern morgen 😛 |
Supporter, Wikiteam
Anmeldungsdatum: Beiträge: 8627 Wohnort: Münster |
Also in Summe 6 Datenträger. Diese Angaben passen nicht mit der folgenden Ausgabe überein: ubuntu@ubuntu:~$ cat /proc/partitions major minor #blocks name […] 8 0 15602688 sda 8 1 11717632 sda1 8 2 1 sda2 8 5 3881984 sda5 8 16 15626240 sdb 8 17 15625216 sdb1 8 32 1953514584 sdc 3 Datenträger, davon einer ohne Partitionen. Solange Du nicht verstehst, was alles defekt ist, solltest Du keinen Reparaturversuch unternehmen und an den Datenträgern nichts verändern! Dein Netzwerkproblem ist momentan irrelevant. Du hast ein zerschossenes Betriebssystem und wahrscheinlich auch defekte Hardware. Ich verschiebe dieses Thema mal nach Datenrettung alias Sicherheit. |
Supporter, Wikiteam
Anmeldungsdatum: Beiträge: 8627 Wohnort: Münster |
Bitte führe diese Prozedur aus:
Falls der Rechner keine Netzwerkverbindung hat, leite die Befehlsausgaben in eine Datei, transferiere diese Datei per USB-Stick auf einen Rechner mit Netzwerkverbindung und poste dann hier den Inhalt der Datei als Codeblock formatiert. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 100 |
Hallo kB, vielen Danke für deine Mühe! Memtest läuft nun wie von dir beschrieben. Die Netzwerk und Internetverbindung lief über DHCP bereits auf Anhieb beim ersten Start des grafischen Live Systems. Mein voriger Beitrag wurde aus dem Live-System hochgeladen. Soll die NIC dennoch im Anschluss an den Memtest getestet werden ? |
Supporter, Wikiteam
Anmeldungsdatum: Beiträge: 8627 Wohnort: Münster |
Dann hast Du Glück gehabt und die Netzwerk-Hardware ist wahrscheinlich nicht defekt.
Wenn das Netzwerk funktioniert, benötigen wir die Befehle aus Punkt 9 meiner Liste nicht mehr. Ich werde jetzt auch den Titel dieses Themas ändern auf „Datenrettung nach Stromausfall“. Das hoffentlich negative Ergebnis von Memtest ist wichtig. Zeige danach bitte die Ausgaben der Befehle aus Punkt 10 meiner Liste. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 100 |
memtest lief die Nacht durch und lief immernoch als ich zur Arbeit musste. Letzter Stand Errors: 0 ... RAM tauschen wäre auch zu schön gewesen. Bekommt man das RAID wieder eingebunden, falls das OS nicht zu retten ist ? Wenn man sich die riesige Fehlerausgabe von fsck 2 Beiträge vorher ansieht, kann man schon fast von einem defekten USB Stick ausgehen. Als ich den Linux Server / NAS zusammen baute ( Anfang 2016 ) war die einschlägige Empfehlung das Linux auf einen SLC USB Stick zu installieren. Ok, ein Blick auf die Bewertungen des USB Sticks (Nach dem Kauf geschrieben) sind recht eindeutig. Die Hardware macht wohl bei vielen Käufern Probleme https://www.amazon.de/gp/product/B00NV63YT4/ref=ppx_yo_dt_b_asin_title_o05_s01?ie=UTF8&psc=1 Hättet ihr hierzu eine andere Empfehlung ? Bzw. auf welchem Medium würdet ihr das OS in diesem Falle installieren ? Verbaut ist ein Asrock N3700-ITX im 19" Gehäuse. Die 4 Festplatten im RAID5 belegen sämtliche SATA Anschlüsse des boards. Über USB war dann der SLC Stick mit dem ubuntu Betriebsystem angeschlossen. Ich werde heute abend das memtest Ergebnis durchgeben, wobei ich aber nicht davon ausgehe, das da jetzt noch was gefunden wird. Viele Grüße Thomas |
Supporter, Wikiteam
Anmeldungsdatum: Beiträge: 8627 Wohnort: Münster |
Es wird weiter laufen bis Du es abbrichst.
Gut!
Davon sprichst Du jetzt zum ersten Mal. Befürchtet hatte ich es allerdings schon.
Ein USB-Stick als / eines Dateiservers ist schon ziemlich verwegen, da das Betriebssystem ständig Logs und anderes schreibt. Flash-Speicher ist nach ca. 100000 Schreibvorgängen kaputt. (Bei SSDs dauert es etwas länger, weil das Betriebssystem der SSD aufpasst und ggf. bereits häufig beschriebene Zellen durch frische ersetzt.) Du solltest nachdenken, wo Du die notwendig variablen Zweige des Dateisystems unterbringst (/tmp/, /run/, /var/, weitere?) und wie Du mit Software-Aktualisierungen verfährst: Unkritisch solche zulassen ist Gift für den USB-Stick ./. Sicherheitsupdates ignorieren ist Gift für die Sicherheit Deiner Daten. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 100 |
Guten Abend, memtest habe ich mit 0 Errors beendet, den "OS-Stick" konnte ich mit einem anderen Rechner auslesen und die Daten sichern. Das RAID5 hatte ich über MDADM als Software-RAID mittels der regulären onboard SATA Controller angelegt. Hier die /etc/fstab: # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/sda1 during installation UUID=1fce1b03-2ccd-4db5-b28e-6b81bafd70f2 / ext4 errors=remount-ro 0 1 # swap was on /dev/sda5 during installation UUID=aa51cebf-297e-4218-83ed-991cb72afa5d none swap sw 0 0 # raidmount 5 /dev/md0 /media/nas ext4 defaults 0 2 #192.168.178.124:/Filme /media/ReadyNAS nfs rw 0 0 → #192.168.178.124:/Filme /media/ReadyNAS nfs rw 0 0 ist noch ein veraltetes Überbleibsel. Der Stick an sich hat während des sehr lange dauernden Kopiervorganges keinerlei Zicken gemacht. Mir ist lediglich aufgefallen: ( Muss nicht wichtig sein )
|
(Themenstarter)
Anmeldungsdatum: Beiträge: 100 |
Spricht etwas dagegen den USB Stick wieder einzubauen, oder sollte ich evtl noch Daten liefern ? |
Supporter, Wikiteam
Anmeldungsdatum: Beiträge: 8627 Wohnort: Münster |
Wenn Du die Daten auf dem RAID retten bzw. den Verbund weiterverwenden möchtest, dann benötigst Du die genauen Befehle, mit denen Du das RAID eingerichtet hattest und auch die Ausgaben der Befehle, welche ich Dir vorgeschlagen hatte. Du kannst auch wie im Wiki beschrieben versuchen, die Konfiguration aus dem Superblock des RAID zu lesen.
Soweit OK.
Aus meiner Sicht bist Du entweder sehr geduldig oder Du hast ein sehr tolerantes Verständnis für „keinerlei Zicken“. Der Stick ist selbstverständlich Elektro-Schrott! |
(Themenstarter)
Anmeldungsdatum: Beiträge: 100 |
Hi, der Stick kommt so oder so weg, dennoch seltsam, dass der Fehler grundsätzlich in Verbindung mit einer gleich benannten 0b Datei auftrat. Wie dem auch sei, ich werde morgen Festplattenersatz besorgen. Ich habe mir die exakten Befehle seiner Zeit nicht weggeschrieben, aber ich hatte die mdadm.conf Datei gesichert.(s.u.) Der Befehl wird aber ähnlich dem Syntax : sudo mdadm --create /dev/md0 --auto md --level=5 --raid-devices=4 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 gelautet haben. . mdadm.conf: # mdadm.conf # # Please refer to mdadm.conf(5) for information about this file. # # by default (built-in), scan all partitions (/proc/partitions) and all # containers for MD superblocks. alternatively, specify devices to scan, using # wildcards if desired. #DEVICE partitions containers # 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/md/0 metadata=1.2 UUID=0d8994b4:c36bd49a:d40a6645:cb4a7e2e name=linux-server:0 ARRAY /dev/md/0 metadata=1.2 UUID=0d8994b4:c36bd49a:d40a6645:cb4a7e2e name=linux-server:0 Die Daten auf dem RAID sind zwar nicht "überlebensntwendig" , aber es würde mir einiges an Arbeit und Zeit sparen, sie noch einmal retten zu können. Grüße ––– EDIT: Die Wiederherstellung eines SW-RAIDs bei Betriebssystemausfall ist in der mdadm wiki Seite sehr gut beschrieben ( sudo mdadm --assemble --scan ). So wie es dort angegeben ist, ist die Angabe der UID etc. optional, bzw nur notwendig, wenn man mehrere RAIDs einsetzt. Das lässt zumindest hoffen. Um nichts unversucht zu lassen, würde ich gerne noch einmal versuchen über das alte OS an das RAID zu gelangen. Falls der Bootvorgang aufgrund einer fehlerhaften grub Konfig verhindert wird ( blinkender Cursor oben links nach BIOS ) , müsste man dies doch von einem fremden Rechner aus ( USB Stick anschliessen ) reparieren können. Ich tue mich nur etwas schwer mit der diesbezüglichen wiki Seite ( https://wiki.ubuntuusers.de/GRUB_2/Reparatur/ ). Für mich zutreffend wäre der Abschnitt "Reparatur mittel Desktop-CD" ich bin mir nur unsicher bei der chroot Sektion. Viele Grüße Thomas |
(Themenstarter)
Anmeldungsdatum: Beiträge: 100 |
Hallo zusammen, ubuntu server 18.04 läuft nun auf einer SSD Festplatte. Die Laufwerke wurden gefunden. 4xHDD 1xSSD (OS) toempie@linux-server:/dev$ cat /proc/partitions major minor #blocks name 7 0 93172 loop0 7 1 93284 loop1 8 0 1953514584 sda 8 16 1953514584 sdb 8 32 1953514584 sdc 8 48 117227520 sdd 8 49 1024 sdd1 8 50 104857600 sdd2 8 51 12366848 sdd3 8 64 1953514584 sde . . toempie@linux-server:/dev$ sudo blkid -o list -w /dev/null device fs_type label mount point UUID --------------------------------------------------------------------------------------------------------------- /dev/sdb linux_raid_member linux-server:0 (in use) 0d8994b4-c36b-d49a-d40a-6645cb4a7e2e /dev/sdc linux_raid_member linux-server:0 (in use) 0d8994b4-c36b-d49a-d40a-6645cb4a7e2e /dev/sdd2 ext4 / b2061c12-e5ee-44b9-b4bc-17cd09862f99 /dev/sdd3 ext4 /tmp 51e5496a-3208-4f4a-a451-e9b08423c028 /dev/sde linux_raid_member linux-server:0 (in use) 0d8994b4-c36b-d49a-d40a-6645cb4a7e2e /dev/loop0 squashfs /snap/core/6350 /dev/loop1 squashfs /snap/core/6531 /dev/sda (not mounted) /dev/sdd1 (not mounted) Offensichtlich versuchte ubuntu mdadm automatisch zu reparieren, denn es existierte direkt nach dem ersten boot mit den 4 Festplatten eine /dev/md127 , wobei aber die mdadm.conf leer war . Nach etwas Kopfkratzen und googlen die Lösung über "update-initramfs -u" . ...Warum auch immer ... . Jetzt zur Problemstellung: cat /proc/mdstat zeigt 3 Platten an anstatt 4 toempie@linux-server:/dev$ cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md0 : inactive sdb[1](S) sde[4](S) sdc[2](S) 5860150536 blocks super 1.2 unused devices: <none> .. Bei den Raid Details fehlt ebenfalls auf, dass sda fehlt, der Status inaktiv ist und ein Raid0 eingerichtet wurde. Vor dem Austausch des Betriebssystems aufgrund eines Datenträgerdefektes war es ein Raid5. .. toempie@linux-server:/dev$ sudo mdadm --detail /dev/md0 /dev/md0: Version : 1.2 Raid Level : raid0 Total Devices : 3 Persistence : Superblock is persistent State : inactive Working Devices : 3 Name : linux-server:0 (local to host linux-server) UUID : 0d8994b4:c36bd49a:d40a6645:cb4a7e2e Events : 49519 Number Major Minor RaidDevice - 8 64 - /dev/sde - 8 32 - /dev/sdc - 8 16 - /dev/sdb Wie gesagt, diese Einrichtung muss automatisch beim ersten Systemstart erfolgt sein. Da try & error hier nun nicht angesagt sind, würde ich euch gerne um Rat fragen, bevor ich das was noch da ist zerschiesse. . 1. Warum legt das System automatisch ein Raid0 an und "vergisst" dabei eine Platte (sda) ? 2. Wie ändere ich die Konfig in Raid5 inkl. der fehlenden Platte sda (Raid auflösen und --assemble --scan ?) ? 3. Wieso steht der Status auf inaktiv ? 4. /proc/mdstat zeigt sämtliche Laufwerke auls Spare.Platten(S). Eine weitere Laune der automatischen Einrichtung? 5. Anscheinende wurden die Geräte (sdb) eingebunden, anstatt die Partitionen (sdb1). Wie kann ich dieses beheben? 6. (Nicht so wichtig) : Gibt es kommandozeilenbasiert auch einen Ruhezustand für das gesamte System, anstatt nur für die Festplatten via hdparm ? 7. (Nicht so wichtig) : Kann man die Gerätezuordnung /sda /sdb /sdc etc. anpassen? Reiner Schönheitsfehler: die Systemplatte /sdd befindet sich zwischen den Raid hdds . Ich würde mich freuen, wenn ihr mir helfen könntet wieder Zugriff auf das RAID zu bekommen. Viele Grüße . EDIT: sudo mdadm --assemble --scan hat kein bestehendes raid gefunden, wahrscheinlich, weil bereits eines automatisch angelegt wurde. Grüße Thomas EDIT2: Es kommt wieder Leben ins Haus: toempie@linux-server:~$ sudo mdadm --detail /dev/md0 /dev/md0: Version : 1.2 Creation Time : Tue Apr 19 13:00:38 2016 Raid Level : raid5 Array Size : 5860150272 (5588.67 GiB 6000.79 GB) Used Dev Size : 1953383424 (1862.89 GiB 2000.26 GB) Raid Devices : 4 Total Devices : 4 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Thu Mar 14 19:35:05 2019 State : clean, degraded, recovering Active Devices : 3 Working Devices : 4 Failed Devices : 0 Spare Devices : 1 Layout : left-symmetric Chunk Size : 512K Consistency Policy : bitmap Rebuild Status : 2% complete Name : linux-server:0 (local to host linux-server) UUID : 0d8994b4:c36bd49a:d40a6645:cb4a7e2e Events : 51000 Number Major Minor RaidDevice State 5 8 0 0 spare rebuilding /dev/sda 1 8 16 1 active sync /dev/sdb 2 8 32 2 active sync /dev/sdc 4 8 64 3 active sync /dev/sde
|