-
Notifications
You must be signed in to change notification settings - Fork 14
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
Comments
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. |
Your patch doesn't solve the problem. tar tries to include the socket, return value is screwed |
Ok, it's fixed for real now. Try new rc.shutdown. |
Yes, I know... That's why I tried to kill the comment. |
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:
|
See https://github.com/yellowman/flashrd/blob/master/etc/rc.shutdown and see yellowman/flashrd#3 for a complete explanation
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
The text was updated successfully, but these errors were encountered: