rockedge wrote: Wed Aug 16, 2023 11:05 pm@wiak All of my reports today are results from build runs using:
Code: Select all
build_firstrib_rootfs.sh version="8.0.0"; revision="-rc5"
As I mentioned early today I git pulled the latest from GitHub and have been running builds today using what ever the very latest commits have been.
I have not seen the resolver.confORIG problem at all today. I mentioned that I did see it before. Both builds I ran in the last hour both have still had pieces mounted but once umounted the file systems works fine. These 2 runs have been Fedora and now I am doing a KL Void minimal to start a fresh experimental platform.
Unless indicated I am using the very latest version of the build script which is version="8.0.0"; revision="-rc5" at this moment.
Okay, thanks rockedge. Must be a different problem to do with the mount binds. I have no time as I say right now, but will check that later. Just posted 8.0.0 -rc6, but that won't fix any mount bind issues.
Quick check and I note that I have the addons_f.plug being sourced prior to the bind umounts. That is potentially problematic. If you do a cd inside the addons_f.plug that would mean the umounts might not work. i.e. the issue could be something in addons_f.plug. I'll try and re-arrange that more safely when I have time to look into the likely cause later.
Code: Select all
[ -s ./addons_f.plug ] && . ./addons_f.plug # for downloading layer addons and FR utils (e.g. 12KL...sfs; 11rox...sfs, wd_grubconfig)
sync;sync
# Finished doing the INSIDE_CHROOT stuff so can now clean up the chroot bind mounts:
umount -l firstrib_rootfs/proc && umount -l firstrib_rootfs/sys && umount -l firstrib_rootfs/dev/pts && umount -l firstrib_rootfs/dev