On Wed, Jun 17, 2020 at 03:48:07PM -0500, Bruce Dubbs via lfs-dev wrote:
> On 6/17/20 3:36 PM, Ken Moffat via lfs-dev wrote:
>
> > On this build, after misreading 'stripping' earlier in the book (and
> > trashing the partial system by running it from within chroot) I had
> > to start over. So, before trying 'stripping again' I exited,
> > unmounted, copied everything, then remounted before trying
> > 'stripping again'.
> >
> > I guess that means I can look at the backup to confirm that
> > stripping again did change the perms. Will do that later.
> > Meanwhile, thanks for the correction for wall.
>
> Hmm. You did do the backup as root, right.
>
> Doing a tar or cp as a regular user can change permissions.
>
> -- Bruce
>
Yes, I learned that a long while ago :)
This time, as root (I open a term and su so that I can mkfs, mount,
chown to lfs, then keep that open e.g. to copy the bzImage to the
host system's /boot) I umounted everything which mount|grep|awk
showed had /mnt/lfs as its third field, then I remounted only
/mnt/lfs and used cp -a.
After that I mounted the sources and logs, and then used my normal
(updated for cross) script to enter chroot, then tried adding
stripping-again to my chroot script and running that.
Now that I've looked at the copy, everything was good at that point
(only three listed, for brevity) -
~$ ls -l /scratch/lfs/bin/su /scratch/lfs/usr/bin/{newgrp,wall}
-rwsr-xr-x 1 root root 74128 Jun 16 23:34 /scratch/lfs/bin/su
-rwsr-xr-x 1 root root 45728 Jun 16 23:34
/scratch/lfs/usr/bin/newgrp
-rwxr-sr-x 1 root tty 43176 Jun 17 01:54 /scratch/lfs/usr/bin/wall
My eventual reply on -support showed that /bin/su had been updated
at a later time, and that time matched when I ran stripping again.
ĸen
--
He died at the console, of hunger and thirst.
Next day he was buried, face-down, nine-edge first.
- the perfect programmer
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
