RE: [PATCH 0/3] umount fixes and cleanups

["Hombourger, Cedric" <Cedric_Hombourger@mentor.com>]

Hi Jan,

In my testing, the only mounts that were really needed for the go packages I was building are:

/dev		# was already mounted before our changes
/dev/pts	# was not mounted before
/sys		# was not mounted before

I have some doubts about /dev/shm; I cannot recall if that one was truly needed

Regarding ordering, this brute force umount command will produce errors for sub-mounts (e.g. when trying to umount /sys/fs/cgroup before /sys/fs/cgroup/blkio)
I seem to remember that in the early days Isar would just loop over its mounts until it got rid of everything

Cedric

-----Original Message-----
From: Jan Kiszka [mailto:jan.kiszka@siemens.com] 
Sent: Wednesday, December 5, 2018 3:36 PM
To: Hombourger, Cedric <Cedric_Hombourger@mentor.com>; Maxim Yu. Osipov <mosipov@ilbers.de>; isar-users <isar-users@googlegroups.com>
Subject: Re: [PATCH 0/3] umount fixes and cleanups

On 05.12.18 13:31, Hombourger, Cedric wrote:
> I was able to use the following work-around for your test-case:
> 
> # run the following command until all mounts are gone umount $(mount 
> |grep $PWD/my-mnt|awk '{print $3}')

Does that listing always produce the right ordering for umount, or does the order not matter?

Just for me to remember: We do want the recursive mounts, don't we? Or, said differently, what is the downside of Maxim's revert for use cases you see?

Jan

> 
> umount -R or -l indeed failed
> 
> Cedric
> 
> -----Original Message-----
> From: Jan Kiszka [mailto:jan.kiszka@siemens.com]
> Sent: Wednesday, December 5, 2018 3:15 PM
> To: Maxim Yu. Osipov <mosipov@ilbers.de>; isar-users 
> <isar-users@googlegroups.com>
> Cc: Hombourger, Cedric <Cedric_Hombourger@mentor.com>
> Subject: Re: [PATCH 0/3] umount fixes and cleanups
> 
> On 05.12.18 12:12, Maxim Yu. Osipov wrote:
>> On 12/5/18 12:29 PM, Jan Kiszka wrote:
>>> Patches related to resolving the pending CI issues as well as 
>>> simplifying the umounts used during cleanup.
>>
>> Tried to run in patch queue:
>>
>> 027b7cf Remove redundant recursive umounts
>> c1bdc33 isar-events: Improve umount handler
>> b354273 ci: Wait for bitbake worker to finish before deleting 
>> artifacts
>> 9cf29e6 isar-bootstrap: Fix and cleanup bind mounting
>> b354026 isar-image: umount base-apt when doing offline build e965c0d
>> gitlab-ci: Switch to ci_build.sh ...
>>
>> After execution of problematic test case (I rebooted PC and executed 
>> steps in clean tree):
>>
>> my stretch Debian system was entered into unusable state as many 
>> important mounts were disappeared (see log of mount points before and 
>> after execution  of last command attached).
> 
> OK, so I took the time and extracted the root cause. We may see a Debian 4.9 kernel bug here:
> 
> # mkdir my-mnt
> # mount --rbind /sys my-mnt
> # mount --make-rslave my-mnt
> # umount {-R,-l,-R -l} my-mnt
> # rmdir my-mnt
> rmdir: failed to remove 'my-mnt': Device or resource busy
> 
> This works fine on my Leap 15.0 kernel (4.12) as well as the 4.4 kernel (Ubuntu) used on our CI server.
> 
> *This* is information we can base commits on. Also, we can file a bug against Debian with this. Could you do that (keep my in CC)?
> 
> Thanks,
> Jan
> 
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate 
> Competence Center Embedded Linux
> 

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux