Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mklive nukes host pseudofs (dev, sys, proc) when interrupted in some circumstances #364

Closed
0x5c opened this issue Jan 16, 2024 · 3 comments · Fixed by #365
Closed

mklive nukes host pseudofs (dev, sys, proc) when interrupted in some circumstances #364

0x5c opened this issue Jan 16, 2024 · 3 comments · Fixed by #365
Labels
bug Something isn't working
Milestone

Comments

@0x5c
Copy link
Contributor

0x5c commented Jan 16, 2024

(Previously mentioned as a secondary bug in #288)

When interrupting mklive (or when it hits a failure) in some circumstances, it will fail to unmount all or some of the pseudofs bind mounts in umount_pseudofs. This causes the rm -rf call in error_out to delete anything in the pseudofs bind mounts that remain.

In my case, lingering processes in a DKMS build kept the /dev bind mount busy, causing most dev nodes on the host to be removed. The main symptoms were the shell screaming about /dev/null being nonexistent and most programs failing to start; a full system restart was required.

A simple reproducer would be

./build-x86-images.sh -a x86_64 -b base -- -v linux6.6 -p zfs

and a ^C once the target xbps is at Building DKMS module 'zfs-2.2.2' for kernel-6.5.13_1...

It seems like there's 3 prongs to that bug

  1. mklive does not ensure that processes in the chroot are all gone, allowing for pseudofs remaining busy.
  2. There is insufficient error handling when unmounting, allowing further cleanup to happen while one or more pseudofs is still being used.
  3. The rm call lacks the --one-file-system option, which should prevent it deleting anything in pseudofs if all else fails.

Anything keeping the /sys bind mount busy could also have permanent consequences, like the mangling of efivars on the host.

@leahneukirchen
Copy link
Member

+1, especially for (3).

@classabbyamp
Copy link
Member

  1. mklive does not ensure that processes in the chroot are all gone, allowing for pseudofs remaining busy.

any ideas on this? Not sure how we could ensure everything is done. I don't think wait would work here for procs e.g. spawned by xbps

classabbyamp added a commit to classabbyamp/void-mklive that referenced this issue Jan 16, 2024
- add some error handling to `umount_pseudofs`
- disable the trap before running `error_out` to stop it running multiple times
- add `--one-file-system` to ensure that the `rm -rf` can't screw you

fixes void-linux#364
@classabbyamp classabbyamp added the bug Something isn't working label Jan 16, 2024
@classabbyamp
Copy link
Member

partial solution, maybe? #365

@classabbyamp classabbyamp added this to the 2024Q1 milestone Jan 18, 2024
classabbyamp added a commit to classabbyamp/void-mklive that referenced this issue Feb 13, 2024
- add some error handling to `umount_pseudofs`
- disable the trap before running `error_out` to stop it running multiple times
- add `--one-file-system` to ensure that the `rm -rf` can't screw you

fixes void-linux#364
classabbyamp added a commit that referenced this issue Feb 15, 2024
- add some error handling to `umount_pseudofs`
- disable the trap before running `error_out` to stop it running multiple times
- add `--one-file-system` to ensure that the `rm -rf` can't screw you

fixes #364
classabbyamp added a commit to classabbyamp/void-mklive that referenced this issue Feb 16, 2024
- add some error handling to `umount_pseudofs`
- disable the trap before running `error_out` to stop it running multiple times
- add `--one-file-system` to ensure that the `rm -rf` can't screw you

fixes void-linux#364
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants