On Mon, Nov 10, 2025 at 11:11 PM Zhu Yanjun <[email protected]> wrote: > > In FC42, when I run "./luo_multi_session" > > # ./luo_multi_session > # [STAGE 1] Starting pre-kexec setup for multi-session test... > # [STAGE 1] Creating state file for next stage (2)... > # [STAGE 1] Creating empty sessions 'multi-test-empty-1' and > 'multi-test-empty-2'... > # [STAGE 1] Creating session 'multi-test-files-1' with one memfd... > # [STAGE 1] Creating session 'multi-test-files-2' with two memfds... > # [STAGE 1] Executing kexec... > > Then the system hang. And via virt-viewer, a calltrace will appear.
Looks like mountroot fails, are you passing the same kernel parameters as the during cold boot? i.e. kexec -l -s --reuse-cmdline --initrd=[initramfs] [kernel] Pasha > > The call trace is in the attachment. > > Yanjun.Zhu > > 在 2025/11/10 7:26, Pasha Tatashin 写道: > > On Mon, Nov 10, 2025 at 8:16 AM Pratyush Yadav <[email protected]> wrote: > >> On Sun, Nov 09 2025, Zhu Yanjun wrote: > >> > >>> 在 2025/11/8 10:13, Pasha Tatashin 写道: > >>>> On Fri, Nov 7, 2025 at 6:36 PM Yanjun.Zhu <[email protected]> wrote: > >>>>> On 11/7/25 4:02 AM, Pasha Tatashin wrote: > >>>>>> On Fri, Nov 7, 2025 at 7:00 AM Pasha Tatashin > >>>>>> <[email protected]> wrote: > >>>>>>>> Hi, Pasha > >>>>>>>> > >>>>>>>> In our previous discussion, we talked about counting the number of > >>>>>>>> times > >>>>>>>> the kernel is rebooted via kexec. At that time, you suggested adding > >>>>>>>> a > >>>>>>>> variable in debugfs to keep track of this count. > >>>>>>>> However, since debugfs is now optional, where would be an appropriate > >>>>>>>> place to store this variable? > >>>>>>> It is an optional config and can still be enabled if the live update > >>>>>>> reboot number value needs to be accessed through debugfs. However, > >>>>>>> given that debugfs does not guarantee a stable interface, tooling > >>>>>>> should not be built to require these interfaces. > >>>>>>> > >>>>>>> In the WIP LUO [1] I have, I pr_info() the live update number during > >>>>>>> boot and also store it in the incoming LUO FDT tree, which can also be > >>>>>>> accessed through this optional debugfs interface. > >>>>>>> > >>>>>>> The pr_info message appears like this during boot: > >>>>>>> [ 0.000000] luo: Retrieved live update data, liveupdate number: 17 > >>>>>>> > >>>>>>> Pasha > >>>>>> Forgot to add link to WIP LUOv5: > >>>>>> [1] https://github.com/soleen/linux/tree/luo/v5rc04 > >>>>> Thanks a lot. I’ve carefully read this commit: > >>>>> https://github.com/soleen/linux/commit/60205b9a95c319dc9965f119303a1d83f0ff08fa. > >>>>> > >>>>> To be honest, I’d like to run some tests with who/luo, including the > >>>>> selftest for kho/luo. Could you please share the steps with me? > >>>>> > >>>>> If the testing steps have already been documented somewhere, could you > >>>>> please share the link? > >>>> Currently the test performs in-kernel tests for FLB data, it creates a > >>>> number of FLB for every registered LUO file-handler, which at the > >>>> moment is only memfd. > >>>> > >>>> It works together with any of the kexec based live update tests. In > >>>> v5, I introduce two tests: > >>>> luo_kexec_simple > >>>> luo_multi_session > >>>> > >>>> For example, with luo_multi_session: > >>> Hi, Pasha > >>> > >>> I enabled "CONFIG_LIVEUPDATE=y" > >>> > >>> # ./luo_multi_session > >>> 1..0 # SKIP Failed to open /dev/liveupdate. Is the luo module loaded? > >>> > >>> # ls /dev/liveupdate > >>> ls: cannot access '/dev/liveupdate': No such file or directory > >>> > >>> # grep "LIVEUPDATE" -inrHI /boot/config-`uname -r` > >>> /boot/config-next-20251107-luo+:349:CONFIG_LIVEUPDATE=y > >>> /boot/config-next-20251107-luo+:11985:CONFIG_LIVEUPDATE_TEST=y > >>> > >>> I made tests on FC42. But /dev/liveupdate is missing. > >> You need to add liveupdate=1 to your kernel cmdline to enable LUO and > >> get /dev/liveupdate. > > +1, kernel parameters require: kho=1 liveupdate=1 > > > >> Pasha, your LUO series doesn't add the liveupdate parameter to > >> kernel-parameters.txt. I think it should be done in the next version to > >> this parameter is discoverable. > > Yeah, that is missing, I will update that in a standalone patch, or in > > a next version. > > > > Thanks, > > Pasha > > -- > Best Regards, > Yanjun.Zhu
