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.