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

/var/empty is not recreated after a reboot. #3

Closed
0x9900 opened this issue Nov 10, 2012 · 5 comments
Closed

/var/empty is not recreated after a reboot. #3

0x9900 opened this issue Nov 10, 2012 · 5 comments

Comments

@0x9900
Copy link
Contributor

0x9900 commented Nov 10, 2012

When setting the variable tardirs="var" the directory /var/empty is not saved. Then at reboot the directory is not recreated and some of the daemon would not restart.

This issue is causing sshd not to start on OpenBSD-5.2

@yellowman
Copy link
Owner

As tar can't exclude sockets (which skew its return value, which we depend on), flashrd tries to not include sockets or directories. /var/empty should be included if it were truly empty, but /var/empty/dev/ contains a socket which never gets listed. Due to /var/empty not actually being empty, the only reasonable solution is to put a file in /var/empty/dev (like touch /var/empty/dev/.flashrd) before turning on rc.shutdown tardirs for the first time. That way, the directories will be created.

There are probably better ways to solve the problem, but for now, I think it's decent to force flashrd to put a dummy file in /var/empty/dev, or for an existing image, do it yourself before enabling tardirs in rc.shutdown.

@yellowman yellowman reopened this Nov 11, 2012
@yellowman
Copy link
Owner

Your patch doesn't solve the problem. tar tries to include the socket, return value is screwed

@yellowman
Copy link
Owner

Ok, it's fixed for real now. Try new rc.shutdown.

@0x9900
Copy link
Contributor Author

0x9900 commented Nov 11, 2012

Yes, I know... That's why I tried to kill the comment.
I wanted to send you a patch with the same fix but I didn't know if you would accept that solution.
Thank you for fixing that problem.

@yellowman
Copy link
Owner

I don't really understand or use most of github's features. So until I read this, I didn't realize that you must have clicked 'x' on the comment :)

Anyways thanks for the report. I think the issue is ready to put to rest now, and it has been an issue for about 3 months since I started checking the return value from tar.

Fred C [[email protected]] wrote:

Yes, I know... That's why I tried to kill the comment.


Reply to this email directly or view it on GitHub:
#3 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants