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

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

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.

Jan

> 
> Probably, only the case when an error happens before rootf_postprocess
> (e.g., in image_install) may lead to some mounts left.
> 
>>>
>>>
>>> With kind regards,
>>> Baurzhan
>>
> 

-- 
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/1e2853af-9f9f-4bad-89a0-d5629b2a5ca1%40siemens.com.