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