[e1] fstab bind-mount Bootproblem

[Taxena Gasparov]

Hallo,

seit einem Update vor einigen Monaten bootet der eisfair1-Server nicht mehr ordentlich (viele
read-only-Filesystem errors bei jedem Schritt/Dienst).

Ursächlich ist meine fstab-Zeile der Art

/public/AB/boot /srv/tftpboot/boot none ro,bind 0 0

zu sein: Nicht nur /public/AB/boot wird ro,bind gemountet, sondern es wirkt sich auch auf das /-Dateisystem,
welches auf einer Partition liegt, aus.

Wenn ich ein noauto als Option hinzufüge...

/public/AB/boot /srv/tftpboot/boot none ro,bind,noauto 0 0

bootet der Server problemlos, allerdings muss ich den mount-bind jedesmal manuell machen per

mount /srv/tftpboot/boot

oder eine automatisierte Krücke basteln; komischerweise wirkt sich das nicht auf den / mount hin zu read
only aus.

Hat sich in den letzten 12 Monaten etwas geändert bezüglich mount?

Dank
Taxi

[Marcus Röckrath]

Hallo Taxena,

Post by Taxena Gasparov
seit einem Update vor einigen Monaten bootet der eisfair1-Server nicht
mehr ordentlich (viele read-only-Filesystem errors bei jedem
Schritt/Dienst).
Ursächlich ist meine fstab-Zeile der Art

/public/AB/boot /srv/tftpboot/boot none ro,bind 0 0

zu sein: Nicht nur /public/AB/boot wird ro,bind gemountet, sondern es
wirkt sich auch auf das /-Dateisystem, welches auf einer Partition liegt,
aus.
Wenn ich ein noauto als Option hinzufüge...

/public/AB/boot /srv/tftpboot/boot none ro,bind,noauto
0 0

bootet der Server problemlos, allerdings muss ich den mount-bind jedesmal
manuell machen per

mount /srv/tftpboot/boot

oder eine automatisierte Krücke basteln; komischerweise wirkt sich das
nicht auf den / mount hin zu read only aus.

Füge doch mal bitte in /etc/init.d/mountfs vor der Zeile 94 (/bin/mount -av
2>/dev/null) ein

sleep 10

ein.

Post by Taxena Gasparov
Hat sich in den letzten 12 Monaten etwas geändert bezüglich mount?

Nicht das ich wüßte. Vielleicht ein Timingproblem.

[Taxena Gasparov]

Hallo Marcus,

Post by Marcus Röckrath
Füge doch mal bitte in /etc/init.d/mountfs vor der Zeile 94 (/bin/mount -av
2>/dev/null) ein
sleep 10
ein.

kein Änderung.
Daraufhin mehrere "mount; read"-Blöcke reingebaut. Nach dem ACL-mount-Teil (Zeile 97-115 in mountfs) ist /
ro gemountet.

$ cat /etc/fstab

Post by Marcus Röckrath
UUID=3... / ext4 defaults,errors=remount-ro 0 1
UUID=8... /boot ext2 defaults,errors=remount-ro 0 1
UUID=2... none swap defaults 0 0
proc /proc proc defaults 0 0
/sys /sys sysfs defaults 0 0
devpts /dev/pts devpts defaults,gid=5,mode=620 0 0
/mnt/floppy auto defaults,user,noauto 0 0
/mnt/cdrom iso9660 defaults,ro,user,noauto 0 0
/dev/sr0 /media/cdrom0 udf,iso9660 noauto,utf8 0 0
/dev/sr1 /media/cdrom1 udf,iso9660 noauto,utf8 0 0
/dev/sr2 /media/cdrom2 udf,iso9660 noauto,utf8 0 0
/dev/sr3 /media/cdrom3 udf,iso9660 noauto,utf8 0 0
/dev/sr4 /media/cdrom4 udf,iso9660 noauto,utf8 0 0
/dev/sr5 /media/cdrom5 udf,iso9660 noauto,utf8 0 0
/dev/sr6 /media/cdrom6 udf,iso9660 noauto,utf8 0 0
/dev/sr7 /media/cdrom7 udf,iso9660 noauto,utf8 0 0
/dev/sr8 /media/cdrom8 udf,iso9660 noauto,utf8 0 0
/dev/sr9 /media/cdrom9 udf,iso9660 noauto,utf8 0 0
/public/AB/boot /srv/tftpboot/boot none ro,bind 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
tmpfs /run tmpfs defaults 0 0
devtmpfs /dev devtmpfs mode=0755,nosuid 0 0

Außer daß die floppy- und cdrom-Zeile einem /dev/fd0 und /dev/cdrom oder so ähnlich, warum auch immer,
beraubt wurden, scheint da das meiste grob zu passen. Gibt es eine Muster-fstab für eisfair1, damit ich
meine fstab harmonisieren kann?

Ich vermute, der mount-Befehl hat sich in der Ausgabe geändert; früher wurden "bind"-mounts in der ersten
Spalte so wie in der fstab mit /public/AB/boot gelistet, jetzt mit /dev/sdXY. Dadurch existieren in der
Ausgabe bei mir zwei Zeilen mit /dev/sdXY, wobei die bind-Zeile zusätzlich die Option "ro" hat und das wirkt
sich womöglich beim acl-remount auf / aus. :-(

Post by Marcus Röckrath
EXT4-fs (sdXY): re-mounted. Opts: errors=remount-ro,acl,user_xattr
EXT4-fs (sdXY): re-mounted. Opts: acl,user_xattr

Es läuft darauf hinaus, daß ...
1. /dev/sdXY on / type ext4 ro,relatime,errors=remount-ro,data=ordered
2. /dev/sdXY on /srv/tftpboot/boot type ext4 ro,relatime,errors=remount-ro,data=ordered
gemountet sind; vor dem acl-Teil zeigt mount noch ...
1. /dev/sdXY on / type ext4 rw,relatime,errors=remount-ro,data=ordered
2. /dev/sdXY on /srv/tftpboot/boot type ext4 ro,relatime,errors=remount-ro,data=ordered

Wenn ich in fstab für /public/AB/boot von ro zu rw ändere bleibt / rw, aber der bind mount möchte ich nicht
rw sondern ro haben.

Kann das jemand bestätigen?

Dank
Taxi

[Taxena Gasparov]

Post by Taxena Gasparov
Wenn ich in fstab für /public/AB/boot von ro zu rw ändere bleibt / rw, aber der bind mount möchte ich nicht
rw sondern ro haben.

Lösungsmöglichkeit:
Beim mount der "restlichen" Dateisysteme in fstab, sollte die bind-mounts unbeachtet bleiben.
Der acl-remount würde nur auf echte Dateisysteme angewandt.
Ein darauffolgender mount nur für bind-Einträge sollte daraufhin neu in mountfs eingebaut werden.

[Holger Bruenjes]

Hallo Taxi

Post by Taxena Gasparov

Post by Taxena Gasparov
Wenn ich in fstab für /public/AB/boot von ro zu rw ändere bleibt / rw, aber der bind mount möchte ich nicht
rw sondern ro haben.

Beim mount der "restlichen" Dateisysteme in fstab, sollte die bind-mounts unbeachtet bleiben.
Der acl-remount würde nur auf echte Dateisysteme angewandt.
Ein darauffolgender mount nur für bind-Einträge sollte daraufhin neu in mountfs eingebaut werden.

kommentiere mal das acl-remounten in der mountfs.

Holger

[Taxena Gasparov]

Hallo Holger,

Post by Holger Bruenjes
kommentiere mal das acl-remounten in der mountfs.
/dev/sdXY on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
/dev/sdXY on /srv/tftpboot/boot type ext4 (ro,relatime,errors=remount-ro,data=ordered)

Taxi

[Marcus Röckrath]

Hallo taxena,

Post by Taxena Gasparov

Post by Marcus Röckrath
Füge doch mal bitte in /etc/init.d/mountfs vor der Zeile 94 (/bin/mount
-av 2>/dev/null) ein
sleep 10
ein.

kein Änderung.

Ok.

Post by Taxena Gasparov
Daraufhin mehrere "mount; read"-Blöcke reingebaut. Nach dem ACL-mount-Teil
(Zeile 97-115 in mountfs) ist / ro gemountet.

Also passiert es hier.

Post by Taxena Gasparov
$ cat /etc/fstab

Post by Marcus Röckrath
/mnt/floppy auto defaults,user,noauto 0 0
/mnt/cdrom iso9660 defaults,ro,user,noauto 0 0

Außer daß die floppy- und cdrom-Zeile einem /dev/fd0 und /dev/cdrom oder
so ähnlich, warum auch immer, beraubt wurden,

Das ist definitiv falsch, denn da fehlt beiden das Device:

/dev/fd0
/dev/cdrom

Post by Taxena Gasparov
scheint da das meiste grob
zu passen. Gibt es eine Muster-fstab für eisfair1, damit ich meine fstab
harmonisieren kann?

Mein relativ frisch installierter eis64 hat folgende fstab:

UUID=1c951cc5-6e00-4062-9b28-4fea81a794ac / ext4 defaults,errors=remount-ro
0 1
UUID=4cac5ec0-69eb-478a-b2d5-0fc32671e219 /boot ext4
defaults,errors=remount-ro 0 1
UUID=79c577c6-f971-4650-92a2-5c9b69b0c91b none swap sw 0 0
proc /proc proc defaults 0 0
/dev/fd0 /media/floppy auto defaults,user,noauto 0 0
/dev/cdrom /media/cdrom iso9660 defaults,ro,user,noauto 0 0
devpts /dev/pts devpts defaults,gid=5,mode=620 0 0
/sys /sys sysfs defaults 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
tmpfs /run tmpfs defaults 0 0
devtmpfs /dev devtmpfs mode=0755,nosuid 0 0

Deine /media/cdrom* Zeilen könnten vom webcdwriter stammen.

Post by Taxena Gasparov
Ich vermute, der mount-Befehl hat sich in der Ausgabe geändert; früher
wurden "bind"-mounts in der ersten Spalte so wie in der fstab mit
/public/AB/boot gelistet, jetzt mit /dev/sdXY. Dadurch existieren in der
Ausgabe bei mir zwei Zeilen mit /dev/sdXY, wobei die bind-Zeile zusätzlich
die Option "ro" hat und das wirkt sich womöglich beim acl-remount auf /

Post by Marcus Röckrath
EXT4-fs (sdXY): re-mounted. Opts: errors=remount-ro,acl,user_xattr
EXT4-fs (sdXY): re-mounted. Opts: acl,user_xattr

Ob die Ausgabe von mount sich geändert hat, kann ich selbst nicht mehr
nachvollziehen, da ich sowas nicht bentutz habe.

Aktuell steht aber das Device an erster Stelle und dann wird es im
Initskript zweimal remountet und es schlägt nun das ro zu, da dieses eben
zuletzt dran ist.

Ich diskutiere das mal mit Holger.

[Marcus Röckrath]

Hallo Taxena,

Post by Marcus Röckrath

Post by Taxena Gasparov
$ cat /etc/fstab

Post by Marcus Röckrath
/mnt/floppy auto defaults,user,noauto 0 0
/mnt/cdrom iso9660 defaults,ro,user,noauto 0 0

Außer daß die floppy- und cdrom-Zeile einem /dev/fd0 und /dev/cdrom oder
so ähnlich, warum auch immer, beraubt wurden,

/dev/fd0 /media/floppy auto defaults,user,noauto 0 0
/dev/cdrom /media/cdrom iso9660 defaults,ro,user,noauto 0 0

Weil deine Mounts für Floppy und CDRom, aus welchem Grund auch immer, nicht
in /media liegen, sind die Devices bei der Umschreibung wegen udev
(UUID-Einträge) verloren gegangen.

Schau, ob die notwendigen Unterverzeichnisse in /media vorhanden sind und
korrigiere die fstab gemäß unserem Standard.

Das hat aber mit dem ro-Mountproblem nichts zu tun; nach Holgers-Beitrag
unterbinde mal das remounten wegen acl, denn das ist sowieso Standard und
sollte schon beim ersten Mount der Plattenpartitionen aktiv werden.

[Thomas Bork]

Post by Marcus Röckrath
Das hat aber mit dem ro-Mountproblem nichts zu tun; nach Holgers-Beitrag
unterbinde mal das remounten wegen acl, denn das ist sowieso Standard und
sollte schon beim ersten Mount der Plattenpartitionen aktiv werden.

Das ist Kernel-abhängig. Habt Ihr das mit allen für eisfair möglichen
Kernel-Versionen, die unter dieser base laufen könnten, für die
angegebenen Dateisysteme ext2,ext3,ext4,xfs überprüft?

[Marcus Röckrath]

Hallo Thomas,

Post by Thomas Bork

Post by Marcus Röckrath
Das hat aber mit dem ro-Mountproblem nichts zu tun; nach Holgers-Beitrag
unterbinde mal das remounten wegen acl, denn das ist sowieso Standard und
sollte schon beim ersten Mount der Plattenpartitionen aktiv werden.

Das ist Kernel-abhängig. Habt Ihr das mit allen für eisfair möglichen
Kernel-Versionen, die unter dieser base laufen könnten, für die
angegebenen Dateisysteme ext2,ext3,ext4,xfs überprüft?

Natürlich nicht und deine Frage ist eher rethorischer Natur, denn wo soll
ich nun alle möglichen alten Kernel herbekommen und durchtesten.

Wenn das remount zwinegnd drin bleiben muss, müssen wir sehen, wie wir dann
aber den hier aufgetretenen Effekt verhindern können.

[Thomas Bork]

Post by Marcus Röckrath
Natürlich nicht und deine Frage ist eher rethorischer Natur, denn wo soll
ich nun alle möglichen alten Kernel herbekommen und durchtesten.

Z.B. von mir.

Post by Marcus Röckrath
Wenn das remount zwinegnd drin bleiben muss, müssen wir sehen, wie wir dann
aber den hier aufgetretenen Effekt verhindern können.

Wenn man darüber nachdenkt, mit dem Weglassen des acl-Remounts ein
Problem zu lösen, sollte man sich auch damit beschäftigen, was das auf
anderen Systeme für Auswirkungen haben kann.

Werden bestimmte Partitionen durch diese Korrektur nicht mehr
acl-remountet, hat das auch Auswirkung auf darauf angewiesene Programme
wie Samba.

Was ich bis jetzt herausgefunden habe ist:

1.
Es ist auch *nicht nur* Kernel-abhängig, welche Standard-Mount-Optionen
ein Device mit einem bestimmten Dateisystem hat. In dem Kernel müssen
für die entsprechenden Dateisysteme die entsprechenden Optionen
aktiviert worden sein.

a)
Es kommt auch darauf an, mit welcher Version von mkfs.FILESYSTEM das
Dateisystem erstellt wurde.

c)
Es kommt auch darauf an, was dabei in /etc/mke2fs.conf stand.

d)
Es kommt auch darauf an, ob die Standard-Mount-Optionen mittels tune2fs
manipuliert wurden.

[Taxena Gasparov]

Hallo Tom,

Post by Taxena Gasparov
d)

sollte das nicht "l)" heißen? :-))

Im Ernst: Kann deine Bedenken nachvollziehen, leider kann ich mangels Erfahrung im acl-Bereich gerade nicht
weiterhelfen.
Alternativevorschlag hatte ich bereits genannt, wobei das die mountfs noch spezifischer macht und

Post by Taxena Gasparov
Beim mount der "restlichen" Dateisysteme in fstab, sollte die bind-mounts unbeachtet bleiben.
Der acl-remount würde nur auf echte Dateisysteme angewandt.
Ein darauffolgender mount nur für bind-Einträge sollte daraufhin neu in mountfs eingebaut werden.

Dank
Taxi

[Thomas Bork]

Post by Taxena Gasparov
Im Ernst: Kann deine Bedenken nachvollziehen, leider kann ich mangels Erfahrung im acl-Bereich gerade nicht
weiterhelfen.
Alternativevorschlag hatte ich bereits genannt, wobei das die mountfs noch spezifischer macht und

Post by Taxena Gasparov
Beim mount der "restlichen" Dateisysteme in fstab, sollte die bind-mounts unbeachtet bleiben.
Der acl-remount würde nur auf echte Dateisysteme angewandt.
Ein darauffolgender mount nur für bind-Einträge sollte daraufhin neu in mountfs eingebaut werden.

Was zeigt denn

findmnt -lo source,target,fstype,options -t ext2,ext3,ext4,xfs
findmnt -lo source,target,fsroot,fstype,options -t ext2,ext3,ext4,xfs

mit den bind-Mounts bei Dir?

[Marcus Röckrath]

Hallo Thomas,

Post by Thomas Bork
Was zeigt denn
findmnt -lo source,target,fstype,options -t ext2,ext3,ext4,xfs
findmnt -lo source,target,fsroot,fstype,options -t ext2,ext3,ext4,xfs
mit den bind-Mounts bei Dir?

Habe das hier auch mal durchgespielt:

eis64 # mount -o bind,ro /home/eis /mnt

eis64 # findmnt -lo source,target,fstype,options -t ext2,ext3,ext4,xfs
SOURCE TARGET FSTYPE OPTIONS
/dev/sda3 / ext4
rw,relatime,errors=remount-ro,data=ordered
/dev/sda1 /boot ext4
rw,relatime,errors=remount-ro,data=ordered
/dev/sda3[/home/eis] /mnt ext4
ro,relatime,errors=remount-ro,data=ordered

eis64 # findmnt -lo source,target,fsroot,fstype,options -t
ext2,ext3,ext4,xfs
SOURCE TARGET FSROOT FSTYPE OPTIONS
/dev/sda3 / / ext4
rw,relatime,errors=remount-ro,data=ordered
/dev/sda1 /boot / ext4
rw,relatime,errors=remount-ro,data=ordered
/dev/sda3[/home/eis] /mnt /home/eis ext4
ro,relatime,errors=remount-ro,data=ordered

eis64 # mount
/dev/sda3 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
/dev/sda3 on /mnt type ext4 (ro,relatime,errors=remount-ro,data=ordered)

[Marcus Röckrath]

Hallo Thomas,

Post by Thomas Bork
findmnt -lo source,target,fstype,options -t ext2,ext3,ext4,xfs
findmnt -lo source,target,fsroot,fstype,options -t ext2,ext3,ext4,xfs

Mit folgendem geänderten Code für mountfs hat es bei mir nun funktioniert:

# remount all acl enabled filesystems with acl,user_xattr,
# if kernel supports acl (excluding /boot)
for pseudofile in /proc/{ksyms,kallsyms}
do
if [ -e "$pseudofile" ]
then
if /bin/grep -q 'posix_acl_' "$pseudofile"
then
/bin/findmnt -lo source,target,fstype,options -t
ext2,ext3,ext4,xfs |
tail -n +2 | egrep -v "^/dev/[^[:space:][]*\[" |
while read source target fstype options
do
if [ "$target" != "/boot" ]
then
/bin/mount -o remount,acl,user_xattr $target
fi
done
fi
fi
done

[Marcus Röckrath]

Hallo Taxena,

Post by Marcus Röckrath

Post by Thomas Bork
findmnt -lo source,target,fstype,options -t ext2,ext3,ext4,xfs
findmnt -lo source,target,fsroot,fstype,options -t ext2,ext3,ext4,xfs

# remount all acl enabled filesystems with acl,user_xattr,
# if kernel supports acl (excluding /boot)
for pseudofile in /proc/{ksyms,kallsyms}
do
if [ -e "$pseudofile" ]
then
if /bin/grep -q 'posix_acl_' "$pseudofile"
then
/bin/findmnt -lo source,target,fstype,options -t
ext2,ext3,ext4,xfs |
tail -n +2 | egrep -v "^/dev/[^[:space:][]*\[" |
while read source target fstype options
do
if [ "$target" != "/boot" ]
then
/bin/mount -o remount,acl,user_xattr $target
fi
done
fi
fi
done

Wie hast du dich gerettet, als das /-Dateisystem ro gemountet war?

Wenn du einen sicheren Weg aus dieser Situation hast, könntest du vielleicht
mal meinen Codevorschlag für den acl-Teil ausprobieren.

[Taxena Gasparov]

Hallo Marcus,

Post by Marcus Röckrath
Wie hast du dich gerettet, als das /-Dateisystem ro gemountet war?

Strg-Alt-Entf und systemrescuecd gebootet, fstab mit noauto editiert

Post by Marcus Röckrath
Wenn du einen sicheren Weg aus dieser Situation hast, könntest du vielleicht
mal meinen Codevorschlag für den acl-Teil ausprobieren.

mach ich heute Abend, wenn's zeitlich reicht.

Taxi

[Marcus Röckrath]

Hallo Taxena,

Post by Taxena Gasparov

Post by Marcus Röckrath
Wie hast du dich gerettet, als das /-Dateisystem ro gemountet war?

Strg-Alt-Entf und systemrescuecd gebootet, fstab mit noauto editiert

Gut.

Du kannst ja auch die jetzige modofozierte mountfs vor Einfügen meines
Vorschlags wegsichern und dann notfalls im systemrescucd-osud
wiederherstellen.

Post by Taxena Gasparov

Post by Marcus Röckrath
Wenn du einen sicheren Weg aus dieser Situation hast, könntest du
vielleicht mal meinen Codevorschlag für den acl-Teil ausprobieren.

mach ich heute Abend, wenn's zeitlich reicht.

Keine Eile, vielleicht hat Thomas auch noch eine ganz andere Idee der
Realisierung.

[Taxena Gasparov]

Hallo Marcus,

Post by Marcus Röckrath
Wenn du einen sicheren Weg aus dieser Situation hast, könntest du vielleicht
mal meinen Codevorschlag für den acl-Teil ausprobieren.
/dev/sdXY on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
/dev/sdXY on /srv/tftpboot/boot type ext4 (ro,relatime,errors=remount-ro,data=ordered)

Wieso wird bei den Options kein "acl,user_xattr" für /-mount gezeigt? Diese waren zuvor auch nicht
vorhanden, aber gerade durch das Remounten sollten diese Options doch gesetzt werden. Nur bei der

Post by Marcus Röckrath
/dev/sdXZ on /boot type ext2 (rw,relatime,errors=remount-ro,user_xattr,acl)

Komisch oder passt das?

Dank
Taxi

[Marcus Röckrath]

Hallo Taxena,

Post by Taxena Gasparov

Post by Marcus Röckrath
Wenn du einen sicheren Weg aus dieser Situation hast, könntest du
vielleicht mal meinen Codevorschlag für den acl-Teil ausprobieren.
/dev/sdXY on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
/dev/sdXY on /srv/tftpboot/boot type ext4
(ro,relatime,errors=remount-ro,data=ordered)

Wieso wird bei den Options kein "acl,user_xattr" für /-mount gezeigt?
Diese waren zuvor auch nicht vorhanden, aber gerade durch das Remounten
sollten diese Options doch gesetzt werden. Nur bei der Bootpartition sind

Post by Marcus Röckrath
/dev/sdXZ on /boot type ext2
(rw,relatime,errors=remount-ro,user_xattr,acl)

Komisch oder passt das?

Ich verstehe nicht so ganz, was du meinst.

Mein Codevorschlag ändert nicht das remounten, sondern verhindert nur, das
dies auch für den bind-mount durchgeführt wird.

/boot wird und wurde früher auch schon ausgeschlossen; für / wird es getan.

Wo vermisst du es genau?

[Marcus Röckrath]

Hallo Taxena,

Post by Marcus Röckrath

Post by Taxena Gasparov
Wieso wird bei den Options kein "acl,user_xattr" für /-mount gezeigt?
Diese waren zuvor auch nicht vorhanden, aber gerade durch das Remounten
sollten diese Options doch gesetzt werden. Nur bei der Bootpartition sind

Post by Marcus Röckrath
/dev/sdXZ on /boot type ext2
(rw,relatime,errors=remount-ro,user_xattr,acl)

Komisch oder passt das?

Ich verstehe nicht so ganz, was du meinst.

Jetzt sehe ich, was du meinst.

Bitte schicke mir mal die mountfs per PM, damit ich sehen kann, ob sich da
ein Typo eingeschlichen hat.

Du kannst auch vor die eigentliche mount-Zeile eine Ausgabe platzieren:

echo "Remounting $target"

Dann sehen wir, ob hier überhaupt remontet wird.

[Marcus Röckrath]

Hallo Taxena,

Post by Taxena Gasparov
Wieso wird bei den Options kein "acl,user_xattr" für /-mount gezeigt?
Diese waren zuvor auch nicht vorhanden, aber gerade durch das Remounten
sollten diese Options doch gesetzt werden. Nur bei der Bootpartition sind

Post by Marcus Röckrath
/dev/sdXZ on /boot type ext2
(rw,relatime,errors=remount-ro,user_xattr,acl)

Hier wird mir für / (aber auch nicht für /boot) das nicht angezeigt, auch
nicht nach einem erfolgreichen remount:

/dev/sda3 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)

Vielleicht liegt es daran, dass das sowieso Standard ist:

# tune2fs -l /dev/sda1 | grep "Default mount options"
Default mount options: user_xattr acl

# tune2fs -l /dev/sda3 | grep "Default mount options"
Default mount options: user_xattr acl

Machst du bitte auch mal diese beiden Befehle.

Post by Taxena Gasparov
Komisch oder passt das?

War das anders, als du den Block komplett auskommentiert hattest?

[Taxena Gasparov]

Hallo Marcus,

Post by Marcus Röckrath
# tune2fs -l /dev/sda1 | grep "Default mount options"
Default mount options: user_xattr acl
# tune2fs -l /dev/sda3 | grep "Default mount options"
Default mount options: user_xattr acl
Machst du bitte auch mal diese beiden Befehle.

selbiges Ergebnis wie bei dir.

Post by Marcus Röckrath
War das anders, als du den Block komplett auskommentiert hattest?

nein, aber finde ich verwirrend, wenn nur Bruchteile der gesetzten Options in der Ausgabe erscheinen.
Wie du schreibst, vermutlich ist definiert, daß nur die Abweichungen vom Standard (den man sich irgendwie
ausgeben kann) angezeigt werden.

Bei meiner ext2-Bootpartition wird's angezeigt, obwohl die ja gerade vom remount ausgeschlossen ist, wenn
ich nicht irre.

Taxi

[Marcus Röckrath]

Hallo Taxena,

Post by Taxena Gasparov
Bei meiner ext2-Bootpartition wird's angezeigt, obwohl die ja gerade vom
remount ausgeschlossen ist, wenn ich nicht irre.

Ist ein weiterer Beweis für meine These, die ich auf meinem System getestet
habe:

Es wird wegen des neuen Defaults schon vorher mit acl gemountet, womit
dieser ganze remount-Block absolut unnötig ist.

[Marcus Röckrath]

Hallo Taxena,

Post by Taxena Gasparov
Wieso wird bei den Options kein "acl,user_xattr" für /-mount gezeigt?

dmesg | grep "re-mounted"

[Thomas Bork]

Post by Marcus Röckrath
/bin/findmnt -lo source,target,fstype,options -t
ext2,ext3,ext4,xfs |
tail -n +2 | egrep -v "^/dev/[^[:space:][]*\[" |
while read source target fstype options
do
if [ "$target" != "/boot" ]
then
/bin/mount -o remount,acl,user_xattr $target
fi
done

Würde ich so machen:

findmnt -n -lo source,target,fstype,options -t
ext2,ext3,ext4,xfs \
| grep -v '\[' |
while read source target fstype options
do

[Marcus Röckrath]

Hallo Thomas,

Post by Thomas Bork

Post by Marcus Röckrath
/bin/findmnt -lo source,target,fstype,options -t
ext2,ext3,ext4,xfs |
tail -n +2 | egrep -v "^/dev/[^[:space:][]*\[" |
while read source target fstype options
do
if [ "$target" != "/boot" ]
then
/bin/mount -o remount,acl,user_xattr $target
fi
done

findmnt -n -lo source,target,fstype,options -t
ext2,ext3,ext4,xfs \
| grep -v '\[' |
while read source target fstype options
do

ich wollte absolut sicherstellen, dass genau die richtigen erwischt werde
und hatte deswegen angenommen, das [ könnte aus anderem Grund an anderer
Stelle auch auftreten. :-) Safety first.

Wenn meine Beobachtungen stimmen, wäre der Code eventuell auf Dauer sowieso
obsolet.

[Taxena Gasparov]

Hallo Thomas,

Post by Thomas Bork
Was zeigt denn
findmnt -lo source,target,fstype,options -t ext2,ext3,ext4,xfs
SOURCE TARGET FSTYPE OPTIONS
/dev/sdXY / ext4 rw,relatime,errors=remount-ro,data=ordered
/dev/sdXZ /boot ext2 rw,relatime,errors=remount-ro,user_xattr,acl
/dev/sdXY[/public/AB/boot] /srv/tftpboot/boot ext4 ro,relatime,errors=remount-ro,data=ordered
findmnt -lo source,target,fsroot,fstype,options -t ext2,ext3,ext4,xfs
SOURCE TARGET FSROOT FSTYPE OPTIONS
/dev/sdXY / / ext4 rw,relatime,errors=remount-ro,data=ordered
/dev/sdXZ /boot / ext2 rw,relatime,errors=remount-ro,user_xattr,acl
/dev/sdXY[/public/AB/boot] /srv/tftpboot/boot /public/AB/boot ext4 ro,relatime,errors=remount-ro,data=ordered

Wenn ich acl wieder aktiviere in mountfs und /src/tftpboot/boot nachträglich manuell einbinde sieht's

Post by Thomas Bork
findmnt -lo source,target,fstype,options -t ext2,ext3,ext4,xfs
SOURCE TARGET FSTYPE OPTIONS
/dev/sdXY / ext4 rw,relatime,errors=remount-ro,data=ordered
/dev/sdXZ /boot ext2 rw,relatime,errors=remount-ro,user_xattr,acl
/dev/sdXY[/public/AB/boot] /srv/tftpboot/boot ext4 ro,relatime,errors=remount-ro,data=ordered
findmnt -lo source,target,fsroot,fstype,options -t ext2,ext3,ext4,xfs
SOURCE TARGET FSROOT FSTYPE OPTIONS
/dev/sdXY / / ext4 rw,relatime,errors=remount-ro,data=ordered
/dev/sdXZ /boot / ext2 rw,relatime,errors=remount-ro,user_xattr,acl
/dev/sdXY[/public/AB/boot] /srv/tftpboot/boot /public/AB/boot ext4 ro,relatime,errors=remount-ro,data=ordered

base 2.8.25
eiskernel 4.9.196-eisfair-1-SMP


Taxi

[Marcus Röckrath]

Hallo Thomas,

Post by Thomas Bork

Post by Marcus Röckrath
Natürlich nicht und deine Frage ist eher rethorischer Natur, denn wo soll
ich nun alle möglichen alten Kernel herbekommen und durchtesten.

Z.B. von mir.

:-)))))

Nicht wirklich machbar Kernel bis zurück in das Jahr 2015 zu testen, denn
seit diesem Jahr ist nach Holgers Aussage

# grep acl /etc/mke2fs.conf
default_mntopts = acl,user_xattr

gesetzt.

Post by Thomas Bork
Wenn man darüber nachdenkt, mit dem Weglassen des acl-Remounts ein
Problem zu lösen, sollte man sich auch damit beschäftigen, was das auf
anderen Systeme für Auswirkungen haben kann.
Werden bestimmte Partitionen durch diese Korrektur nicht mehr
acl-remountet, hat das auch Auswirkung auf darauf angewiesene Programme
wie Samba.
1.
Es ist auch *nicht nur* Kernel-abhängig, welche Standard-Mount-Optionen
ein Device mit einem bestimmten Dateisystem hat. In dem Kernel müssen
für die entsprechenden Dateisysteme die entsprechenden Optionen
aktiviert worden sein.
a)
Es kommt auch darauf an, mit welcher Version von mkfs.FILESYSTEM das
Dateisystem erstellt wurde.

Diesen Punkt habe ich mit meinem Altsystem getestet:

Bei der Erstellung wurde wohl nicht mit acl,xattr als Deafult gearbeitet,
denn

# tune2fs -l /dev/sda3
tune2fs 1.45.5 (07-Jan-2020)
Filesystem features: has_journal ext_attr resize_inode dir_index
filetype needs_recovery sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem created: Sat Jan 7 13:29:33 2012

Ein Zugriff und Setzen von ACLs mit setfacl/getfacl ist fehlerfrei möglich.

Nach dem Remount in mountfs auch nicht anders zu erwarten.

Nun habe ich genau diesen Remount aus mountfs entfernt und rebootet, aber
auch danach stand acl zur Verfügung, also ein auslesen und Setzen mit
getfacl/setacl funktioniert.

Ergo: Kann das System acl, wird beim Mount defaultmäßig mit acl gemountet,
es spielt also keine Rolle, mit welchen Optionen an dieser Stelle das
Dateisystem erstellt wurde.

Im Ubuntu-Wiki fand ich den Hinweis, dass eine acl-Angabe in der fstab
Vorrang vor der Definition im Dateisystem hat; wenn acl aber sowieso
Default (s. o. mount defaults in /etc/mke2fs.conf) ist, barucht es auch in
der fstab nicht angegeben zu sein.

Post by Thomas Bork
c)
Es kommt auch darauf an, was dabei in /etc/mke2fs.conf stand.

Scheinbar nicht, es kommt eher darauf an, was jetzt da drin steht.

Post by Thomas Bork
d)
Es kommt auch darauf an, ob die Standard-Mount-Optionen mittels tune2fs
manipuliert wurden.

IMHO genausowenig, wie mein Test zeigt.

Kann das System acl, dann wird es auch automatisch bei uns seit 2015
aktiviert, wenn man das nicht in der fstab explizit mit noacl abschaltet.

Dann wäre das remounting in der mountfs wirklich obsolet.

[Holger Bruenjes]

Hallo

Post by Marcus Röckrath
Nicht wirklich machbar Kernel bis zurück in das Jahr 2015 zu testen, denn
seit diesem Jahr ist nach Holgers Aussage
# grep acl /etc/mke2fs.conf
default_mntopts = acl,user_xattr
gesetzt.

Ich habe das nochmal nachgegraben ;-)

als default option 'default_mntopts = acl,user_xattr' wurde mit den
e2fsprogs 1.42 gesetzt und mit dem base update-1.8.1 vom 2012-02-18
verteilt.

Holger

[Marcus Röckrath]

Hallo Holger,

Post by Holger Bruenjes

Post by Marcus Röckrath
Nicht wirklich machbar Kernel bis zurück in das Jahr 2015 zu testen, denn
seit diesem Jahr ist nach Holgers Aussage
# grep acl /etc/mke2fs.conf
default_mntopts = acl,user_xattr
gesetzt.

Ich habe das nochmal nachgegraben ;-)
als default option 'default_mntopts = acl,user_xattr' wurde mit den
e2fsprogs 1.42 gesetzt und mit dem base update-1.8.1 vom 2012-02-18
verteilt.

Erklärt

# tune2fs -l /dev/sda3
Default mount options:    (none)
Filesystem created:       Sat Jan  7 13:29:33 2012

auf meinem Privateis und

# tune2fs -l /dev/sda3
Default mount options: user_xattr acl
Filesystem created: Wed Nov 7 12:01:47 2012

auf dem Schulserver.

[Thomas Bork]

Post by Marcus Röckrath
Nicht wirklich machbar Kernel bis zurück in das Jahr 2015 zu testen, denn
seit diesem Jahr ist nach Holgers Aussage
# grep acl /etc/mke2fs.conf
default_mntopts = acl,user_xattr
gesetzt.

In dieser Datei werden Optionen für das Erzeugen von Dateisystemen gesetzt.

Post by Marcus Röckrath

Post by Thomas Bork
a)
Es kommt auch darauf an, mit welcher Version von mkfs.FILESYSTEM das
Dateisystem erstellt wurde.

Bei der Erstellung wurde wohl nicht mit acl,xattr als Deafult gearbeitet,
denn
# tune2fs -l /dev/sda3
tune2fs 1.45.5 (07-Jan-2020)
Filesystem features: has_journal ext_attr resize_inode dir_index
filetype needs_recovery sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem created: Sat Jan 7 13:29:33 2012
Ein Zugriff und Setzen von ACLs mit setfacl/getfacl ist fehlerfrei möglich.
Nach dem Remount in mountfs auch nicht anders zu erwarten.

Ok.

Post by Marcus Röckrath
Nun habe ich genau diesen Remount aus mountfs entfernt und rebootet, aber
auch danach stand acl zur Verfügung, also ein auslesen und Setzen mit
getfacl/setacl funktioniert.
Ergo: Kann das System acl, wird beim Mount defaultmäßig mit acl gemountet,
es spielt also keine Rolle, mit welchen Optionen an dieser Stelle das
Dateisystem erstellt wurde.

Das finde ich merkwürdig - aber wenn Du es getestet hast...
Hoffentlich funktioniert das wirklich mit allen Kerneln, die unter base
2.8.25 noch installiert sein könnten.

Post by Marcus Röckrath

Post by Thomas Bork
c)
Es kommt auch darauf an, was dabei in /etc/mke2fs.conf stand.

Scheinbar nicht, es kommt eher darauf an, was jetzt da drin steht.

Warum sollte eine Datei, in der Optionen für das Erstellen von
Dateisystemen stehen, die aktuellen Mount-Optionen beeinflussen?

Post by Marcus Röckrath

Post by Thomas Bork
d)
Es kommt auch darauf an, ob die Standard-Mount-Optionen mittels tune2fs
manipuliert wurden.

IMHO genausowenig, wie mein Test zeigt.
Kann das System acl, dann wird es auch automatisch bei uns seit 2015
aktiviert, wenn man das nicht in der fstab explizit mit noacl abschaltet.

Ok, wir werden sehen.

[Marcus Röckrath]

Hallo Thomas,

Post by Thomas Bork

Post by Marcus Röckrath

Post by Thomas Bork
c)
Es kommt auch darauf an, was dabei in /etc/mke2fs.conf stand.

Scheinbar nicht, es kommt eher darauf an, was jetzt da drin steht.

Warum sollte eine Datei, in der Optionen für das Erstellen von
Dateisystemen stehen, die aktuellen Mount-Optionen beeinflussen?

# grep acl /etc/mke2fs.conf
default_mntopts = acl,user_xattr

Die Option heißt nicht default_mkfsopt sondern default_mntopts.

Ich denke, damit ist wirklich gemeint, dass hier die Defaults für den Mount
festgelegt werden.

Ich bin auf https://wiki.ubuntuusers.de/ACL/ gestoßen. Meine Beobachtungen
finden sich da auch im Abschnitt "Aktivieren im Dateisystem".

Die Einstellung im Dateisystem sind nur der "letzte" Notnagel, wenn es
ansonsten keine Vorgaben gibt.

Die Vorgaben können in der fstab oder seit einiger Zeit durch den Default
gegeben sein. Nur wenn also hier nichts festgelegt sit, kommt die
Einstellung im Dateisystem zum Zuge.

[Thomas Bork]

Post by Marcus Röckrath
# grep acl /etc/mke2fs.conf
default_mntopts = acl,user_xattr
Die Option heißt nicht default_mkfsopt sondern default_mntopts.

Weil das die Option ist, die dem Dateisystem bei Formatieren mitgegeben
wird, die per tune2fs ausgegeben und per tune2fs manipuliert werden kann
(Default mount options).

Mount liest /etc/mke2fs.conf nicht. Mount sieht aber sehr wohl auf die
Optionen, die dem Dateisystem bei Erstellung mitgegeben wurden.

Und wenn wir schon bei "heißen" sind:
Die Konfigurationsdatei heisst mke2fs.conf und nicht mount.conf.

[Hilix]

Das ist Kernel-abhängig. Habt Ihr das mit allen für eisfair möglichen Kernel-Versionen, die unter dieser base laufen könnten,
für die angegebenen Dateisysteme ext2,ext3,ext4,xfs überprüft?

...auch für meinen E1-Server kann ich das bestätigen, wenn ich den fraglichen Block in mountfs kommentiere.
Das Zielverzeichnis, das mit -bind,ro gemountet wurde, ist read-only (gecheckt mit touch)
das Qell-Verzeichnis ist rw (gecheckt mit touch)
...auch mit weiteren Mount-Attributen getestet.

Gruß. / Hilmar.

[ System: Host: hirodc Kernel: 4.9.220-eisfair-1-SMP i586 bits: 32
Console: tty 0 Distro: eisfair-1
CPU: Single core Transmeta Crusoe TM5500 (-UP-) cache: 256 KB
speed: 665 MHz (max)
Base: 2.8.25
File system sda3 on / type ext3
]

[Marcus Röckrath]

Hallo Taxena,

Post by Marcus Röckrath
Weil deine Mounts für Floppy und CDRom, aus welchem Grund auch immer,
nicht in /media liegen, sind die Devices bei der Umschreibung wegen udev
(UUID-Einträge) verloren gegangen.

ich war mal /mnt-Fan oder mochte das media-auto-hokuspokus nicht.

Hat sich aber schon seit langem so allgemein durchgesetzt.

[Taxena Gasparov]

Hallo Marcus,

...

Dankeschön.

[Hilix]

Hallo Taxi,

ich kann Dein Problem nachvollziehen

Was ich gemacht habe, ist:

- ein Verzeichnis /srv/tmp zu erstellen
- und in fstab einzufügen:
/tmp /srv/tmp ext4 bind,ro 0 0

nach einem Reboot kann nicht mehr auf Root-Verzeichnisse geschrieben werden, da sie offensichtlich read-only sind.

Das ist insofern eigenartig, als ein Bind-Mount nicht die Eigenschaften des Verzeichnisses/Gerätes in der ersten fstab-Spalte

Note that a read-only bind will create a read-only mountpoint (VFS entry),
but the original filesystem superblock will still be writable, meaning that
the olddir will be writable, but the newdir will be read-only.

Das stimmt, solange man den Bind-Mount-Befehl auf der Kommando-Zeile ausführt und auch wenn man das entsprechende Init-Script
/etc/init.d/mountfs am direkt in der Shell startet. Wenn man mit dem obigen Eintrag in der fstab ein Reboot macht, erhält man
eine Reihe Read-Only Meldungen:

--------------------------------------------
...
/srv/tmp : successfully mounted
EXT4-fs (sda3): re-mounted. Opts: errors=remount-ro,acl,user_xattr
EXT4-fs (sda3): re-mounted. Opts: acl,user_xattr
/var/install/config.d/environment.sh: line 26: /etc/wgetrc: Read-only file system
* Activating all swap files/partitions...
swapon: /swapfile: swapon failed: Read-only file system
* Setting up hostname ...
/etc/rc2.d/S09hostname: line 23: /etc/hosts: Read-only file system
* Setting console mode to Unicode (UTF-8)...
/usr/sbin/zic: Can't remove /usr/share/zoneinfo//etc/localtime: Read-only file system
* Loading ide cdrom drivers ...
* Configuring loopback and ethernet device ...
* Starting usb ...
* Configuring ip on ethernet cards ...
* Setting up additional routes ...
* Setting up resolv.conf ...
/etc/rc2.d/S35resolv: line 23: /etc/resolv.conf: Read-only file system
cp: cannot create regular file '/etc/resolv.conf.dhcpc': Read-only file system
* Starting dhcpc ...
- deleting routers
* Starting syslogd ...
syslogd: /var/log/messages: Read-only file system
syslogd: /var/log/log.eis-install: Read-only file system
* Starting klogd ...
* Starting haveged ...
...
--------------------------------------------

Man kann sich einloggen, aber die Root-Partition sda3 ist ganz definitiv ro gemountet!
Das darf aber gem. der mount Man-Page nicht sein.

Btw.: Ich habe die analoge Prozedur unter einem aktuellen Debian 10 nachvollzogen. Dort tritt dieses Phänomen mit der ro-/ nicht
auf! "/srv/tmp" ist rw gemountet.

Workaraound.

Wenn man den zum fstab-Eintrag entsprechenden Mount-Befehl stattdessen in das "local"-Initscript einträgt läuft alles wie
erwartet. Keine ro Root! Das würde bedeuten, dass man das Problem ggf. zunächst im mountfs-Initscript suchen müsste.

Ich habe das btw. so gemacht:

------------------------------------------
. /etc/init.d/functions

case $1
in
start)
boot_mesg " * Changing system font to Tamsyn10x20r"
/usr/bin/setfont /usr/share/kbd/consolefonts/Tamsyn10x20r
boot_mesg " * Mount with _bind_"
mount -o bind,ro /tmp /srv/tmp <===========
;;
stop)
;;
esac
-------------------------------------------------

Viele Grüße. / Hilmar.

[Holger Bruenjes]

Hallo Hilmar

Post by Hilix
Workaraound.
Wenn man den zum fstab-Eintrag entsprechenden Mount-Befehl stattdessen in das "local"-Initscript einträgt läuft alles wie
erwartet. Keine ro Root! Das würde bedeuten, dass man das Problem ggf. zunächst im mountfs-Initscript suchen müsste.

das hatte ich ja schon geschrieben, dass der remount Bereich
kommentiert werden soll

Post by Hilix
------------------------------------------
. /etc/init.d/functions
case $1
in
start)
boot_mesg " * Changing system font to Tamsyn10x20r"
/usr/bin/setfont /usr/share/kbd/consolefonts/Tamsyn10x20r

das ist obsolet, geht ganz normal ueber die locales config ;-)

Holger

[Hilix]

Hallo Holger>> boot_mesg " * Changing system font to Tamsyn10x20r"

Post by Holger Bruenjes

Post by Hilix
/usr/bin/setfont /usr/share/kbd/consolefonts/Tamsyn10x20r

das ist obsolet, geht ganz normal ueber die locales config ;-)

...so geht's aber auch. :-)
Gruß./Hilmar.

[Marcus Röckrath]

Hallo Hilmar,

Post by Hilix
Man kann sich einloggen, aber die Root-Partition sda3 ist ganz definitiv
ro gemountet! Das darf aber gem. der mount Man-Page nicht sein.
Btw.: Ich habe die analoge Prozedur unter einem aktuellen Debian 10
nachvollzogen. Dort tritt dieses Phänomen mit der ro-/ nicht auf!
"/srv/tmp" ist rw gemountet.

Ist doch längst geklärt, wieso das passiert.

In mountfs werden die die Mounts nochmal remountet, um acl zu aktivieren,
was inzwischen überflüssig ist, da acl default ist.

Aus der Ausgabe von mount werden dabei die mounts anhand des
Dateisystemtypes identifiziert, die remountet werden sollen.

Daber wird nun das Rootdevice doppelt erwischt und weil der bind-Mount auch
in der ersten Spalte der mount-Ausgabe sich als Device /dev/sda3 zu
erkennen gibt, wird schlussendlich /dev/sda3 ro remountet.

also:

Im Remount-Abschnitt wird /dev/sda3 zunächst rw und dann nochmal ro
remountet.

IMHO muss der gane remount-Block raus, da wegen acl als Standard sowieso
überflüssig.

[Hilix]

Hallo Marcus,

Post by Marcus Röckrath
Ist doch längst geklärt, wieso das passiert.

sorry, für meinen überflüssigen Beitrag..
Grüße. / Hilmar.

[Holger Bruenjes]

Hallo Hilmar

Post by Hilix
sorry, für meinen überflüssigen Beitrag..

Du koenntest mir sagen, ob das kommentieren zu dem gewuenschten
Erfolg gefuehrt hat

Danke

Holger

[Hilix]

Hallo Holger,

Post by Holger Bruenjes
Du koenntest mir sagen, ob das kommentieren zu dem gewuenschten
Erfolg gefuehrt hat

Ich kann Dir nur sagen, dass mein Workaround offensichtlich funktioniert.

Bei dem, was Marcus ausgeführt hat, dachte ich, Ihr hättet das schon ausprobiert?
mountfs ist doch Devs-Sache. :)

[aber "kommentieren" funktioniert, soweit ich das feststellen konnte. Ich kann aber nichts über mögliche side-effects sagen...]
Ob's wirklich funktioniert, sollte besser Taxi bestätigen.

Grüße./Hilmar.

[Taxena Gasparov]

Hallo Hilmar,

Post by Hilix
ich kann Dein Problem nachvollziehen

Dankeschön!

Post by Hilix
--------------------------------------------
...
/srv/tmp                 : successfully mounted
EXT4-fs (sda3): re-mounted. Opts: errors=remount-ro,acl,user_xattr
EXT4-fs (sda3): re-mounted. Opts: acl,user_xattr
/var/install/config.d/environment.sh: line 26: /etc/wgetrc: Read-only file system
 * Activating all swap files/partitions...
swapon: /swapfile: swapon failed: Read-only file system
 * Setting up hostname ...
/etc/rc2.d/S09hostname: line 23: /etc/hosts: Read-only file system
 * Setting console mode to Unicode (UTF-8)...
/usr/sbin/zic: Can't remove /usr/share/zoneinfo//etc/localtime: Read-only file system
 * Loading ide cdrom drivers ...
 * Configuring loopback and ethernet device ...
 * Starting usb ...
 * Configuring ip on ethernet cards ...
 * Setting up additional routes ...
 * Setting up resolv.conf ...
/etc/rc2.d/S35resolv: line 23: /etc/resolv.conf: Read-only file system
cp: cannot create regular file '/etc/resolv.conf.dhcpc': Read-only file system
 * Starting dhcpc ...
   - deleting routers
 * Starting syslogd ...
  syslogd: /var/log/messages: Read-only file system
  syslogd: /var/log/log.eis-install: Read-only file system
 * Starting klogd ...
 * Starting haveged ...
...
--------------------------------------------

wie kommst du an diese Zeilen (ohne Fotografieren und Abtippen:-)?

Dank
Taxi

[Hilix]

Hallo Taxi,

Post by Taxena Gasparov
wie kommst du an diese Zeilen (ohne Fotografieren und Abtippen:-)?

- "gpm" auf Server installieren und aktivieren
- Mit Maus die Textzeilen auf Bildschirm selektieren
- mit vim oder nano eine (neue) Textdatei öffnen und
- den selektieren Bildschirm-Text in die neue Datei pasten (mittlere Maustaste/Scrollrad klicken).
(bei vim natürlich vorher <I>).

Geht halt nur bei (sichtbarem) Bildschirmtext; ggf. kann man mit <Shift><Bild^^^> nach oben scrollen und weiteren Text davor
selektieren und in den Pastebuffer cutten.

Vielleicht kennt jemand noch eine elegantere Methode. Aber diese funktioniert unter Eisfair gut.

Gruß. / Hilmar,

[Marcus Röckrath]

Hallo Hilmar,

Post by Hilix

Post by Taxena Gasparov
wie kommst du an diese Zeilen (ohne Fotografieren und Abtippen:-)?

- "gpm" auf Server installieren und aktivieren
- Mit Maus die Textzeilen auf Bildschirm selektieren
- mit vim oder nano eine (neue) Textdatei öffnen und
- den selektieren Bildschirm-Text in die neue Datei pasten (mittlere
Maustaste/Scrollrad klicken).
(bei vim natürlich vorher <I>).
Geht halt nur bei (sichtbarem) Bildschirmtext; ggf. kann man mit
<Shift><Bild^^^> nach oben scrollen und weiteren Text davor selektieren
und in den Pastebuffer cutten.
Vielleicht kennt jemand noch eine elegantere Methode. Aber diese
funktioniert unter Eisfair gut.

Direkt auf dem eis ist das so gut machbar. Entsprechend geht es auch, wenn
man von enem anderen Rechner per ssh-Sitzung Text aus der Konsole kopiert.

[Taxena Gasparov]

Post by Marcus Röckrath
Direkt auf dem eis ist das so gut machbar. Entsprechend geht es auch, wenn
man von enem anderen Rechner per ssh-Sitzung Text aus der Konsole kopiert.

beim mounten der Dateisysteme ist der ssh-Dienst noch nicht aktiv, ansonsten mache ich das natürlich oft so.

[Taxena Gasparov]

Post by Hilix
- "gpm" auf Server installieren und aktivieren
- Mit Maus die Textzeilen auf Bildschirm selektieren
- mit vim oder nano eine (neue) Textdatei öffnen und
- den selektieren Bildschirm-Text in die neue Datei pasten (mittlere Maustaste/Scrollrad klicken).
  (bei vim natürlich vorher <I>).
Geht halt nur bei (sichtbarem) Bildschirmtext; ggf. kann man mit <Shift><Bild^^^> nach oben scrollen und
weiteren Text davor selektieren und in den Pastebuffer cutten.

hm, das heißt gpm läuft schon beim mounten der Dateisysteme? Kann ich mir gerade nicht vorstellen, dazu
müsste es ja in der initrd liegen oder im kernel, oder nicht?

[Marcus Röckrath]

Hallo Taxena,

Post by Taxena Gasparov
hm, das heißt gpm läuft schon beim mounten der Dateisysteme? Kann ich mir
gerade nicht vorstellen, dazu müsste es ja in der initrd liegen oder im
kernel, oder nicht?

Der gpm startet erst danach, allerdings ist / auch schon vor mountfs ro
gemountet und es werden vor mountfs auch schon Module geladen, die nicht in
der initrd stecken.

Ob der gpm vorziehbar wäre, wäre die Frage, denn er wird vermutlich auf ein
rw-Dateisystem angewiesen sein.

[Hilix]

Post by Taxena Gasparov

Post by Hilix
Geht halt nur bei (sichtbarem) Bildschirmtext;

hm, das heißt gpm läuft schon beim mounten der Dateisysteme?

?? (S07mountfs ... S63gpm)
Ich arbeite meist direkt an der Konsole (virtuell via Virt-Manager oder physisch), da bekommt man mehr mit, vor allem beim Hoch-
und Runterfahren (wie in Deinem Fall). Bei Remote via ssh (z.B.) sieht man da nur den Login-prompt und man muss in die
entsprechenden Logs bzw. dmesg schauen, was ja grundsätzlich keine schlechte Idee ist :-) .
Gruß./Hilmar.

[Taxena Gasparov]

Post by Taxena Gasparov
hm, das heißt gpm läuft schon beim mounten der Dateisysteme?

??  (S07mountfs ... S63gpm)

eher nicht.
Wie hast du dann die Bildschirmausgabe in den gestrigen Post um 15Uhr20 gebracht?

Ich arbeite meist direkt an der Konsole (virtuell via Virt-Manager oder physisch),

Ich hier nur physisch.

da bekommt man mehr mit,
vor allem beim Hoch- und Runterfahren (wie in Deinem Fall). Bei Remote via ssh (z.B.) sieht man da nur den
Login-prompt und man muss in die entsprechenden Logs bzw. dmesg schauen, was ja grundsätzlich keine
schlechte Idee ist :-) .

hat dmesg alle Bootbildschirmausgaben?
Konkret: das Wort "successfully" kann ich in meiner dmesg-Ausgabe nicht finden.
Welches logfile enthält die exakte Bildschirmausgabe?

Dank
Taxi

[Hilix]

Post by Taxena Gasparov

Post by Taxena Gasparov
hm, das heißt gpm läuft schon beim mounten der Dateisysteme?

??  (S07mountfs ... S63gpm)

eher nicht.

?

Post by Taxena Gasparov
Wie hast du dann die Bildschirmausgabe in den gestrigen Post um 15Uhr20 gebracht?

Das habe ich doch ausführlich beschrieben: gpm->vim Datei->in BootPart.(rw)->später scp Datei->Sys mit Mail
Gruß./Hilmar.

[Taxena Gasparov]

Post by Hilix

Post by Taxena Gasparov

Post by Taxena Gasparov
hm, das heißt gpm läuft schon beim mounten der Dateisysteme?

??  (S07mountfs ... S63gpm)

eher nicht.

?

mountfs mit S07 wird sehr weit vor gpm mit S63 gestartet, also geht's damit eher nicht, oder doch?

Post by Hilix

Post by Taxena Gasparov
Wie hast du dann die Bildschirmausgabe in den gestrigen Post um 15Uhr20 gebracht?

Das habe ich doch ausführlich beschrieben: gpm->vim Datei->in BootPart.(rw)->später scp Datei->Sys mit Mail

gpm ist der Knackpunkt. vim und Rest ist mir klar.
Aber ist bei dir tatsächlich gpm aktiv vor S07?

Gruß
Taxi

[Hilix]

Post by Taxena Gasparov
mountfs mit S07 wird sehr weit vor gpm mit S63 gestartet, also geht's damit eher nicht, oder doch?

Post by Hilix

Post by Taxena Gasparov
Wie hast du dann die Bildschirmausgabe in den gestrigen Post um 15Uhr20 gebracht?

Das habe ich doch ausführlich beschrieben: gpm->vim Datei->in BootPart.(rw)->später scp Datei->Sys mit Mail

gpm ist der Knackpunkt. vim und Rest ist mir klar.
Aber ist bei dir tatsächlich gpm aktiv vor S07?

Wir reden wahrscheinlich aneinander vorbei? Probiers doch einfach mal aus. :-)
(Ich rede von der Bildschirmausgabe! beim Booten.)
Gruß. / Hilmar.

[Marcus Röckrath]

Hallo Hilmar,

Post by Hilix

Post by Taxena Gasparov
gpm ist der Knackpunkt. vim und Rest ist mir klar.
Aber ist bei dir tatsächlich gpm aktiv vor S07?

Wir reden wahrscheinlich aneinander vorbei? Probiers doch einfach mal aus.
:-) (Ich rede von der Bildschirmausgabe! beim Booten.)

Klar, aber sitzt du physisch vor der Kiste und greifst die dort sofort ab?

Wenn man nach vollendetem Boot noch so weit zurückscrollen kann, ist dann
auch der gpm geladen, aber im Moment des Erscheinens der Mountmeldungen,
ist es gpm doch noch nicht.

[Hilix]

Post by Marcus Röckrath
Klar, aber sitzt du physisch vor der Kiste und greifst die dort sofort ab?
Wenn man nach vollendetem Boot noch so weit zurückscrollen kann, ist dann
auch der gpm geladen, aber im Moment des Erscheinens der Mountmeldungen,
ist es gpm doch noch nicht.

Hallo Marcus, ich wundere mich jetzt doch etwas...

Ich sitze an einem nativ installierten Eis an der Konsole oder verbinde mit einer Eis-VM via Virt-Manager mit der Konsole dieser
VM. "gpm" ist installiert und aktiviert. Nach einem Reboot des Eis erscheint der Login Prompt. Ich logge mich als root ein.
Wenn ich dann die Maus bewege erscheint der Mauszeiger auf dem Textbildschirm als Block. Damit selektiere ich die Boot-Msgs.
(Text) auf dem Bildschirm, die ich oberhalb des "login:" Prompts sehe mit der Maus öffne am Shell-Prompt mit einem Text-Editor
eine (neue) Textdatei und paste mit der mittleren Maustaste/rad den selektierten Text in die Datei und speichere dieselbe.

In dem speziellen Mount-Bind-Test, bei dem die Root-Partition "ro" war, habe ich die Datei nach /boot gespeichert, da die
Boot-Partition "rw" war.

Wieviel Du von diesen Bootmeldungen oberhalb des login: erreichen kannst, hängt von der Größe des Bildschirms und ggf. der
Auflösung bzw. Schriftgröße zusammen. (Die Schriftgröße an der Konsole kann man mit der "vga =" Option in der lilo.conf
einstellen. (z.B. bei meinem 24"er: vga = 0x391)

Wenn Du (remote) mit ssh auf die Kiste gehst, siehst Du keine Bootmeldungen, so wie an der Konsole. Da muss man halt in
/var/log/messages, relevante Log-Files oder in dmesg Output schauen, um etwas über Meldungen bei Boot oder Shutdown zu sehen.
Wenn das entfernte Eis-/odersonstwaslinux-System als VM auf einem entfernten Virtualisierungshost läuft, erreiche ich übers
Netzwerk via Virt-Manager (libvirt, ssh) auch die Konsole der entfernten VM.

Zu "gpm": Ich habe die Vermutung, dass Taxi meint, gpm würde die Boot-Meldungen in eine Datei speichern, die man dann auslesen
kann. Das habe ich aber nie behauptet.

Das ist also alles keine Hexerei. Ich hoffe, ich habe mich jetzt etwas verständlicher ausgedrückt. :-)

Grüße. / Hilmar.

[Marcus Röckrath]

Hallo Hilmar,

Post by Hilix
Wieviel Du von diesen Bootmeldungen oberhalb des login: erreichen kannst,
hängt von der Größe des Bildschirms und ggf. der Auflösung bzw.
Schriftgröße zusammen. (Die Schriftgröße an der Konsole kann man mit der
"vga =" Option in der lilo.conf einstellen. (z.B. bei meinem 24"er: vga =
0x391)

Wieso sollte die Menge des zurückscrollbaren Inhalts von der Schriftgröße
abhängen?

Da steckt ein Puffer von festgelegter Größe dahinter, der als Textkonsole
eine bestimmte Menge an Zeichen vorhalten kann.

Post by Hilix
Wenn Du (remote) mit ssh auf die Kiste gehst, siehst Du keine
Bootmeldungen, so wie an der Konsole. Da muss man halt in
/var/log/messages, relevante Log-Files oder in dmesg Output schauen,

Klar, aber es gibt Bootinfos, die man dort auch nicht finden wird und in der
Regel auch nicht braucht.

Post by Hilix
Das ist also alles keine Hexerei. Ich hoffe, ich habe mich jetzt etwas
verständlicher ausgedrückt. :-)

Natürlich nicht, man kommt irgendwie immer an alles ran.

[Hilix]

Post by Marcus Röckrath
Wieso sollte die Menge des zurückscrollbaren Inhalts von der Schriftgröße
abhängen?

Mist, er merkt aber auch alles! (Ok, fast alles) :-)
Ich meinte natürlich die "Auflösung"
Grüße./Hilmar.

[Marcus Röckrath]

Hallo Hilmar,

Post by Hilix

Post by Marcus Röckrath
Wieso sollte die Menge des zurückscrollbaren Inhalts von der Schriftgröße
abhängen?

Mist, er merkt aber auch alles! (Ok, fast alles) :-)

Ich sag nur: Lehrer

Post by Hilix
Ich meinte natürlich die "Auflösung"

Hähhhhh?

Die Puffergröße in Zeichen hat doch mit der Auflösung auch nichts zu tun.

[Taxena Gasparov]

Hallo,

nach heutigen Updates bootet der Server mit "/" read-only und als Konsequenz sind die zuvor in Vollfunktion
arbeitenden Dienste nun in Nicht- oder Teilfunktion, d.h. selbige Problematik wie vor knapp einem Jahr.

Post by Taxena Gasparov
Hat sich in den letzten 12 Monaten etwas geändert bezüglich mount?

hat sich in den letzten Wochen etwas geändert bezüglich /etc/init.d/mountfs?

Taxi

[Marcus Röckrath]

Hallo Taxena,

Post by Taxena Gasparov
nach heutigen Updates bootet der Server mit "/" read-only und als
Konsequenz sind die zuvor in Vollfunktion arbeitenden Dienste nun in
Nicht- oder Teilfunktion, d.h. selbige Problematik wie vor knapp einem
Jahr.

Da war was mit mount binds in der fstab und dem rw-remounting; wie haben wir
damals das Problem gelöst?

Post by Taxena Gasparov
hat sich in den letzten Wochen etwas geändert bezüglich
/etc/init.d/mountfs?

Laut Backups (verfügbar bis Anfang Februar) sehe ich keine Änderung.

[Taxena Gasparov]

Hallo Marcus,

Post by Marcus Röckrath
Da war was mit mount binds in der fstab und dem rw-remounting;

nicht rw, ro-remounting durch bind-mount der fstab wirkte sich auf das "nichtbind"/echte Dateisystem aus.

Post by Marcus Röckrath
wie haben wir damals das Problem gelöst?

Den acl-Block (ca. Zeile 100) kommentieren. Dieser war nicht mehr kommentiert. Nach Kommentierung, bootet
der Server wieder.

Post by Marcus Röckrath

Post by Taxena Gasparov
hat sich in den letzten Wochen etwas geändert bezüglich
/etc/init.d/mountfs?

Laut Backups (verfügbar bis Anfang Februar) sehe ich keine Änderung.

der Zeitstempel zeigte 3.4.2021 an, aber weshalb außer den Updates die Kommentarzeichenlöschung in der
mountfs stattgefunden haben sollte, kommt mir nichts in den Sinn.

Taxi

[Marcus Röckrath]

Hallo Taxena,

Post by Taxena Gasparov

Post by Marcus Röckrath
wie haben wir damals das Problem gelöst?

Den acl-Block (ca. Zeile 100) kommentieren. Dieser war nicht mehr
kommentiert. Nach Kommentierung, bootet der Server wieder.

Post by Marcus Röckrath

Post by Taxena Gasparov
hat sich in den letzten Wochen etwas geändert bezüglich
/etc/init.d/mountfs?

Laut Backups (verfügbar bis Anfang Februar) sehe ich keine Änderung.

der Zeitstempel zeigte 3.4.2021 an, aber weshalb außer den Updates die
Kommentarzeichenlöschung in der mountfs stattgefunden haben sollte, kommt
mir nichts in den Sinn.

Die mountfs ist im Februar aus dem base-Paket in das eisfair-base-Paket
gewandert (ohne Codeänderung).

Das hat somit ddeine manuelle Änderung überschrieben.

[Taxena Gasparov]

Post by Marcus Röckrath
Die mountfs ist im Februar aus dem base-Paket in das eisfair-base-Paket
gewandert (ohne Codeänderung).
Das hat somit ddeine manuelle Änderung überschrieben.

wieso wurde dieser unnötige acl-remount-Codeblock nicht gelöscht?

[Marcus Röckrath]

Hallo Taxena,

Post by Taxena Gasparov

Post by Marcus Röckrath
Die mountfs ist im Februar aus dem base-Paket in das eisfair-base-Paket
gewandert (ohne Codeänderung).
Das hat somit ddeine manuelle Änderung überschrieben.

wieso wurde dieser unnötige acl-remount-Codeblock nicht gelöscht?

Weil es - Thomas hat sich damals so geäußert - in Altinstallationen acl noch
nicht Standard bei der Formatierung war.

[Taxena Gasparov]

Hallo Marcus,

Post by Marcus Röckrath
Weil es - Thomas hat sich damals so geäußert - in Altinstallationen acl noch
nicht Standard bei der Formatierung war.

wieso wurde dieser Codeblock nicht angepasst, damit bind-Einträge der fstab nicht mehr remountet werden?

Vor 2020 war die fstab-Konstellation problemlos.

Laut mount-manpage-Abschnitt ...

Post by Marcus Röckrath
Since util-linux 2.31, mount ignores the bind flag from /etc/fstab on a remount operation (if "-o remount" is specified on command line).
This is necessary to fully control mount options on remount by command line. In previous versions the bind flag has been always applied
and it was impossible to re-define mount options without interaction with the bind semantic. This mount(8) behavior does not affect situa‐
tions when "remount,bind" is specified in the /etc/fstab file.

... ist diese Änderung ursächlich.

Gemäß letztem Satz: Ist diese "remount,bind"-Alternative eine Lösung für das Problem?
Falls nein, fällt mir nur ein, alle bind-fstab-mount-Einträge nach dem acl-remount-Block stattfinden zu lassen.
Oder ist eisfair nun nicht mehr benutzbar mit fstab-mount-bind-Einträgen?

Taxi

[Marcus Röckrath]

Hallo Taxena,

Post by Taxena Gasparov
Laut mount-manpage-Abschnitt ...

Post by Marcus Röckrath
Since util-linux 2.31, mount ignores the bind flag from
/etc/fstab on a remount operation (if "-o remount" is specified on
command line).
This is necessary to fully control mount options on remount by
command line. In previous versions the bind flag has been always
applied and it was impossible to re-define mount options without
interaction with the bind semantic. This mount(8) behavior does
not affect situa‐ tions when "remount,bind" is specified in the
/etc/fstab file.

... ist diese Änderung ursächlich.
Gemäß letztem Satz: Ist diese "remount,bind"-Alternative eine Lösung für das Problem?

Hast du es mal probiert, ich bin mir über die wirklichen Konsequenzen des
letzten Satzes nicht sicher, tendiere aber zu nein.

Post by Taxena Gasparov
Falls nein, fällt mir nur ein, alle bind-fstab-mount-Einträge
nach dem acl-remount-Block stattfinden zu lassen.

Falls diese Mounts nicht für zwischenzeitlich gestartete Dienste notwendig
sind, könnten sie in boot.local erledigt werden.

Post by Taxena Gasparov
Oder ist eisfair nun
nicht mehr benutzbar mit fstab-mount-bind-Einträgen?

Das Problem sind nur ro-bind-Mounts.

[Holger Bruenjes]

Hallo Taxi

Post by Taxena Gasparov

Post by Marcus Röckrath
Weil es - Thomas hat sich damals so geäußert - in Altinstallationen acl noch
nicht Standard bei der Formatierung war.

wieso wurde dieser Codeblock nicht angepasst, damit bind-Einträge der fstab nicht mehr remountet werden?

Ich ahbe dir eine Aenderung geschickt, probier es bitte aus.

Danke

Holger