Re: [PATCH] meta: Drop lazy and recursive unmounts

["'Jan Kiszka' via isar-users" <isar-users@googlegroups.com>]

On 04.10.24 10:16, 'Jan Kiszka' via isar-users wrote:
> On 04.10.24 10:00, Uladzimir Bely wrote:
>> On Fri, 2024-10-04 at 09:28 +0200, 'Florian Bezdeka' via isar-users
>> wrote:
>>> On Thu, 2024-10-03 at 16:37 +0200, Baurzhan Ismagulov wrote:
>>>> Hello Florian,
>>>>
>>>> On 2024-10-01 13:59, Florian Bezdeka wrote:
>>>>> I scanned the logs and searched for /dev mounts. Typical example:
>>>>>
>>>>> tmp/work/debian-bookworm-amd64/isar-exclude-docs/0.2.2-
>>>>> r0/temp/log.do_dpkg_build.18089
>>>>> 521:devpts on /dev/pts type devpts
>>>>> (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666)
>>>>> 522:tmpfs on /dev/shm type tmpfs (rw,relatime,inode64)
>>>>
>>>> We'll address the patches with priority. Could you please provide
>>>> 1. the output
>>>> of bitbake ... 2>&1 |tee bitbake.txt and 2. the related failed task
>>>> log.do_build? Off-list if sensitive.
>>>
>>> I already sent patches for fixing this issue. There is no failed
>>> task.
>>> rootfs::do_rootfs_postprocess and rootfs::do_rootfs_install both call
>>> rootfs::rootfs_do_mounts but never clean up.
>>>
>>> In case the mounts are left behind I will run into "can not umount,
>>> device still active" later.
>>>
>>>>
>>>>
>>>>> At the end I still have one active /dev mount:
>>>>> tmpfs on /builds/myproject/build/tmp/work/debian-bookworm-
>>>>> amd64/sbuild-chroot-target/1.0-r0/rootfs/dev type tmpfs
>>>>> (rw,nosuid,size=65536k,mode=755,inode64)
>>>>
>>>> Thanks for the info, this looks like an sbuild migration bug.
>>>> Checking.
>>>
>>> Reviewing patches should do it...
>>>
>>
>> Hello all.
>>
>> I've checked this case and we are really have this mount left. It's not
>> related to sbuild (e.g., building packages) but to producing sbuild-
>> chroot itself.
>>
>> E.g., entering kas shell and running "bitbake sbuild-chroot-target"
>> always results in "/dev" mount left in sbuild-chroot workdir rootfs.
>>
>> For "image" targets we have umount routiness in image.bbclass. For
>> initramfs, we now have Jan's patches.
>>
>> But I guess that "[PATCH 0/2] Fix leftover mounts in rootfs.bbclass"
>> patchset should itself cover all cases. And we might not even need
>> special handling in image.bbclass and initramfs.bbclass.
> 
> We can and possibly should make this work - but not in the way those
> patches currently interact. Please check once again.

No, we should not start to consolidate the umounts again. If we do that,
we could also drop the warning from the catch-all handler
build_completed and let it umount everything, as we've done in the past.
If we don't want this anymore, every individual task that does mounting
must also do the umounting at its end. And that means even the umount in
do_rootfs_finalize would become obsolete.

Jan

-- 
Siemens AG, Technology
Linux Expert Center

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/ecda24dc-7921-4477-b3ba-dc14a39aa148%40siemens.com.