19 Jun
2017
19 Jun
'17
10:57 a.m.
Ja wieder richtig was los auf der Liste ;)
Da versuche ich auch eine Frage loszuwerden.
Möchte das rootfilesystem ro mounten. Aber auch wenn ich als bootarg übergebe:
Kernel command line: console=ttyPS0,115200 earlyprintk root=/dev/mmcblk0p1 ro
rootfstype=ext4 rootwait
passiert folgendes:
[ 1.494744] Waiting for root device /dev/mmcblk0p1...
[ 1.506415] mmc0: new high speed MMC card at address 0001
[ 1.512259] mmcblk0: mmc0:0001 Q1J54A 1.82 GiB
[ 1.516921] mmcblk0boot0: mmc0:0001 Q1J54A partition 1 2.00 MiB
[ 1.533021] mmcblk0boot1: mmc0:0001 Q1J54A partition 2 2.00 MiB
[ 1.549074] mmcblk0rpmb: mmc0:0001 Q1J54A partition 3 512 KiB
[ 1.556238] mmcblk0: p1 p2 p3
[ 1.602972] EXT4-fs (mmcblk0p1): INFO: recovery required on readonly filesystem
[ 1.610198] EXT4-fs (mmcblk0p1): write access will be enabled during recovery
[ 1.680390] EXT4-fs (mmcblk0p1): recovery complete
[ 1.686907] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts:
(null)
[ 1.694956] VFS: Mounted root (ext4 filesystem) readonly on device 179:1.
....
[ 2.559526] EXT4-fs (mmcblk0p1): re-mounted. Opts: data=ordered
und dann
mount gibt:
/dev/root on / type ext4 (rw,relatime,data=ordered)
....
die Zeile in fstab hab ich auskommentiert.
#/dev/root / auto defaults 1 1
Daher zwei Fragen:
Woher kommt bei 1.6 der Wunsch nach dem Recovery? Ist das normal, kann/soll man das
unterdrücken?
Ist immerhin nur ein emmc mit entsprechend beschränkten Schreibzyklen.
Und woher wird dann bei 2.6 dieser erneute Mount, der dann auch noch rw ist?
In /etc/rc5.d/... sehe ich auch nichts das darauf deutet ....
Viele Grüße
Arno
19 Jun
19 Jun
11:45 a.m.
On Mon, Jun 19, 2017 at 10:57:57AM +0200, Arno Steffens wrote:
Ja wieder richtig was los auf der Liste ;)
Da versuche ich auch eine Frage loszuwerden.
Möchte das rootfilesystem ro mounten. Aber auch wenn ich als bootarg übergebe:
Kernel command line: console=ttyPS0,115200 earlyprintk root=/dev/mmcblk0p1 ro
rootfstype=ext4 rootwait
passiert folgendes:
[ 1.494744] Waiting for root device /dev/mmcblk0p1...
[ 1.506415] mmc0: new high speed MMC card at address 0001
[ 1.512259] mmcblk0: mmc0:0001 Q1J54A 1.82 GiB
[ 1.516921] mmcblk0boot0: mmc0:0001 Q1J54A partition 1 2.00 MiB
[ 1.533021] mmcblk0boot1: mmc0:0001 Q1J54A partition 2 2.00 MiB
[ 1.549074] mmcblk0rpmb: mmc0:0001 Q1J54A partition 3 512 KiB
[ 1.556238] mmcblk0: p1 p2 p3
[ 1.602972] EXT4-fs (mmcblk0p1): INFO: recovery required on readonly filesystem
[ 1.610198] EXT4-fs (mmcblk0p1): write access will be enabled during recovery
[ 1.680390] EXT4-fs (mmcblk0p1): recovery complete
[ 1.686907] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts:
(null)
[ 1.694956] VFS: Mounted root (ext4 filesystem) readonly on device 179:1.
....
[ 2.559526] EXT4-fs (mmcblk0p1): re-mounted. Opts: data=ordered
und dann
mount gibt:
/dev/root on / type ext4 (rw,relatime,data=ordered)
....
die Zeile in fstab hab ich auskommentiert.
#/dev/root / auto defaults 1 1
Daher zwei Fragen:
Woher kommt bei 1.6 der Wunsch nach dem Recovery? Ist das normal, kann/soll man das
unterdrücken?
Wo kommt das Dateisystem her? Der Kernel-Code sieht so aus:
if (EXT4_HAS_INCOMPAT_FEATURE(sb, EXT4_FEATURE_INCOMPAT_RECOVER)) {
if (sb->s_flags & MS_RDONLY) {
ext4_msg(sb, KERN_INFO, "INFO: recovery "
"required on readonly filesystem");
if (really_read_only) {
ext4_msg(sb, KERN_ERR, "write access "
"unavailable, cannot proceed");
return -EROFS;
}
ext4_msg(sb, KERN_INFO, "write access will "
"be enabled during recovery");
}
}
Da steht also was im Superblock, was "bitte repariere mich" bedeutet.
Passiert das bei jedem Boot, oder nur beim ersten?
Ist immerhin nur ein emmc mit entsprechend
beschränkten Schreibzyklen.
Und woher wird dann bei 2.6 dieser erneute Mount, der dann auch noch rw ist?
In /etc/rc5.d/... sehe ich auch nichts das darauf deutet ....
Das ist ohne weitere Details nicht beantwortbar. Was ist denn der Kontext, in
dem das passiert? Einen üblichen Verdächtigen kenne ich an der Stelle nicht.
Bau' doch mal ein dump_stack an der Stelle im Kernel ein, die diese Meldung
ausgibt.
Liebe Grüße
Uwe
2:09 p.m.
Hallo Uwe,
Es bleibt aber dabei, dass einmal gemountet und dann nochmal wird.
Der erste Mount wird noch von den Kernel-bootparams gesteuert. Der zweite ist komisch.
Das mit den DumpStacks kenne ich noch nicht.
Ist das so richtig?
- Kernel neu kompilieren mit Kernel debugging, Verbose kernel error messages,
und dann an den Sources wo gemounted wird (diese Ausgaben kommen) einen Aufruf
dump_stack() rein?
Bin nicht ganz so fingerfertig .... ;)
Gesendet: Montag, 19. Juni 2017 um 11:45 Uhr
Von: "Uwe Kleine-König" <uwe(a)kleine-koenig.org>
An: "Arno Steffens" <epsi(a)gmx.de>
Cc: flug(a)lug-freiburg.de
Betreff: Re: [Flug] kernel boot param, mounten ...
On Mon, Jun 19, 2017 at 10:57:57AM +0200, Arno Steffens wrote:
Da haben mich meine Versuche in die Irre geführt. Tatsächlich war das wohl eher eine
Ausnahme, das ein Recovery kommt.
Ja wieder richtig was los auf der Liste ;)
Da versuche ich auch eine Frage loszuwerden.
Möchte das rootfilesystem ro mounten. Aber auch wenn ich als bootarg übergebe:
Kernel command line: console=ttyPS0,115200 earlyprintk root=/dev/mmcblk0p1 ro
rootfstype=ext4 rootwait
passiert folgendes:
[ 1.494744] Waiting for root device /dev/mmcblk0p1...
[ 1.506415] mmc0: new high speed MMC card at address 0001
[ 1.512259] mmcblk0: mmc0:0001 Q1J54A 1.82 GiB
[ 1.516921] mmcblk0boot0: mmc0:0001 Q1J54A partition 1 2.00 MiB
[ 1.533021] mmcblk0boot1: mmc0:0001 Q1J54A partition 2 2.00 MiB
[ 1.549074] mmcblk0rpmb: mmc0:0001 Q1J54A partition 3 512 KiB
[ 1.556238] mmcblk0: p1 p2 p3
[ 1.602972] EXT4-fs (mmcblk0p1): INFO: recovery required on readonly filesystem
[ 1.610198] EXT4-fs (mmcblk0p1): write access will be enabled during recovery
[ 1.680390] EXT4-fs (mmcblk0p1): recovery complete
[ 1.686907] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts:
(null)
[ 1.694956] VFS: Mounted root (ext4 filesystem) readonly on device 179:1.
....
[ 2.559526] EXT4-fs (mmcblk0p1): re-mounted. Opts: data=ordered
und dann
mount gibt:
/dev/root on / type ext4 (rw,relatime,data=ordered)
....
die Zeile in fstab hab ich auskommentiert.
#/dev/root / auto defaults 1 1
Daher zwei Fragen:
Woher kommt bei 1.6 der Wunsch nach dem Recovery? Ist das normal, kann/soll man das
unterdrücken?
Wo kommt das Dateisystem her? Der Kernel-Code sieht so aus:
if (EXT4_HAS_INCOMPAT_FEATURE(sb, EXT4_FEATURE_INCOMPAT_RECOVER)) {
if (sb->s_flags & MS_RDONLY) {
ext4_msg(sb, KERN_INFO, "INFO: recovery "
"required on readonly filesystem");
if (really_read_only) {
ext4_msg(sb, KERN_ERR, "write access "
"unavailable, cannot proceed");
return -EROFS;
}
ext4_msg(sb, KERN_INFO, "write access will "
"be enabled during recovery");
}
}
Da steht also was im Superblock, was "bitte repariere mich" bedeutet.
Passiert das bei jedem Boot, oder nur beim ersten? Ist immerhin nur ein emmc mit entsprechend
beschränkten Schreibzyklen.
Und woher wird dann bei 2.6 dieser erneute Mount, der dann auch noch rw ist?
In /etc/rc5.d/... sehe ich auch nichts das darauf deutet ....
Das ist ohne weitere Details nicht beantwortbar. Was ist denn der Kontext, in
dem das passiert? Einen üblichen Verdächtigen kenne ich an der Stelle nicht.
Bau' doch mal ein dump_stack an der Stelle im Kernel ein, die diese Meldung
ausgibt.
Liebe Grüße
Uwe
Danke und Grüße zurück
Arno
2:45 p.m.
Hallo Arno,
On 06/19/2017 02:09 PM, Arno Steffens wrote:
Es bleibt aber dabei, dass einmal gemountet und dann
nochmal wird.
Der erste Mount wird noch von den Kernel-bootparams gesteuert. Der zweite ist komisch.
Das mit den DumpStacks kenne ich noch nicht.
Ist das so richtig?
- Kernel neu kompilieren mit Kernel debugging, Verbose kernel error messages,
und dann an den Sources wo gemounted wird (diese Ausgaben kommen) einen Aufruf
dump_stack() rein?
Bin nicht ganz so fingerfertig .... ;)
erst Sourcen ändern und dann kompilieren :-) Debuginfo und verbose
brauchst Du für diese Methode nicht. Ansonsten hast Du das schon richtig
verstanden.
Uwe
3:33 p.m.
Gesendet: Montag, 19. Juni 2017 um 14:45 Uhr
Von: "Uwe Kleine-König" <uwe(a)kleine-koenig.org>
An: "Arno Steffens" <epsi(a)gmx.de>
Cc: flug(a)lug-freiburg.de
Betreff: Re: [Flug] kernel boot param, mounten ...
Hallo Arno,
On 06/19/2017 02:09 PM, Arno Steffens wrote:
So, der erste mount sieht so aus
[ 1.514877] Waiting for root device /dev/mmcblk0p1...
[ 1.526368] mmc0: new high speed MMC card at address 0001
[ 1.532245] mmcblk0: mmc0:0001 Q1J54A 1.82 GiB
[ 1.536905] mmcblk0boot0: mmc0:0001 Q1J54A partition 1 2.00 MiB
[ 1.542987] mmcblk0boot1: mmc0:0001 Q1J54A partition 2 2.00 MiB
[ 1.559033] mmcblk0rpmb: mmc0:0001 Q1J54A partition 3 512 KiB
[ 1.565928] mmcblk0: p1 p2 p3
[ 1.626160] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts:
(null)
[ 1.634221] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W
4.6.0-xilinx-v2016.3 #4
[ 1.642500] Hardware name: Xilinx Zynq Platform
[ 1.647042] [<c010e758>] (unwind_backtrace) from [<c010b058>]
(show_stack+0x10/0x14)
[ 1.654749] [<c010b058>] (show_stack) from [<c031a760>]
(dump_stack+0x7c/0x90)
[ 1.661959] [<c031a760>] (dump_stack) from [<c026f730>]
(ext4_fill_super+0x2d50/0x316c)
[ 1.669941] [<c026f730>] (ext4_fill_super) from [<c01f3610>]
(mount_bdev+0x15c/0x188)
[ 1.677749] [<c01f3610>] (mount_bdev) from [<c0269140>]
(ext4_mount+0x18/0x20)
[ 1.684952] [<c0269140>] (ext4_mount) from [<c01f4254>]
(mount_fs+0x14/0xa4)
[ 1.691987] [<c01f4254>] (mount_fs) from [<c020d628>]
(vfs_kern_mount+0x48/0xf0)
[ 1.699364] [<c020d628>] (vfs_kern_mount) from [<c0210458>]
(do_mount+0x1a8/0xc24)
[ 1.706913] [<c0210458>] (do_mount) from [<c0211250>]
(SyS_mount+0x8c/0xb4)
[ 1.713860] [<c0211250>] (SyS_mount) from [<c0801160>]
(mount_block_root+0x108/0x268)
[ 1.721669] [<c0801160>] (mount_block_root) from [<c08014cc>]
(mount_root+0x120/0x128)
[ 1.729566] [<c08014cc>] (mount_root) from [<c0801650>]
(prepare_namespace+0x17c/0x1c4)
[ 1.737552] [<c0801650>] (prepare_namespace) from [<c0800e30>]
(kernel_init_freeable+0x1d4/0x1e4)
[ 1.746410] [<c0800e30>] (kernel_init_freeable) from [<c05ba2e0>]
(kernel_init+0x8/0x114)
[ 1.754568] [<c05ba2e0>] (kernel_init) from [<c0107638>]
(ret_from_fork+0x14/0x3c)
[ 1.762138] #####################
[ 1.765439] VFS: Mounted root (ext4 filesystem) readonly on device 179:1.
der zweite, von dem ich nicht weiß woher dann:
[ 2.194325] udevd[727]: starting eudev-3.2
[ 2.315902] EXT4-fs (mmcblk0p1): re-mounted. Opts: data=ordered
[ 2.322559] ----------------
[ 2.325360] CPU: 1 PID: 755 Comm: mount Tainted: G W 4.6.0-xilinx-v2016.3
#4
[ 2.333513] Hardware name: Xilinx Zynq Platform
[ 2.338058] [<c010e758>] (unwind_backtrace) from [<c010b058>]
(show_stack+0x10/0x14)
[ 2.345774] [<c010b058>] (show_stack) from [<c031a760>]
(dump_stack+0x7c/0x90)
[ 2.352985] [<c031a760>] (dump_stack) from [<c026c3a4>]
(ext4_remount+0x48c/0x530)
[ 2.360521] [<c026c3a4>] (ext4_remount) from [<c01f3e80>]
(do_remount_sb+0x64/0x1d4)
[ 2.368246] [<c01f3e80>] (do_remount_sb) from [<c02108c0>]
(do_mount+0x610/0xc24)
[ 2.375706] [<c02108c0>] (do_mount) from [<c0211250>]
(SyS_mount+0x8c/0xb4)
[ 2.382652] [<c0211250>] (SyS_mount) from [<c0107580>]
(ret_fast_syscall+0x0/0x3c)
[ 2.390388] ----------------
Fehlt noch was um dahinter zu kommen, schätze ich. Also was sich hinter
(do_remount_sb) from [<c02108c0>] verbirgt.
Gruß
Arno
Es bleibt aber dabei, dass einmal gemountet und
dann nochmal wird.
Der erste Mount wird noch von den Kernel-bootparams gesteuert. Der zweite ist komisch.
Das mit den DumpStacks kenne ich noch nicht.
Ist das so richtig?
- Kernel neu kompilieren mit Kernel debugging, Verbose kernel error messages,
und dann an den Sources wo gemounted wird (diese Ausgaben kommen) einen Aufruf
dump_stack() rein?
Bin nicht ganz so fingerfertig .... ;)
erst Sourcen ändern und dann kompilieren :-) Debuginfo und verbose
brauchst Du für diese Methode nicht. Ansonsten hast Du das schon richtig
verstanden.
Uwe
9:29 p.m.
On 06/19/2017 03:33 PM, Arno Steffens wrote:
Wenig überraschendes. Dass das W-Taint-Flag gesetzt ist, ist vermutlich
irrelevant hier. Und oh, ein Vendor-Gammel-Kernel, der nicht mal die
Stable-Updates enthält.
Gesendet: Montag, 19. Juni 2017 um 14:45 Uhr
Von: "Uwe Kleine-König" <uwe(a)kleine-koenig.org>
An: "Arno Steffens" <epsi(a)gmx.de>
Cc: flug(a)lug-freiburg.de
Betreff: Re: [Flug] kernel boot param, mounten ...
Hallo Arno,
On 06/19/2017 02:09 PM, Arno Steffens wrote:
So, der erste mount sieht so aus
[ 1.514877] Waiting for root device /dev/mmcblk0p1...
[ 1.526368] mmc0: new high speed MMC card at address 0001
[ 1.532245] mmcblk0: mmc0:0001 Q1J54A 1.82 GiB
[ 1.536905] mmcblk0boot0: mmc0:0001 Q1J54A partition 1 2.00 MiB
[ 1.542987] mmcblk0boot1: mmc0:0001 Q1J54A partition 2 2.00 MiB
[ 1.559033] mmcblk0rpmb: mmc0:0001 Q1J54A partition 3 512 KiB
[ 1.565928] mmcblk0: p1 p2 p3
[ 1.626160] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts:
(null)
[ 1.634221] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W
4.6.0-xilinx-v2016.3 #4
[ 1.642500] Hardware name: Xilinx Zynq Platform
[ 1.647042] [<c010e758>] (unwind_backtrace) from [<c010b058>]
(show_stack+0x10/0x14)
[ 1.654749] [<c010b058>] (show_stack) from [<c031a760>]
(dump_stack+0x7c/0x90)
[ 1.661959] [<c031a760>] (dump_stack) from [<c026f730>]
(ext4_fill_super+0x2d50/0x316c)
[ 1.669941] [<c026f730>] (ext4_fill_super) from [<c01f3610>]
(mount_bdev+0x15c/0x188)
[ 1.677749] [<c01f3610>] (mount_bdev) from [<c0269140>]
(ext4_mount+0x18/0x20)
[ 1.684952] [<c0269140>] (ext4_mount) from [<c01f4254>]
(mount_fs+0x14/0xa4)
[ 1.691987] [<c01f4254>] (mount_fs) from [<c020d628>]
(vfs_kern_mount+0x48/0xf0)
[ 1.699364] [<c020d628>] (vfs_kern_mount) from [<c0210458>]
(do_mount+0x1a8/0xc24)
[ 1.706913] [<c0210458>] (do_mount) from [<c0211250>]
(SyS_mount+0x8c/0xb4)
[ 1.713860] [<c0211250>] (SyS_mount) from [<c0801160>]
(mount_block_root+0x108/0x268)
[ 1.721669] [<c0801160>] (mount_block_root) from [<c08014cc>]
(mount_root+0x120/0x128)
[ 1.729566] [<c08014cc>] (mount_root) from [<c0801650>]
(prepare_namespace+0x17c/0x1c4)
[ 1.737552] [<c0801650>] (prepare_namespace) from [<c0800e30>]
(kernel_init_freeable+0x1d4/0x1e4)
[ 1.746410] [<c0800e30>] (kernel_init_freeable) from [<c05ba2e0>]
(kernel_init+0x8/0x114)
[ 1.754568] [<c05ba2e0>] (kernel_init) from [<c0107638>]
(ret_from_fork+0x14/0x3c)
[ 1.762138] #####################
[ 1.765439] VFS: Mounted root (ext4 filesystem) readonly on device 179:1. Es bleibt aber dabei, dass einmal gemountet und
dann nochmal wird.
Der erste Mount wird noch von den Kernel-bootparams gesteuert. Der zweite ist komisch.
Das mit den DumpStacks kenne ich noch nicht.
Ist das so richtig?
- Kernel neu kompilieren mit Kernel debugging, Verbose kernel error messages,
und dann an den Sources wo gemounted wird (diese Ausgaben kommen) einen Aufruf
dump_stack() rein?
Bin nicht ganz so fingerfertig .... ;)
erst Sourcen ändern und dann kompilieren :-) Debuginfo und verbose
brauchst Du für diese Methode nicht. Ansonsten hast Du das schon richtig
verstanden.
Uwe
der zweite, von dem ich nicht weiß woher dann:
[ 2.194325] udevd[727]: starting eudev-3.2
[ 2.315902] EXT4-fs (mmcblk0p1): re-mounted. Opts: data=ordered
[ 2.322559] ----------------
[ 2.325360] CPU: 1 PID: 755 Comm: mount Tainted: G W 4.6.0-xilinx-v2016.3
#4
[ 2.333513] Hardware name: Xilinx Zynq Platform
[ 2.338058] [<c010e758>] (unwind_backtrace) from [<c010b058>]
(show_stack+0x10/0x14)
[ 2.345774] [<c010b058>] (show_stack) from [<c031a760>]
(dump_stack+0x7c/0x90)
[ 2.352985] [<c031a760>] (dump_stack) from [<c026c3a4>]
(ext4_remount+0x48c/0x530)
[ 2.360521] [<c026c3a4>] (ext4_remount) from [<c01f3e80>]
(do_remount_sb+0x64/0x1d4)
[ 2.368246] [<c01f3e80>] (do_remount_sb) from [<c02108c0>]
(do_mount+0x610/0xc24)
[ 2.375706] [<c02108c0>] (do_mount) from [<c0211250>]
(SyS_mount+0x8c/0xb4)
[ 2.382652] [<c0211250>] (SyS_mount) from [<c0107580>]
(ret_fast_syscall+0x0/0x3c)
[ 2.390388] ----------------
Fehlt noch was um dahinter zu kommen, schätze ich. Also was sich hinter
(do_remount_sb) from [<c02108c0>] verbirgt.
Nö, da steht alles drin, was interessant ist. Der Schlüssel ist
Comm: mount
d.h. die Änderung kommt vom Programm mount, das den mount(2)-syscall
(SyS_mount) aufruft. Such nochmal nach einem Aufruf von
mount -o remount
(nicht unbedingt direkt in dieser Reihenfolge) in Deinen Init-Skripten.
Liebe Grüße
Uwe
20 Jun
20 Jun
9:20 a.m.
Gesendet: Montag, 19. Juni 2017 um 21:29 Uhr
Von: "Uwe Kleine-König" <uwe(a)kleine-koenig.org>
An: "Arno Steffens" <epsi(a)gmx.de>
Cc: flug(a)lug-freiburg.de
Betreff: Re: Aw: Re: [Flug] kernel boot param, mounten ...
On 06/19/2017 03:33 PM, Arno Steffens wrote:
Wenig überraschendes. Dass das W-Taint-Flag gesetzt ist, ist vermutlich
irrelevant hier. Und oh, ein Vendor-Gammel-Kernel, der nicht mal die
Stable-Updates enthält.
Hab mir auch vorgenommen, eher einen Vanilla Kernel zu nehmen und das nötige
einzupatchen.
Aber immer eins nach dem anderen... ;)
Gesendet: Montag, 19. Juni 2017 um 14:45 Uhr
Von: "Uwe Kleine-König" <uwe(a)kleine-koenig.org>
An: "Arno Steffens" <epsi(a)gmx.de>
Cc: flug(a)lug-freiburg.de
Betreff: Re: [Flug] kernel boot param, mounten ...
Hallo Arno,
On 06/19/2017 02:09 PM, Arno Steffens wrote:
So, der erste mount sieht so aus
[ 1.514877] Waiting for root device /dev/mmcblk0p1...
[ 1.526368] mmc0: new high speed MMC card at address 0001
[ 1.532245] mmcblk0: mmc0:0001 Q1J54A 1.82 GiB
[ 1.536905] mmcblk0boot0: mmc0:0001 Q1J54A partition 1 2.00 MiB
[ 1.542987] mmcblk0boot1: mmc0:0001 Q1J54A partition 2 2.00 MiB
[ 1.559033] mmcblk0rpmb: mmc0:0001 Q1J54A partition 3 512 KiB
[ 1.565928] mmcblk0: p1 p2 p3
[ 1.626160] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts:
(null)
[ 1.634221] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W
4.6.0-xilinx-v2016.3 #4
[ 1.642500] Hardware name: Xilinx Zynq Platform
[ 1.647042] [<c010e758>] (unwind_backtrace) from [<c010b058>]
(show_stack+0x10/0x14)
[ 1.654749] [<c010b058>] (show_stack) from [<c031a760>]
(dump_stack+0x7c/0x90)
[ 1.661959] [<c031a760>] (dump_stack) from [<c026f730>]
(ext4_fill_super+0x2d50/0x316c)
[ 1.669941] [<c026f730>] (ext4_fill_super) from [<c01f3610>]
(mount_bdev+0x15c/0x188)
[ 1.677749] [<c01f3610>] (mount_bdev) from [<c0269140>]
(ext4_mount+0x18/0x20)
[ 1.684952] [<c0269140>] (ext4_mount) from [<c01f4254>]
(mount_fs+0x14/0xa4)
[ 1.691987] [<c01f4254>] (mount_fs) from [<c020d628>]
(vfs_kern_mount+0x48/0xf0)
[ 1.699364] [<c020d628>] (vfs_kern_mount) from [<c0210458>]
(do_mount+0x1a8/0xc24)
[ 1.706913] [<c0210458>] (do_mount) from [<c0211250>]
(SyS_mount+0x8c/0xb4)
[ 1.713860] [<c0211250>] (SyS_mount) from [<c0801160>]
(mount_block_root+0x108/0x268)
[ 1.721669] [<c0801160>] (mount_block_root) from [<c08014cc>]
(mount_root+0x120/0x128)
[ 1.729566] [<c08014cc>] (mount_root) from [<c0801650>]
(prepare_namespace+0x17c/0x1c4)
[ 1.737552] [<c0801650>] (prepare_namespace) from [<c0800e30>]
(kernel_init_freeable+0x1d4/0x1e4)
[ 1.746410] [<c0800e30>] (kernel_init_freeable) from [<c05ba2e0>]
(kernel_init+0x8/0x114)
[ 1.754568] [<c05ba2e0>] (kernel_init) from [<c0107638>]
(ret_from_fork+0x14/0x3c)
[ 1.762138] #####################
[ 1.765439] VFS: Mounted root (ext4 filesystem) readonly on device 179:1. Es bleibt aber dabei, dass einmal gemountet und
dann nochmal wird.
Der erste Mount wird noch von den Kernel-bootparams gesteuert. Der zweite ist komisch.
Das mit den DumpStacks kenne ich noch nicht.
Ist das so richtig?
- Kernel neu kompilieren mit Kernel debugging, Verbose kernel error messages,
und dann an den Sources wo gemounted wird (diese Ausgaben kommen) einen Aufruf
dump_stack() rein?
Bin nicht ganz so fingerfertig .... ;)
erst Sourcen ändern und dann kompilieren :-) Debuginfo und verbose
brauchst Du für diese Methode nicht. Ansonsten hast Du das schon richtig
verstanden.
Uwe
der zweite, von dem ich nicht weiß woher dann:
[ 2.194325] udevd[727]: starting eudev-3.2
[ 2.315902] EXT4-fs (mmcblk0p1): re-mounted. Opts: data=ordered
[ 2.322559] ----------------
[ 2.325360] CPU: 1 PID: 755 Comm: mount Tainted: G W 4.6.0-xilinx-v2016.3
#4
[ 2.333513] Hardware name: Xilinx Zynq Platform
[ 2.338058] [<c010e758>] (unwind_backtrace) from [<c010b058>]
(show_stack+0x10/0x14)
[ 2.345774] [<c010b058>] (show_stack) from [<c031a760>]
(dump_stack+0x7c/0x90)
[ 2.352985] [<c031a760>] (dump_stack) from [<c026c3a4>]
(ext4_remount+0x48c/0x530)
[ 2.360521] [<c026c3a4>] (ext4_remount) from [<c01f3e80>]
(do_remount_sb+0x64/0x1d4)
[ 2.368246] [<c01f3e80>] (do_remount_sb) from [<c02108c0>]
(do_mount+0x610/0xc24)
[ 2.375706] [<c02108c0>] (do_mount) from [<c0211250>]
(SyS_mount+0x8c/0xb4)
[ 2.382652] [<c0211250>] (SyS_mount) from [<c0107580>]
(ret_fast_syscall+0x0/0x3c)
[ 2.390388] ----------------
Fehlt noch was um dahinter zu kommen, schätze ich. Also was sich hinter
(do_remount_sb) from [<c02108c0>] verbirgt.
Nö, da steht alles drin, was interessant ist. Der Schlüssel ist
Comm: mount
d.h. die Änderung kommt vom Programm mount, das den mount(2)-syscall
(SyS_mount) aufruft. Such nochmal nach einem Aufruf von
mount -o remount
(nicht unbedingt direkt in dieser Reihenfolge) in Deinen Init-Skripten.
Liebe Grüße
Uwe
9:38 a.m.
Hallo Arno,
Die Praxis zeigt, dass oft alles was halbwegs läuft, dann dem
Zeitmanagement zum Opfer fällt und es in ein Release schafft.
Meines Erachtens nach ist es wenig sinnvoll auf einen Vendor-Kernel zu
setzen, wenn es mainline halbwegs vernünftige Unterstützung gibt. Die
Vendor-Kernel, die ich kenne, enthalten so viel nicht nachvollziehbare
Änderungen, dass von "Vendor funktioniert" auf "Mainline
funktioniert"
nur wenig einfacher ist, als von "Nichts" auf "Mainline funktioniert"
zu
kommen. Die Differenz ist kleiner als der Aufwand, den Vendor-Kernel ans
fliegen zu kriegen. OK, das setzt voraus, dass man schon firm in
Kernel-Entwicklung ist, weil man ohne den Vendor-Kernel auch den
(vermutlich bereits bezahlten) Support des Vendors nicht in Anspruch
nehmen kann. Ich empfehle hier #armlinux und die linux-arm-kernel ML, da
kriegt man in der Regel bei gut gestellten Fragen auch Hilfe.
Liebe Grüße
Uwe
Wenig
überraschendes. Dass das W-Taint-Flag gesetzt ist, ist vermutlich
irrelevant hier. Und oh, ein Vendor-Gammel-Kernel, der nicht mal die
Stable-Updates enthält.
Hab mir auch vorgenommen, eher einen Vanilla Kernel zu nehmen und das nötige
einzupatchen.
Aber immer eins nach dem anderen... ;) 
12 Jul
12 Jul
10:37 a.m.
Hallo Arno,
ich weiß nicht ob du noch suchst und ich weiß auch nicht genau was du vor
hast. Ich hatte letztens aber die Anforderung ein System gegen dauerhafte
Veränderung abzusichern und habe daher mit aufs ein RW tmpfs Layer über das
RO Root gelegt und reboote das System regelmäßig.
Daran habe ich mich orientiert:
https://www.logicsupply.com/explore/io-hub/how-to-build-a-read-only-linux-s…
Die Kommentare darunter sind auch lesenswert, dort gibts
Verbesserungsvorschläge.
Grüße Patrick
Am 20. Juni 2017 um 09:38 schrieb Uwe Kleine-König <uwe(a)kleine-koenig.org>rg>:
Hallo Arno,
nötige
einzupatchen.
Wenig
überraschendes. Dass das W-Taint-Flag gesetzt ist, ist vermutlich
irrelevant hier. Und oh, ein Vendor-Gammel-Kernel, der nicht mal die
Stable-Updates enthält.
Hab mir auch vorgenommen, eher einen Vanilla Kernel zu nehmen und das Aber immer eins nach dem anderen... ;)
Die Praxis zeigt, dass oft alles was halbwegs läuft, dann dem
Zeitmanagement zum Opfer fällt und es in ein Release schafft.
Meines Erachtens nach ist es wenig sinnvoll auf einen Vendor-Kernel zu
setzen, wenn es mainline halbwegs vernünftige Unterstützung gibt. Die
Vendor-Kernel, die ich kenne, enthalten so viel nicht nachvollziehbare
Änderungen, dass von "Vendor funktioniert" auf "Mainline
funktioniert"
nur wenig einfacher ist, als von "Nichts" auf "Mainline funktioniert"
zu
kommen. Die Differenz ist kleiner als der Aufwand, den Vendor-Kernel ans
fliegen zu kriegen. OK, das setzt voraus, dass man schon firm in
Kernel-Entwicklung ist, weil man ohne den Vendor-Kernel auch den
(vermutlich bereits bezahlten) Support des Vendors nicht in Anspruch
nehmen kann. Ich empfehle hier #armlinux und die linux-arm-kernel ML, da
kriegt man in der Regel bei gut gestellten Fragen auch Hilfe.
Liebe Grüße
Uwe
_______________________________________________
Freiburger Linux User Group
Mail an die Liste: flug(a)lug-freiburg.de
Mailingliste verwalten (u.a. abbestellen): https://lug-freiburg.de/
mailman/listinfo/flug
2480
days inactive
2503
days old
8 comments
3 participants
participants (3)
-
Arno Steffens -
Patrick Banholzer -
Uwe Kleine-König