• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst]root-Partition Read-Only nach Upgrade auf SL 11

R

rcu

Newbie
Ich habe testweise versucht, ein OpenSuSE 10.2 System auf OpenSuSE 11 upzugraden. Zuerstmal einen lauffähigen Klon auf neue Partition (hier /dev/sda2) gemacht, und von dieser dann gebootet. (Hetzner Root-Server)

So bin ich dann vorgegeangen:
1. Upgrade auf 10.3 mittels smart mit den 10.3 oss und update channels
2. Software Update mittels YaST

reboot ...
- soweit so gut, alles funktioniert noch...

3. Upgrade von rpm und zypper auf OpenSuSE 11 Versionen, Ersetzen der Paketquellen gemäß diesem HowTo:
Upgrading openSUSE 10.3 –> 11.0 in a running system:
http://blogs.warwick.ac.uk/bweber/entry/upgrading_opensuse_103/

4.
Code: 
#zypper ref
#zypper dup

- Super, alles funktioniert immernoch, apache, mysql, postfix, usw. laufen auch in der neuen Version weiter, ggf. nach Dienste-Neustart.

Schließlich: Anpassen der Boot-Konfiguration auf dem Hauptsystem, um den neuen Kernel zu booten:

Code: 
timeout 3
default 1

#Das folgende funktioniert:
title Linux (openSUSE 10.2)
root (hd0,0)
kernel /boot/vmlinuz-2.6.18.8-0.10-bigsmp root=/dev/sda1 ro vga=0x317
initrd /boot/initrd-2.6.18.8-0.10-bigsmp

#Das da ist das neue System:
title openSUSE 11.0 - 2.6.25.11-0.1 (pae)
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.25.11-0.1-pae root=/dev/sda2 ro vga=0x317
    initrd /boot/initrd-2.6.25.11-0.1-pae

Die entsprechende fstab:

Code: 
proc /proc proc defaults 0 0
none /dev/pts devpts gid=5,mode=620 0 0
/dev/sda2 / ext3 defaults 0 0
/dev/sdb2            swap                 swap       defaults              0 0

5. reboot. Klappt, bootet. Nach ca. 10 min kann ich mich per ssh anmelden.

Das Problem aber:
Das komplette System ist Read-Only gemountet. Unter /var/log/ finden sich keine neuen Anhängsel, "'#touch testdatei" geht nicht, egal wo, da "unzureichende Berechtigung - Readonly-FS" oder so ähnlich.

Was schließlich funktioniert:
#mount /dev/sda1 /mnt
#nano /mnt/boot/grub/menu.lst
#default=0 setzen
#shutdown -r now

Altes System geht wieder.

Ein paar der letzten Einträge aus /var/log/messages:
Code: 
Aug 19 08:53:01 derserver /usr/sbin/cron[14439]: pam_loginuid(crond:session): Cannot open /proc/self/loginuid: Read-only file system
Aug 19 08:53:01 derserver /usr/sbin/cron[14439]: pam_loginuid(crond:session): set_loginuid failed
Aug 19 08:53:01 derserver /usr/sbin/cron[14439]: Cannot make/remove an entry for the specified session
Aug 19 08:53:12 derserver master[30555]: process 14438 exited, status 0
Aug 19 08:54:01 derserver /usr/sbin/cron[14440]: pam_loginuid(crond:session): Cannot open /proc/self/loginuid: Read-only file system
Aug 19 08:54:01 derserver /usr/sbin/cron[14440]: pam_loginuid(crond:session): set_loginuid failed
Aug 19 08:54:01 derserver /usr/sbin/cron[14440]: Cannot make/remove an entry for the specified session
Aug 19 08:55:01 derserver /usr/sbin/cron[14442]: pam_loginuid(crond:session): Cannot open /proc/self/loginuid: Read-only file system

Ich hoffe dieses Forum passt am ehesten auf mein Problem, falls nicht, bin ich fürs Verschieben dankbar.

Sollte irgendwas unklar sein, bitte nachhaken.
Danke schonmal für Eure Bemühungen, mir zu helfen!

Also nochmal kurz das eigentliche Problem:

Nach reboot ist das System read-only.
Es können keine Logdateien geschrieben werden.

Was könnte beim booten schief laufen, und wie finde ich das heraus, ohne Monitor = physischen Zugriff auf den Server? :???:
 
A

Anonymous

Gast
#Das da ist das neue System:
title openSUSE 11.0 - 2.6.25.11-0.1 (pae)
root (hd0,1)
kernel /boot/vmlinuz-2.6.25.11-0.1-pae root=/dev/sda2 ro vga=0x317
initrd /boot/initrd-2.6.25.11-0.1-pae
Zum Vergrößern anklicken....

nimm mal das readonly aus der Grubkonfiguration raus.

robi
 
OP
R

rcu

Newbie
Danke robi,
ich kann das erst morgen früh probieren, da das System noch bis in die Nacht produktiv im einsatz ist. :/

Ich habe bisher gedacht, das ro bezöge sich auf den Kernel... oder?
Habe gerade die menu.lst auf meinem vmware-Spielplatz angeschaut, da ist auch nix mit ro. Hätte ich gleich probieren sollen,...

Meine vm:
Code: 
###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 11.0 - 2.6.25.11-0.1
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.25.11-0.1-default root=/dev/sda2 resume=/dev/sda1 splash=silent showopts vga=0x332
    initrd /boot/initrd-2.6.25.11-0.1-default

Ohne jetzt offtopic rumflamen zu wollen muss ich ich doch feststellen, dass es für mich schon fast immer ein Fehler war, die Boot-Vorschläge von YaST ernstzunehmen.
(und um noch mehr OT zu werden: "apt-get dist-upgrade" ist schon was tolles, gell?!)

Kann mir jemand erklären, warum der erste Menüeintrag in ein funktionierendes System bootet?
Naja, danke erstmal, ich schreibe morgen, was passiert...
 
T

Tooltime

Advanced Hacker
Ohne richtig darüber nach zu denken, würde ich sagen die fstab sieht einwenig merkwürdig aus.
a)
Die fstab wird Zeilenweise abgearbeitet, daher sollte auch auf die Reihenfolge der Einträge geachtet werden. Möglicher Weise verhindert das zu frühe mounten von proc, das remounten vom schreibgeschützen root-Filesystem.
b)
Vielleicht fehlt auch das eine oder Pseudo-Filesystem "sysfs, debugfs".

Beispiel fstab(11.0):
Code: 
# Zuerst swap mounten
/dev/disk-part1 swap                 swap       defaults              0 0
# Als nächstes root-Filesystem mounten
/dev/disk-part2 /                    ext3       acl,user_xattr        1 1
# Weitere lokale Filesysteme mounten
/dev/disk-part3 /home 		     ext3       defaults              1 2
# Pseudo Filesysteme des Kernels mounten
proc                 /proc                proc       defaults              0 0
sysfs                /sys                 sysfs      noauto                0 0
debugfs              /sys/kernel/debug    debugfs    noauto                0 0
usbfs                /proc/bus/usb        usbfs      noauto                0 0
devpts               /dev/pts             devpts     mode=0620,gid=5       0 0
 
OP
R

rcu

Newbie
Mit Hilfe einer lokalen virtuellen Maschine konnte ich das Problem lösen. Da ich aus datenschutzmäßigen Gründen etwas ZU sparsam mit meinen Angaben war konnte mir auch keiner gezielt helfen - falls meine folgende Lösung in Bezug auf das Threadthema unbrauchbar ist, den Thread bitte löschen.

Der zu bootende Kernel befand sich eigentlich auf SATA-Platte 1 statt Platte 0.
Nach dem Laden des Kernels wurden sda und sdb vertauscht. Ein mounten über UUID oder disklabel hätten dies verhindert.

Dank auch an Tooltime: dass die fstab zeilenweise abgearbeitet wird, war mir neu. Die vorhandene fstab funktioniert trotzdem, v.a. da die /boot-Partition jetzt auf SATA-Platte 0 liegt und Platte 1 als sdb gemappt wird.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben