Reorder or remove deleting the lfs user

[xry111]

Currently we are deleting the lfs user before 701-changingowner. This is bad because between these two steps there's a time point where the LFS system is owned by an unnamed UID. And it's blown up after ​https://wiki.linuxfromscratch.org/lfs/changeset/6e179a90255308dc64eec386fb3ae49ab16acca4.

For now I've filtered out --step lfs from 701-changingowner but it's not an ideal solution.

And DJ believes we should just not delete the lfs user.

[Pierre Labastie]

I agree removing the lfs user is not part of the book. But creating it is! So a real testing of book instructions involves creating the lfs user. This is of course impossible if the lfs user already exists. This leads me to think we should always remove the lfs user before doing anything in jhalfs. This would solve the ordering problem, and allow testing the book instructions. But this has a drawback if for any reason there is a permanent lfs user on the host, which should never be deleted. Since we already save the lfs user directory when the lfs user already exists, we could add lfs user removal after that. But then, when recreating it, it may appear with a different uid, so that it wouldn't own the saved directory. Well, in this case, just add a chown when replacing the directories in their correct location. Will try to come up with something.

[Pierre Labastie]

Trying to come back to at least maintain jhalfs... Hope I'll get enough time. I'll first just reorder lfs removal to after the "mk_SUDO" step. And revert the commits that removed the --from-lfs switches. Since everything after the "mk_SUDO" step is in chroot, and user lfs cannot be used in chroot, this should at least fix the problem of the unnamed uid in a better way. Now, for the bigger picture, I am not sure what to do:

• if the lfs user does not exist, this is simple: create it and leave it, as the book does, but I do not like the idea of having an automated tool create a user and leave it around without the user knowing it...
• if the user lfs already exists: save its home and remove it, before recreating it when running the book. But then, which user should be left at the end? the initial or the created one?

[Pierre Labastie]

I've come to this:

• If a user with name lfs exists on the system:
  • rename that user to lfsxxx, and move its home to /home/lfs.XXX. This means that if a user with name lfsxxx is already on the system, we must delete it, possibly after asking (but I do not like that, because it means jhalfs cannot be run unattended).
  • create a new lfs user with book instructions
  • leave everything as is, but warn at the end of the jhalfs run that there is a new user and the old one has changed name

• if there is no user with name lfs:
  • create it with book instructions
  • leave it as is, but warn at the end of the jhalfs run that there is a new user

Please comment...

[Douglas R. Reno]

Replying to Pierre Labastie:

I've come to this:

• If a user with name lfs exists on the system:
  • rename that user to lfsxxx, and move its home to /home/lfs.XXX. This means that if a user with name lfsxxx is already on the system, we must delete it, possibly after asking (but I do not like that, because it means jhalfs cannot be run unattended).
  • create a new lfs user with book instructions
  • leave everything as is, but warn at the end of the jhalfs run that there is a new user and the old one has changed name

• if there is no user with name lfs:
  • create it with book instructions
  • leave it as is, but warn at the end of the jhalfs run that there is a new user

Please comment...

This approach sounds really good to me. I think we probably shouldn't ask since most users shouldn't have anything in /home/lfs other than the files we create, and we want jhalfs to be completely automated. A lot of us editors that use jhalfs for testing LFS have a 'lfs' user kept around, so this would probably be the best way for us editors as well. I think a notification at the end would be helpful as well

This also fixes the issue that I run into when building a new system where I don't realize that the lfs user hasn't been created yet, and jhalfs fails because of it

[Douglas R. Reno]

Would it be possible to add some kind of checks into jhalfs to make sure that /mnt/lfs is a mounted filesystem instead of just a directory? I know that's out of scope for this ticket but I'll create a new one if it is reasonable

[Pierre Labastie]

Replying to Douglas R. Reno:

Would it be possible to add some kind of checks into jhalfs to make sure that /mnt/lfs is a mounted filesystem instead of just a directory? I know that's out of scope for this ticket but I'll create a new one if it is reasonable

I have had use cases where $(MOUNT_PT) was actually a directory. For example when I wanted to test some part of jhalfs itself, and I didn't have a spare partition. Or when I wanted to test a part of lfs build without the aim of booting it later. But there are maybe ways to mount a directory onto itself.

[xry111]

Replying to Pierre Labastie:

Replying to Douglas R. Reno:

Would it be possible to add some kind of checks into jhalfs to make sure that /mnt/lfs is a mounted filesystem instead of just a directory? I know that's out of scope for this ticket but I'll create a new one if it is reasonable

I have had use cases where $(MOUNT_PT) was actually a directory. For example when I wanted to test some part of jhalfs itself, and I didn't have a spare partition. Or when I wanted to test a part of lfs build without the aim of booting it later. But there are maybe ways to mount a directory onto itself.

FTR: Douglas hit some unexpected systemd test failures when MOUNT_PT is not a real mount point. And I guess mount --bind $LFS $LFS is enough to fix the failures.

[Pierre Labastie]

Replying to xry111:

Replying to Pierre Labastie:

Replying to Douglas R. Reno:

Would it be possible to add some kind of checks into jhalfs to make sure that /mnt/lfs is a mounted filesystem instead of just a directory? I know that's out of scope for this ticket but I'll create a new one if it is reasonable

I have had use cases where $(MOUNT_PT) was actually a directory. For example when I wanted to test some part of jhalfs itself, and I didn't have a spare partition. Or when I wanted to test a part of lfs build without the aim of booting it later. But there are maybe ways to mount a directory onto itself.

FTR: Douglas hit some unexpected systemd test failures when MOUNT_PT is not a real mount point. And I guess mount --bind $LFS $LFS is enough to fix the failures.

Let's file another ticket... Not sure what to do, but the discussion is not for this ticket.

[Pierre Labastie]

pushed a new branch plabs/lfs-user. Thanks for testing...

[xry111]

I still prefer jhalfs to just use a different name, like lfs1 or lfs2 (if both lfs1 and lfs2 exists) for build, leaving the lfs user unchanged if it already exists. I've changed the references to the lfs user in a LFS branch: ​https://lists.linuxfromscratch.org/sympa/arc/lfs-book/2024-12/msg00149.html, it should (I hope...) be easy to implement this.

[Pierre Labastie]

Ok, so several strategy discussed, both on mail and here:

• renodr: agrees with comment:3
• xry111: proposes to modify the LFS book so that it is easy to replace "lfs" with another name. Has to be agreed on the LFS side, though.
• bdubbs: proposes to remove the lfs user before entering jhalfs, and to always remove it when it is not needed anymore (before entering chroot).
• Jeremy wiig: agrees with bdubbs, but had rather be able to create and use a random lfs user (lfs$RANDOM or so).

So I'd propose two possible approaches here:

• if the LFS book is modified: let the user define the name and group of the temporary user (default lfs:lfs, but could also be cosette:miserables or whatever). This user and group shouldn't exist on the machine and would be removed before entering chroot (as bdubbs said, there is no need to keep it further on an automated build)
• if the LFS book isn't modified: roughly keep the present state of trunk, except if an lfs user already exists, it is moved to another name before creating a temporary one. The temporary one would be deleted before entering chroot, and the moved one would be left as is (possibly with a warning at the end of the jhalfs run).

Note that bdubbs made a good point telling that the temporary user is only needed to stay in a manual build, to be able to fix errors in chap. 5 and 6, but not in an automated build...

[Pierre Labastie]

I pushed the scenario "if the book is modified" at 972816e on branch plabs/lfs-user. It must be used with a modified book (branch xry111/lfs-user of the the lfs book).

[Pierre Labastie]

Eventually modifying the LFS book was accepted. So this ticket is fixed by commits 9de90cd68, 462ecfda7fd, 8affcaddf2, and 972816ed0c87.