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
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
Hallo Uwe,
Gesendet: Montag, 19. Juni 2017 um 11:45 Uhr Von: "Uwe Kleine-König" uwe@kleine-koenig.org An: "Arno Steffens" epsi@gmx.de Cc: flug@lug-freiburg.de Betreff: Re: [Flug] kernel boot param, mounten ...
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?
Da haben mich meine Versuche in die Irre geführt. Tatsächlich war das wohl eher eine Ausnahme, das ein Recovery kommt.
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.
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 .... ;)
Liebe Grüße Uwe
Danke und Grüße zurück Arno
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
Gesendet: Montag, 19. Juni 2017 um 14:45 Uhr Von: "Uwe Kleine-König" uwe@kleine-koenig.org An: "Arno Steffens" epsi@gmx.de Cc: flug@lug-freiburg.de Betreff: Re: [Flug] kernel boot param, mounten ...
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
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
On 06/19/2017 03:33 PM, Arno Steffens wrote:
Gesendet: Montag, 19. Juni 2017 um 14:45 Uhr Von: "Uwe Kleine-König" uwe@kleine-koenig.org An: "Arno Steffens" epsi@gmx.de Cc: flug@lug-freiburg.de Betreff: Re: [Flug] kernel boot param, mounten ...
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
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.
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.
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
Gesendet: Montag, 19. Juni 2017 um 21:29 Uhr Von: "Uwe Kleine-König" uwe@kleine-koenig.org An: "Arno Steffens" epsi@gmx.de Cc: flug@lug-freiburg.de Betreff: Re: Aw: Re: [Flug] kernel boot param, mounten ...
On 06/19/2017 03:33 PM, Arno Steffens wrote:
Gesendet: Montag, 19. Juni 2017 um 14:45 Uhr Von: "Uwe Kleine-König" uwe@kleine-koenig.org An: "Arno Steffens" epsi@gmx.de Cc: flug@lug-freiburg.de Betreff: Re: [Flug] kernel boot param, mounten ...
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
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.
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... ;)
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.
Lesen heist halt nicht verstehen ;) Tatsächlich hab ich ein /etc/init.d/checkroot.sh gefunden.
Ganz am Ende :
# # If the root filesystem was not marked as read-only in /etc/fstab, # remount the rootfs rw but do not try to change mtab because it # is on a ro fs until the remount succeeded. Then clean up old mtabs # and finally write the new mtab. # mount -n -o remount,$rootmode / if test "$rootmode" = rw then ln -sf /proc/mounts /dev/mtab fi
Da könnte man ja ne Abfrage machen, ob der Kernel nicht schon im $rootmode gemounted ist, oder? Aber ich habs grad mit time geprüft, das geht praktisch in Null-Zeit:
real 0m 0.01s user 0m 0.00s sys 0m 0.00s
Also kann man lassen. Dachte ich kann etwas Zeit sparen beim booten. War eine relative große Zeitlücke im log dort. Aber daran lag es wohl nicht.
Danke Uwe, wieder was gelernt. Gruß Arno
Liebe Grüße Uwe
Hallo Arno,
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... ;)
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
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-sy... 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@kleine-koenig.org:
Hallo Arno,
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... ;)
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@lug-freiburg.de Mailingliste verwalten (u.a. abbestellen): https://lug-freiburg.de/ mailman/listinfo/flug
-
Arno Steffens -
Patrick Banholzer -
Uwe Kleine-König