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

[Uladzimir Bely <ubely@ilbers.de>]

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.

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
> 

-- 
Best regards,
Uladzimir.



-- 
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/0fb46eeddf91578871a624d51c76e79958760a24.camel%40ilbers.de.