Re: [LEDE-DEV] early printk breaks kernel on the clearfog board
Am Dienstag, 25. April 2017, 02:08:48 CEST schrieb Syrone Wong: > try `make kernel_menuconfig` and select the corresponding one. Thats how it has to be done now. However I claim that the new one should be the default, and teh right way is to have people using old bootloaders do the hard way. However it is really not that simple: switching between CONFIG_DEBUG_MVEBU_UART0 and CONFIG_DEBUG_MVEBU_UART0_ALTERNATE does *not* switch CONFIG_DEBUG_UART_PHYS!!! If course nothing can be done to fix this kernel-side. Thats why I am asking what would be the proper way to deal with this from a higher level (Lede menuconfig). Quoting kernel menuconfig: DEBUG_MVEBU_UART0_ALTERNATE: "This option should be used with the new bootloaders that remap the internal registers at 0xf100. If the wrong DEBUG_MVEBU_UART* option is selected, when u-boot hands over to the kernel, the system silently crashes, with no serial output at all." DEBUG_MVEBU_UART0: "This option should be used with the old bootloaders ... " "This option will not work on older Marvell platforms (Kirkwood, Dove, MV78xx0, Orion5x), which should pick the "new bootloader" variant." It seems to be that "new"should be the default, and applicable to most, and all new platforms. Better not put bricks into peoples paths when they are starting out on new stuff. Of course one way would be to make a Lede menuconfig for this. br Josua Mayer > > > Best Regards, > Syrone Wong > > On Mon, Apr 24, 2017 at 11:18 PM, Josua Mayer <josua.ma...@jm0.eu> wrote: > > Am Montag, 24. April 2017, 02:37:48 CEST schrieb Syrone Wong: > >> You may want to enable CONFIG_DEBUG_MVEBU_UART0_ALTERNATE > > > > Yes, this is the one. But it is not visible from the Lede menuconfig. The > > problem I was trying to point out is that in the kernel-config this is > > what > > should be selected when selecting early-printk in the Lede menuconfig. > > > >> or CONFIG_DEBUG_MVEBU_UART1_ALTERNATE if early printk is being enabled. > >> > >> > >> Best Regards, > >> Syrone Wong > >> > >> On Mon, Apr 24, 2017 at 3:39 AM, Josua Mayer <josua.maye...@gmail.com> > > > > wrote: > >> > Hi everybody, > >> > > >> > I noticed a serious problem with a Clearfog build that enables > >> > CONFIG_KERNEL_EARLY_PRINTK=y. > >> > In short: after Loading Kernel, the serial console stays completely > >> > silent, and apparently the board does *not* boot. > >> > > >> > This came as a serious surprise to me. > >> > Turns out the reason for this is the usage of the old uart physical > >> > address: CONFIG_DEBUG_UART_PHYS=0xd0012000 > >> > This is the default for if DEBUG_MVEBU_UART0 > >> > However the Clearfog Pro uses mainline u-boot, and requires: > >> > CONFIG_DEBUG_UART_PHYS=0xf1012000 > >> > > >> > Any opinions what should be done about this? > >> > I personally suggest to switch to what the kernel config calls "new > >> > bootloaders". > >> > After all this is quite the trap when somebody is so thoughtful to > >> > start > >> > with a debug build, only to find out that is the reason his builds > >> > don't > >> > boot. > >> > > >> > Imre Kaloz: you are the one who committed this setting with config-4.4, > >> > so I figured you may have some valuable insight here. > >> > > >> > br > >> > Josua Mayer > >> > > >> > > >> > ___ > >> > Lede-dev mailing list > >> > Lede-dev@lists.infradead.org > >> > http://lists.infradead.org/mailman/listinfo/lede-dev > > > > ___ > > Lede-dev mailing list > > Lede-dev@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/lede-dev > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] early printk breaks kernel on the clearfog board
Am Montag, 24. April 2017, 02:37:48 CEST schrieb Syrone Wong: > You may want to enable CONFIG_DEBUG_MVEBU_UART0_ALTERNATE Yes, this is the one. But it is not visible from the Lede menuconfig. The problem I was trying to point out is that in the kernel-config this is what should be selected when selecting early-printk in the Lede menuconfig. > or CONFIG_DEBUG_MVEBU_UART1_ALTERNATE if early printk is being enabled. > > > Best Regards, > Syrone Wong > > On Mon, Apr 24, 2017 at 3:39 AM, Josua Mayer <josua.maye...@gmail.com> wrote: > > Hi everybody, > > > > I noticed a serious problem with a Clearfog build that enables > > CONFIG_KERNEL_EARLY_PRINTK=y. > > In short: after Loading Kernel, the serial console stays completely > > silent, and apparently the board does *not* boot. > > > > This came as a serious surprise to me. > > Turns out the reason for this is the usage of the old uart physical > > address: CONFIG_DEBUG_UART_PHYS=0xd0012000 > > This is the default for if DEBUG_MVEBU_UART0 > > However the Clearfog Pro uses mainline u-boot, and requires: > > CONFIG_DEBUG_UART_PHYS=0xf1012000 > > > > Any opinions what should be done about this? > > I personally suggest to switch to what the kernel config calls "new > > bootloaders". > > After all this is quite the trap when somebody is so thoughtful to start > > with a debug build, only to find out that is the reason his builds don't > > boot. > > > > Imre Kaloz: you are the one who committed this setting with config-4.4, > > so I figured you may have some valuable insight here. > > > > br > > Josua Mayer > > > > > > ___ > > Lede-dev mailing list > > Lede-dev@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] early printk breaks kernel on the clearfog board
Hi everybody, I noticed a serious problem with a Clearfog build that enables CONFIG_KERNEL_EARLY_PRINTK=y. In short: after Loading Kernel, the serial console stays completely silent, and apparently the board does *not* boot. This came as a serious surprise to me. Turns out the reason for this is the usage of the old uart physical address: CONFIG_DEBUG_UART_PHYS=0xd0012000 This is the default for if DEBUG_MVEBU_UART0 However the Clearfog Pro uses mainline u-boot, and requires: CONFIG_DEBUG_UART_PHYS=0xf1012000 Any opinions what should be done about this? I personally suggest to switch to what the kernel config calls "new bootloaders". After all this is quite the trap when somebody is so thoughtful to start with a debug build, only to find out that is the reason his builds don't boot. Imre Kaloz: you are the one who committed this setting with config-4.4, so I figured you may have some valuable insight here. br Josua Mayer ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] stall/hang in netifd on LEDE r1318 on Linksys WRT1900AC V1
Hi Syrone, Pat, I ran into the same issue on the Clearfog Pro, and my colleague figured out a way to make it disappear. Please try out this patch and let me know if it helps on your boards: https://github.com/Artox/lede-project/commit/db724f8ff1ed4c77668f691ed4d066a8e0f2693e From db724f8ff1ed4c77668f691ed4d066a8e0f2693e Mon Sep 17 00:00:00 2001 From: Josua Mayer <josua.maye...@gmail.com> Date: Wed, 17 Aug 2016 16:42:07 +0200 Subject: [PATCH] mvebu: enable cpu hotplug support in kernel This option prevents the rcu stalls in mvneta on armada-38x. Signed-off-by: Josua Mayer <josua.maye...@gmail.com> --- target/linux/mvebu/config-4.4 | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/mvebu/config-4.4 b/target/linux/mvebu/config-4.4 index d0f042e..6c4ff70 100644 --- a/target/linux/mvebu/config-4.4 +++ b/target/linux/mvebu/config-4.4 @@ -209,6 +209,7 @@ CONFIG_HAVE_UID16=y CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y CONFIG_HIGHMEM=y # CONFIG_HIGHPTE is not set +CONFIG_HOTPLUG_CPU=y CONFIG_HWBM=y CONFIG_HWMON=y CONFIG_HZ_FIXED=0 -- 2.6.6 Am 15.08.2016 um 08:57 schrieb Syrone Wong: > I have the same issue. Everything works well on > https://github.com/lede-project/source/commit/22ef1c83b35cd5633b0c58c9c38a43494a906a6a, > boot hang when compiling > https://github.com/lede-project/source/commit/b9b665ae49469a73d254b1a219a4a7c4e22f27c0 > last night. > > I'm too lazy to attach TTL cable, then I revert to the older version. > > I hope my information help. > > Best Regards, > Syrone Wong > > > On Mon, Aug 15, 2016 at 2:27 PM, pat <p...@patfruth.com> wrote: >> Dear LEDE devs, >> >> There doesn’t appear to be an LEDE forum yet, else I’d post it on the forum. >> So I’m hoping someone on the mail list has a suggestion here. >> >> I’ve been running a build of OpenWRT DD R49195 since earlier this year. >> I thought I’d try to move to LEDE. >> >> To that end, I’ve just built an image based on LEDE r1318 for a Linksys >> WRT1900AC V1 (aka mamba). >> The build completed successfully, and the image appears to have flashed >> successfully. >> Upon booting, the boot process stalls/hangs. I see the following in a >> serial/tty console; >> >> . >> … >> …. >> [ 16.641909] device eth0 entered promiscuous mode >> [ 16.649345] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready >> [ 76.692269] INFO: rcu_sched self-detected stall on CPU >> [ 76.697461] 1-...: (6000 ticks this GP) idle=4b7/141/0 >> softirq=902/919 fqs=5980 >> [ 76.702321] INFO: rcu_sched detected stalls on CPUs/tasks: >> [ 76.702341] 1-...: (6000 ticks this GP) idle=4b7/141/0 >> softirq=902/919 fqs=5980 >> [ 76.702352] (detected by 0, t=6002 jiffies, g=111, c=110, q=990) >> [ 76.702356] Task dump for CPU 1: >> [ 76.702368] netifd R running 0 1106 1 0x0002 >> [ 76.702401] [] (__schedule) from [] >> (SyS_ioctl+0x34/0x5c) >> [ 76.702418] [] (SyS_ioctl) from [] >> (ret_fast_syscall+0x0/0x3c) >> [ 76.750523] (t=6006 jiffies g=111 c=110 q=990) >> [ 76.755178] Task dump for CPU 1: >> [ 76.758420] netifd R running 0 1106 1 0x0002 >> [ 76.764838] [] (unwind_backtrace) from [] >> (show_stack+0x10/0x14) >> [ 76.772617] [] (show_stack) from [] >> (rcu_dump_cpu_stacks+0x78/0xb0) >> [ 76.780648] [] (rcu_dump_cpu_stacks) from [] >> (rcu_check_callbacks+0x28c/0x754) >> [ 76.789637] [] (rcu_check_callbacks) from [] >> (update_process_times+0x38/0x64) >> [ 76.798543] [] (update_process_times) from [] >> (tick_sched_timer+0x21c/0x260) >> [ 76.807358] [] (tick_sched_timer) from [] >> (__hrtimer_run_queues+0xf8/0x1b8) >> [ 76.816084] [] (__hrtimer_run_queues) from [] >> (hrtimer_interrupt+0xac/0x200) >> [ 76.824898] [] (hrtimer_interrupt) from [] >> (armada_370_xp_timer_interrupt+0x30/0x38) >> [ 76.834407] [] (armada_370_xp_timer_interrupt) from >> [] (handle_percpu_devid_irq+0x6c/0x84) >> [ 76.87] [] (handle_percpu_devid_irq) from [] >> (generic_handle_irq+0x24/0x34) >> [ 76.853521] [] (generic_handle_irq) from [] >> (__handle_domain_irq+0x98/0xac) >> [ 76.862247] [] (__handle_domain_irq) from [] >> (armada_370_xp_handle_irq+0x50/0xb0) >> [ 76.871496] [] (armada_370_xp_handle_irq) from [] >> (__irq_svc+0x54/0x70) >> [ 76.879869] Exception stack(0xce1b5de8 to 0xce1b5e30) >> [ 76.884938] 5de0: cf83fca4 cf83eca4 >> c05c6614 cf83fca4 >> [ 76.893141] 5e00: cf83fc80 cf83f830 0
Re: [LEDE-DEV] fstools testing help
Am 13.08.2016 um 20:16 schrieb Daniel Dickinson: > On Tue, 2016-08-09 at 17:13 +0200, Josua Mayer wrote: >> Hi John, >> >> I have finally found the time to look into this, and managed to >> reproduce the segfault that Álvaro noticed. >> It is caused by a call to fclose(0x0); This is very unexpected, >> shouldn't the C library check for NULL and return quietly? > > C generally doesn't do any prevent shooting yourself in the foot type > checks for things related to memory/fd/handle management. Part of the > reason is fast and small is that it leaves most things up to the > programmer. I've head RUST is supposed to be a new thing that might be > small and fast but safer, but that's just what I'm told, I haven't > looked into it, and don't really know anything about it. I did some research, and apparently fclose(0) is undefined. To each C library its own behaviour. Luckily that call is now properly prevented! > > Regards, > > Daniel > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] mount_root skipped on initramfs builds
Hi everyone, During my work on supporting a block-device as overlay partition, without using extroot I came across this phenomenon: When booting my mvebu-based board with an initramfs, mount_root was not executed. This seems unusual to me, I certainly expected the init process to be exactly the same. So I traced the cause to line 15 in the 80_mount_root preinit script. It says: [ "$INITRAMFS" = "1" ] || boot_hook_add preinit_main do_mount_root Very clearly, this behaviour is intentional. Would anyone be willing to shed some light on why this is? Can it be removed? And if not: What is stopping us? John I added you in CC because it is your commit that added the initramfs-check: https://git.lede-project.org/?p=source.git;a=blobdiff;f=package/base-files/files/lib/preinit/80_mount_root;h=9a99ee91097129205e7cee966ce4bf2ecd0d7c72;hp=ad24fb8ace70707e434c9980d948399834ce160f;hb=f43b7934d2850c2f545736253a0f8cbe4915fdff;hpb=1360067c4a75cd1804710e6f25871f695d3271b2 br Josua Mayer ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] fstools testing help
Hi John, Am 08.07.2016 um 07:47 schrieb John Crispin: > > On 07/07/2016 21:36, Josua Mayer wrote: >> Hi John, >> >> Could you please point me at where you merged my 2 patches? I want to >> ensure I am testing the same code that was causing segfaults. >> >> br >> Josua Mayer >> > > I already dropped them. : >_< > > John > Well short story: given following setup: mmclko0p1: fat32 (zImage, dtb) mmcblk0p2: ext4 (rootfs) bootargs root=/dev/mmcblk0p2 ro no segfaults when running mount_root no memleaks reported by valgrind Any ideas what might be going wrong? >> Am 05.07.2016 um 14:33 schrieb Álvaro Fernández Rojas: >>> Hi Josua >>> >>> Not mounted rw. >>> Unfortunately I didn't have time to check it thoroughly and I didn't see >>> any remarkable messages. >>> >>> – Álvaro. >>> >>> El 5/7/16 a las 14:31, Josua Mayer escribió: >>>> Hi Álvaro, >>>> >>>> Am 05.07.2016 um 14:17 schrieb Álvaro Fernández Rojas: >>>>> It fails when trying to boot a Raspberry Pi, and then it segfaults when >>>>> calling mount_root without any parameters.\ >>>> How do you see it fail when it boots? Messages? / not mounted rw? >>>>> >>>>> – Álvaro >>>>> >>>>> El 5/7/16 a las 14:14, Josua Mayer escribió: >>>>>> Hi John, >>>>>> >>>>>> Am 05.07.2016 um 09:44 schrieb John Crispin: >>>>>>> On 30/06/2016 09:23, Álvaro Fernández Rojas wrote: >>>>>>>> I will try to test it on RPi tonight. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Álvaro. >>>>>>>> >>>>>>>> El 30/6/16 a las 9:21, John Crispin escribió: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> i have just merged to fstools patches into my staging tree that >>>>>>>>> address >>>>>>>>> a double mount issue and add back ext4 support. the ext4 patch >>>>>>>>> previously broke rPi and other ext4 targets, but i thini with josua's >>>>>>>>> patch applied it should work. i have done some basic testing already >>>>>>>>> my >>>>>>>>> end but would like further etst coverage to make sure there are no >>>>>>>>> hidden regressions >>>>>>>>> >>>>>>>>> things that should be tested are >>>>>>>>> >>>>>>>>> * does ext4 mount work on eMMC >>>>>>>>> * does rootfs mount work on rPi >>>>>>>>> * does extroot still work with flat mounts >>>>>>>>> * does extroot still work with flat overlay mounts >>>>>>>>> >>>>>>>>> i have only tested the last one so far. >>>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>> Hi Josua, >>>>>>> >>>>>>> after applying your patches, users of flat ext4 are seeing segfaults >>>>>>> when calling mount_root >>>>>> when manually calling mount_root? With which parameters? >>>>>> I will certainly look into it though. >>>>>>> John >>>> >> >> ___ >> Lede-dev mailing list >> Lede-dev@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/lede-dev >> ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] fstools testing help
Hi John, Could you please point me at where you merged my 2 patches? I want to ensure I am testing the same code that was causing segfaults. br Josua Mayer Am 05.07.2016 um 14:33 schrieb Álvaro Fernández Rojas: > Hi Josua > > Not mounted rw. > Unfortunately I didn't have time to check it thoroughly and I didn't see any > remarkable messages. > > – Álvaro. > > El 5/7/16 a las 14:31, Josua Mayer escribió: >> Hi Álvaro, >> >> Am 05.07.2016 um 14:17 schrieb Álvaro Fernández Rojas: >>> It fails when trying to boot a Raspberry Pi, and then it segfaults when >>> calling mount_root without any parameters.\ >> How do you see it fail when it boots? Messages? / not mounted rw? >>> >>> – Álvaro >>> >>> El 5/7/16 a las 14:14, Josua Mayer escribió: >>>> Hi John, >>>> >>>> Am 05.07.2016 um 09:44 schrieb John Crispin: >>>>> On 30/06/2016 09:23, Álvaro Fernández Rojas wrote: >>>>>> I will try to test it on RPi tonight. >>>>>> >>>>>> Regards, >>>>>> Álvaro. >>>>>> >>>>>> El 30/6/16 a las 9:21, John Crispin escribió: >>>>>>> Hi, >>>>>>> >>>>>>> i have just merged to fstools patches into my staging tree that address >>>>>>> a double mount issue and add back ext4 support. the ext4 patch >>>>>>> previously broke rPi and other ext4 targets, but i thini with josua's >>>>>>> patch applied it should work. i have done some basic testing already my >>>>>>> end but would like further etst coverage to make sure there are no >>>>>>> hidden regressions >>>>>>> >>>>>>> things that should be tested are >>>>>>> >>>>>>> * does ext4 mount work on eMMC >>>>>>> * does rootfs mount work on rPi >>>>>>> * does extroot still work with flat mounts >>>>>>> * does extroot still work with flat overlay mounts >>>>>>> >>>>>>> i have only tested the last one so far. >>>>>>> >>>>>>> John >>>>>>> >>>>> Hi Josua, >>>>> >>>>> after applying your patches, users of flat ext4 are seeing segfaults >>>>> when calling mount_root >>>> when manually calling mount_root? With which parameters? >>>> I will certainly look into it though. >>>>> John >> ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] fstools: ext4 overlay support - rootfs mounted twice bug
Am 29.06.2016 um 12:21 schrieb John Crispin:
>
>
> On 29/06/2016 12:11, Josua Mayer wrote:
>> Hi John,
>>
>> thansk for taking a look. I actually sent it this way by intention,
>> looking to get in touch with someone who had the original bug.
>>
>> Am 29.06.2016 um 08:30 schrieb John Crispin:
>>> Hi,
>>>
>>> the patch is an attachement making inline commenting impossible. please
>>> send patches inline
>> From 59a8fa6d7490ba3da76aec710a1beb241ffaa089 Mon Sep 17 00:00:00 2001
>> From: Josua Mayer <josua.maye...@gmail.com>
>> Date: Thu, 16 Jun 2016 18:35:30 +0200
>> Subject: [PATCH 2/4] mount_root: Don't mount ext4 rootfs twice
>>
>> When there is a) no rootfs_data overlay partition,
>> and b) /dev/root points to an ext4 partition
>> the partition would be mounted twice, once as / and then as /overlay.
>> The essence of this change is to return before mounting /overlay,
>> if /dev/root has been mounted as /.
>>>
>> Signed-off-by: Josua Mayer <josua.maye...@gmail.com>
>> ---
>> mount_root.c | 40 ++--
>> 1 file changed, 30 insertions(+), 10 deletions(-)
>>
>> diff --git a/mount_root.c b/mount_root.c
>> index 608ce5d..13e5772 100644
>> --- a/mount_root.c
>> +++ b/mount_root.c
>> @@ -37,25 +37,45 @@ start(int argc, char *argv[1])
>> if (!getenv("PREINIT") && stat("/tmp/.preinit", ))
>> return -1;
>>
>> +/*
>> + * When the default overlay partition name rootfs_data can not be found,
>> + * fall back to the special /dev/root device.
>> + */
>> if (!data) {
>> root = volume_find("rootfs");
>> volume_init(root);
>> +
>> +// mount /dev/root at /
>> ULOG_NOTE("mounting /dev/root\n");
>> mount("/dev/root", "/", NULL, MS_NOATIME | MS_REMOUNT, 0);
>> -}
>>
>> -/*
>> - * Before trying to mount and use "rootfs_data" let's check if there is
>> - * extroot configured. Following call will handle reading config from
>> - * the "rootfs_data" on its own.
>> - */
>> -extroot_prefix = "";
>> -if (!mount_extroot()) {
>> -ULOG_NOTE("switched to extroot\n");
>> +/*
>> + * Now that / has been mounted, and there is no overlay device,
>> + * see if extroot is configured.
>> + *
>> + * The following call will handle reading configuration from
>> + * rootfs on its own.
>> + */
>> +extroot_prefix = "";
>> +if (!mount_extroot()) {
>> +ULOG_NOTE("switched to extroot\n");
>> +/*
>> + * extroot succeeded mounting an overlay partition,
>> return.
>> + */
>> +return 0;
>> +}
>> +
>> +/*
>> + * Even if extroot was not configured, considering that no
>> overlay
>> + * partition was found, and / was mounted, return now.
>> + */
>> return 0;
>> }
>>
>> -/* There isn't extroot, so just try to mount "rootfs_data" */
>> +/*
>> + * neither /dev/root nor extroot were used.
>> + * Attempt to mount the overlay partition.
>> + */
>> switch (volume_identify(data)) {
>> case FS_NONE:
>> ULOG_WARN("no usable overlay filesystem found, using tmpfs
>> overlay\n");
>>
>
> derived from looking at the patch. as the patch is not inline i am not
> able to actually import it locally so i can only judge it by looking at it.
>
> after applying your patch, mount_extroot() would be hidden behind a
> if(!data) {} which means that it will only ever be called if there is no
> rootfs_data
That is only partially right. Like I pointed out, it is called inside
mount_overlay().
If there is a way to fix this, I need to understand what should happen:
code path before my patch:
data = volume_find("rootfs_data");
if (!data) {/* mount /dev/root as / */}
mount_extroot()
switch (volume_identify(data))
>From this artificial trace, I extracted these runtime conditions for
extroot:
1. rootfs_data exists but not mounted yet
2. rootfs_data does not exist and /dev/root mounted as /
I then guessed that mount_extroot only makes sense when there is an
overlay partition, or the read-write rootfs mounted in order to have its
configuration available.
So my guess was: if overlay isnt mounted yet but will be later, no point
in executing mount_extroot. Especially considering it will be inherently
called from the call to mount_overlay thats occuring later on.
>
> John
>
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] fstools: ext4 overlay support - rootfs mounted twice bug
Hi John,
thansk for taking a look. I actually sent it this way by intention,
looking to get in touch with someone who had the original bug.
Am 29.06.2016 um 08:30 schrieb John Crispin:
> Hi,
>
> the patch is an attachement making inline commenting impossible. please
> send patches inline
>From 59a8fa6d7490ba3da76aec710a1beb241ffaa089 Mon Sep 17 00:00:00 2001
From: Josua Mayer <josua.maye...@gmail.com>
Date: Thu, 16 Jun 2016 18:35:30 +0200
Subject: [PATCH 2/4] mount_root: Don't mount ext4 rootfs twice
When there is a) no rootfs_data overlay partition,
and b) /dev/root points to an ext4 partition
the partition would be mounted twice, once as / and then as /overlay.
The essence of this change is to return before mounting /overlay,
if /dev/root has been mounted as /.
>
Signed-off-by: Josua Mayer <josua.maye...@gmail.com>
---
mount_root.c | 40 ++--
1 file changed, 30 insertions(+), 10 deletions(-)
diff --git a/mount_root.c b/mount_root.c
index 608ce5d..13e5772 100644
--- a/mount_root.c
+++ b/mount_root.c
@@ -37,25 +37,45 @@ start(int argc, char *argv[1])
if (!getenv("PREINIT") && stat("/tmp/.preinit", ))
return -1;
+ /*
+* When the default overlay partition name rootfs_data can not be found,
+* fall back to the special /dev/root device.
+*/
if (!data) {
root = volume_find("rootfs");
volume_init(root);
+
+ // mount /dev/root at /
ULOG_NOTE("mounting /dev/root\n");
mount("/dev/root", "/", NULL, MS_NOATIME | MS_REMOUNT, 0);
- }
- /*
-* Before trying to mount and use "rootfs_data" let's check if there is
-* extroot configured. Following call will handle reading config from
-* the "rootfs_data" on its own.
-*/
- extroot_prefix = "";
- if (!mount_extroot()) {
- ULOG_NOTE("switched to extroot\n");
+ /*
+* Now that / has been mounted, and there is no overlay device,
+* see if extroot is configured.
+*
+* The following call will handle reading configuration from
+* rootfs on its own.
+*/
+ extroot_prefix = "";
+ if (!mount_extroot()) {
+ ULOG_NOTE("switched to extroot\n");
+ /*
+* extroot succeeded mounting an overlay partition,
return.
+*/
+ return 0;
+ }
+
+ /*
+* Even if extroot was not configured, considering that no
overlay
+* partition was found, and / was mounted, return now.
+*/
return 0;
}
- /* There isn't extroot, so just try to mount "rootfs_data" */
+ /*
+* neither /dev/root nor extroot were used.
+* Attempt to mount the overlay partition.
+*/
switch (volume_identify(data)) {
case FS_NONE:
ULOG_WARN("no usable overlay filesystem found, using tmpfs
overlay\n");
--
2.6.6
>
>> mount_root: Don't mount ext4 rootfs twice
>
> the patch is incorrect, it breaks the vase where there is an overlay
> setup + extroot. after your patch the extroot codepath wont ever run if
> there is a rootfs_data partition
Good point. I had indeed been thinking about this while creating the
patch. I would really be interested if you derived that from reading the
code, or testing. Eitehr way here is what I think how it should work:
If there is rootfs_data, the code wil proceed till down to the switch
statement, and then end up either in a) ramoverlay(), b)
mount_overlay(data) or c) mount_snapshot(data).
a) extroot will not happen.
b) mount_overlay calls mount_extroot
c) I didnt think of that case, and it doesnt mount extroot.
The only change, and I really hope I am not reading my code wrong (if
so, correct me please) is that besides a bunch of comments, is that when
there is no rootfs_data, and /dev/root gets mounted as /, the code
immediately returns before either a), b) or c).
>
> John
>
br
Josua Mayer
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] fstools: ext4 overlay support - rootfs mounted twice bug
Hi everybody,
Some of you might remember that there was a bug where an ext4 rootfs was
mounted twice, first as / and then as overlay.
After staring down the mount_root.c file I think I spotted the reason
for it. Sadly I was not able to reproduce the original problem so I am
looking for somebody who had this issue and would be willing to try out
a patch of mine.
Please get back at me if you can.
For any interested people I am attaching the patch to this mail (this is
not yet a patch submission, just discussion).
br
Josua Mayer
>From 92e2a22f3af1e04e8f83c3b580da941c69e460b4 Mon Sep 17 00:00:00 2001
From: Ram Chandra Jangir <rja...@codeaurora.org>
Date: Fri, 11 Mar 2016 22:01:42 +0530
Subject: [PATCH 1/2] fstools: support for ext4fs overlay
This change will enables eMMC (ext4 fs) boot support, when we try to boot
from eMMC card then it will read partition names from
/sys/block/mmcblkX/mmcblkXY/uevent
file and will mount the rootfs_data partition as ext4fs overlay.
Signed-off-by: Ram Chandra Jangir <rja...@codeaurora.org>
---
CMakeLists.txt | 1 +
libfstools/ext4.c | 193
libfstools/find.c | 3 +-
libfstools/libfstools.h | 1 +
libfstools/overlay.c| 14
libfstools/volume.h | 1 +
mount_root.c| 2 +
7 files changed, 214 insertions(+), 1 deletion(-)
create mode 100644 libfstools/ext4.c
diff --git a/CMakeLists.txt b/CMakeLists.txt
index a6002e5..5117e8e 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -11,6 +11,7 @@ ADD_LIBRARY(fstools SHARED
libfstools/overlay.c
libfstools/volume.c
libfstools/mtd.c
+ libfstools/ext4.c
libfstools/mount.c
libfstools/ubi.c
libfstools/find.c)
diff --git a/libfstools/ext4.c b/libfstools/ext4.c
new file mode 100644
index 000..f648aa8
--- /dev/null
+++ b/libfstools/ext4.c
@@ -0,0 +1,193 @@
+/*
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+*/
+
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "libfstools.h"
+
+#include "volume.h"
+
+#define ext4_sysfs_path "/sys/block/mmcblk*/mmcblk*/uevent"
+#define MAX_SIZE 128
+
+#define EXT_SB_OFF 0x400
+#define EXT_SB_KBOFF (EXT_SB_OFF >> 10)
+#define EXT_SB_MAGIC "\123\357"
+#define EXT_MAG_OFF 0x38
+
+struct ext4_priv {
+ char *name;
+ char*devname;
+};
+
+static struct driver ext4_driver;
+
+static int ext4_volume_init(struct volume *v)
+{
+ char buf[MAX_SIZE];
+ struct ext4_priv *p;
+
+ p = (struct ext4_priv*)v->priv;
+ snprintf(buf, sizeof(buf), "/dev/%s",p->devname);
+
+ v->name = strdup(p->name);
+ v->type = EXT4VOLUME;
+ v->blk = strdup(buf);
+ return 0;
+}
+
+static int
+ext4_part_match(char *dev, char *name, char *filename)
+{
+ FILE *fp;
+ char buf[MAX_SIZE];
+ char devname[MAX_SIZE];
+ int i;
+ int ret = -1;
+
+ fp = fopen(filename, "r");
+ if (!fp)
+ return ret;
+
+ while (fgets(buf, sizeof(buf), fp)) {
+ if (strstr(buf, "DEVNAME")) {
+ strcpy(devname, buf + strlen("DEVNAME="));
+ continue;
+ }
+ /* Match partition name */
+ if (strstr(buf, name)) {
+ ret = 0;
+ break;
+ }
+ }
+
+ fclose(fp);
+
+ /* make sure the string is \0 terminated */
+ devname[sizeof(devname) - 1] = '\0';
+
+ /* remove trailing whitespace */
+ i = strlen(devname) - 1;
+ while (i > 0 && devname[i] <= ' ')
+ devname[i--] = '\0';
+
+ strcpy(dev, devname);
+ return ret;
+}
+
+static int ext4_find_devname(char *dev, char *name)
+{
+ int i;
+ glob_t gl;
+
+ if (glob(ext4_sysfs_path, GLOB_NOESCAPE | GLOB_MARK, NULL, ) < 0)
+ return -1;
+
+ for (i = 0; i < gl.gl_pathc; i++) {
+ if (!ext4_part_match(dev, name, gl.gl_pathv[i])) {
+ globfree();
+ return 0;
+ }
+ }
+
+ globfree();
+ return -1;
+}
+
+static int check_for_mtd(const char *mtd)
+{
+ FILE *fp;
+ char dev[MAX_SIZE];
+
+ if ((fp = fopen("/proc/mtd", "r"))) {
+ while (fgets(dev, sizeof(dev), fp)) {
+ if (strstr(dev, mtd)) {
+fclose(fp);
+return -1;
+ }
+ }
+ }
+ fclose(fp);
+ return 0;
+}
+
+static int ext4_volume_find(struct volume *v, char *
Re: [LEDE-DEV] [PATCH] mount_root: implement overlay= boot option
Hi everybody,
Please take a look at this draft below. It attempts to solve the issue
of using an overlay device on regular block devices such as sata, emmc
or sdcards WITHOUT any unnecessary block2mtd layer in between.
I extended the find.method of ext4 code to include devname, because
partname is not easily available. It requires mtdparts or blockdevparts
kernel option, which requires specifying partition offsets and sizes.
Something that is totally redundant when there is a partition table, be
it MBR or GPT.
Ideally there would be 2 find-functions, one by partname and one by
devname. But that is currently hard to implement due to
a) lack of documentation for the intended purpose of each function
(init, find, read, write) implemented by drivers
b) lack of consistent behaviour of these functions across drivers (ext4,
mtd, ubi)
I feel like this driver api could use some rework to accomodate both mtd
and block devices, as well as potential future filesystems (f2fs?) in
addition to jffs, ubi and ext4.
br
Josua Mayer
Am 10.05.2016 um 14:25 schrieb josua.maye...@gmail.com:
> From: Josua Mayer <josua.maye...@gmail.com>
>
> This change adds code to handle a new option on cmdline: overlay=
> This is used to find the rootfs_data partition / disk when it has a
> non-standard name or location.
>
> It takes either the device node name, or the partition name:
> i.e. /dev/mmcblk0p3, mmcblk0p3, rootfs_data
>
> This option has precedence over the default name "rootfs_data", and extroot.
>
> Signed-off-by: Josua Mayer <josua.maye...@gmail.com>.
> ---
> libfstools/ext4.c | 4 +--
> mount_root.c | 86
> +--
> 2 files changed, 86 insertions(+), 4 deletions(-)
>
> diff --git a/libfstools/ext4.c b/libfstools/ext4.c
> index f648aa8..2c6dd91 100644
> --- a/libfstools/ext4.c
> +++ b/libfstools/ext4.c
> @@ -77,8 +77,8 @@ ext4_part_match(char *dev, char *name, char *filename)
> strcpy(devname, buf + strlen("DEVNAME="));
> continue;
> }
> - /* Match partition name */
> - if (strstr(buf, name)) {
> + /* Match either partition name or device node name */
> + if (strstr(buf, name) || strstr(devname, name)) {
> ret = 0;
> break;
> }
> diff --git a/mount_root.c b/mount_root.c
> index 47a3409..64aef66 100644
> --- a/mount_root.c
> +++ b/mount_root.c
> @@ -28,11 +28,52 @@ static int
> start(int argc, char *argv[1])
> {
> struct volume *root;
> - struct volume *data = volume_find("rootfs_data");
> + struct volume *data = NULL;
>
> if (!getenv("PREINIT"))
> return -1;
>
> + /*
> + * Check cmdline for a hint about overlay device
> + * e.g. /dev/mmcblk0p3
> + */
> + {
> + FILE *fp;
> + char buffer[100] = {0};
> +
> + fp = fopen("/proc/cmdline", "r");
> + while (!feof(fp)) {
> + if(fscanf(fp, "overlay=%s", buffer))
> + break;
> +
> + fseek(fp, 1, SEEK_CUR);
> + }
> + fclose(fp);
> +
> + /*
> + * If an overlay= argument was found, look for a volume with
> that name
> + */
> + if (buffer[0]) {
> + /*
> + * strip /dev/ prefix if any
> + */
> + int offset = 0;
> + if (strstr(buffer, "/dev/"))
> + offset = 5;
> +
> + ULOG_NOTE("Looking for overlay device given on
> commandline\n");
> + data = volume_find(buffer + offset);
> + }
> + }
> +
> + /*
> + * Look for default rootfs_data partition name
> + */
> + data = volume_find("rootfs_data");
> +
> + /*
> + * In case rootfs_data doesn't exist, only mount /dev/root for now
> + */
> if (!data) {
> root = volume_find("rootfs");
> volume_init(root);
> @@ -95,8 +136,49 @@ stop(int argc, char *argv[1])
> static int
> done(int argc, char *argv[1])
> {
> - struct volume *v = volume_find("rootfs_data");
> + struct volume *v = NULL;
> + FILE *fp;
> + struct stat fs = {0};
> + char *buffer;
>
> + /*
> + * First check if there is an overlay device hint in cmdline
> + */
> + fp = fopen("/proc/cmd
