[Eisfair] Wiki-Artikel zum Wechsel auf Kernel 4.9

[Thomas Zweifel]

Hallo Hilmar

Am 07.12.19 um 23:51 schrieb Hilmar Böhm:
> Echt gut! und vielen Dank für Deine Arbeit.
> 
> Bei mir lief der Upgrade (Boot-Partitionvergrössern) leider nicht so
> easy, obwohl ich alle Schritte so durchgeführt habe, wie Du sie jetzt
> am Anfang Deines Artikel beschrieben hast.
> Der Unterschied war aber, dass ich nur mit einer Single Systemdisk
> gearbeitet habe, kein RAID.

Die Anleitung ist nur für Raid gedacht. Wie man /boot ohne Raid 
vergrössert ist in der Anleitung von Marcus schon enthalten.


> Mein 1. Versuch - als Test - mit einem virtuellen Eis (KVM) lief
> einwandfrei, wie erwartet.
> Deswegen habe ich mich an meinwn alten EIS-1 Server (Hardware/Eisen)
> gewagt. Nach dem "resize2fs" war allerdings der Superblock der neuen
> Bootpartition invalid. Damit konnte auch das vorhandene (alte)
> Filesystem (ext3) nicht mehr gemountet werden. Eine Reparatur mit
> Ersatz-Superblocks funktionierte nicht.
> 
> Das passierte sowohl, wenn ich die Operationen online/im laufenden
> Betrieb mit eisfair durchgeführt habe, als auch mit einem extern
> angebooteten OS (Clonezilla, keine GUI bei nur 230MB Mem.).

Das lässt sich, ohne den genauen Weg zu kennen den Du unternommen hast, 
lediglich als Folgefehler vermuten.


Beim Non-Raid wäre mein vorgehen etwa so (wenn ich nur 
eisfair-Boardmittel nutzen wollte)

Swap deaktivieren, /boot umounten und ein Backup davon per dd erstellen 
/dev/sda1 --> /tmp/bootfs.
Dann die Partitionen per [g|f]disk ändern und das Backup von /boot 
zurückkopieren - Da der Startsektor der ersten Partition gleich bleibt 
bootet der Rechner nach wie vor - Die geänderte Partitionstabelle muss 
allerdings über einen Reboot neu eingelesen werden.
Nach dem Reboot das ext-fs von /boot vergrössern, lilo aufrufen und den 
swap wieder aktivieren.

Dies allerdings ohne Garantie, da ich nicht getestet habe ob Theorie und 
Praxis miteinander können.... :-)



> Nun, ich hab's mit einigen Klimmzügen und einem Backup doch noch
> hingekriegt!

Gut.


> Jetzt habe ich 2 Fragen:
> - Du hast alle Aktionen im laufenden Betrieb durchgeführt?

Ja, während sda als ausgefallen gilt (bearbeitet wird) laufen das System 
und die Dienste auf sdb weiter, und umgekehrt läuft das System und 
Dienste auf sda während sdb bearbeitet wird.


> - Du schreibst: "Die Raid-Superblocks von sda1 und sda2 löschen wir
> ebenfalls". Warum löscht Du explizit die Superblocks?

Das ist reine Angewohnheit, vermeidet Probleme bei geklonten 
installationen die dann mit der nicht gewollten Platte starten, oder 
mdadm dazu bringen die Arbeit komplett zu verweigern.

In dem Fall wäre es nicht zwingend nötig. ;-)


> Werden beim
> Löschen/Vergrößern mit fdisk/gdisk nicht automatisch neue Superblocks
> erzeugt?

Nein, die werden erst beim Erneuten hinzufügen zum Raid neu erstellt.

Wobei ich den Eindruck nicht loswerde, dass wir da aneinander vorbeireden:

Die Superblocks beim Dateisystem und der Raid-Superblock sind nicht zu 
verwechseln, beide beinhalten jedoch Metadaten die für den Betrieb nötig 
sind. ;-)


eis # dd if=/dev/zero of=/tmp/testfs bs=1G count=1
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.04844 s, 524 MB/s

eis # mke2fs -b4096 -m0 -i16384 -text4 -j /tmp/testfs
mke2fs 1.45.1 (12-May-2019)
Discarding device blocks: done
Creating filesystem with 262144 4k blocks and 65536 inodes
Filesystem UUID: d8a0253e-6d44-46ac-a2f8-374c9407c2a2
Superblock backups stored on blocks:
         32768, 98304, 163840, 229376

Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done


eis # mdadm -D /dev/md1
/dev/md1:
            Version : 0.90
      Creation Time : Fri Dec  6 08:56:11 2019
         Raid Level : raid1
         Array Size : 98240 (95.94 MiB 100.60 MB)
      Used Dev Size : 98240 (95.94 MiB 100.60 MB)
       Raid Devices : 2
      Total Devices : 2
    Preferred Minor : 1
        Persistence : Superblock is persistent

      Intent Bitmap : Internal

        Update Time : Sat Dec  7 18:25:29 2019
              State : clean
     Active Devices : 2
    Working Devices : 2
     Failed Devices : 0
      Spare Devices : 0

Consistency Policy : unknown

               UUID : cc84bcaa:66f12d51:3d186b3c:53958f34
             Events : 0.110

     Number   Major   Minor   RaidDevice State
        0       8        1        0      active sync   /dev/sda1
        1       8       17        1      active sync   /dev/sdb1





Gruss Thomas