View previous topic :: View next topic |
Author |
Message |
BoGun n00b
Joined: 16 Jul 2023 Posts: 12
|
Posted: Sun Jul 16, 2023 4:01 pm Post subject: (Solved) Help please, autoboot Mac mini after power failure |
|
|
Hi all,
New here on the forum and been dabbling with Linux for a couple of years now. I'm glad I finally managed to quit both OSX and MS but it's been a struggle I can promise you that.
Ok so I guess from reading my "subject" sentence that you understand I'm a newbie? But at least I've understood from ending up here on the Gentoo forum many times when googling "Daphile Gentoo" that Unsupported Software is the section to start a thread about anything that has to do with Daphile.
So ok here's what I would like to achieve, but first a little background; I got Daphile installed on a old mac mini 2009 and in general I'm very happy with it. It's very stable.
I really like most things with old Macs appart from one thing and that is the poor solution they adapted if there's a power failure (or outage maybe? I'm not sure. English is not my native language). As many thing Apple it works pretty fine as long as you ONLY use Apple products, in this case Os X. In Mac OS X, you can check "Start up automatically after a power failure" in the "Energy Saver System Preferences" to get it to boot up after a power failure.
But having this value checked doesn't make a persistent "BIOS/EFI" setting as one can set on a PC. It only gets set by Mac OS X on every boot ...e.g when using anything other than OS X booting up after power failure it doesn't work.
Or at least I thought so for quite a long time ...
I've searched for a solution to this for a very long time and finally today I actually found a solution in this thread > https://superuser.com/questions/212434/how-to-reboot-after-power-failure-for-mac-mini-running-ubuntu
So I followed the instructions for my type of Mac and tested the suggested command and Voila, magic! it worked.
"But say the joy that lasts" ... (I used this command btw : setpci -s 00:03.0 0x7b.b=0x19)
Naturally I also wanted this to be "automatically" set every time the Mini/Daphile boots as desribed in the thread. But of course when following the instructions to create "a systemd startup service" to set this value at every boot I failed.
I basically don't now shit, but I guess because Daphile presumably uses OpenRC which how I understand it from reading wiki is "Gentoo's native init system".
So here's where any of you clever people come in (I hope ...) anyone who could guide me and solve this? E.g how should the "script" be written and where (what directory) should it be placed. And of course finally, how do I start it?
P,S, please don't expect too much of my very poor Linux skills. I'm on a very basic level, not very clever but on the other hand very stubborn and tenacious.
Last edited by BoGun on Sat Jul 22, 2023 1:33 pm; edited 1 time in total |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 22578
|
Posted: Sun Jul 16, 2023 4:25 pm Post subject: |
|
|
Welcome to the forums.
For OpenRC-based systems, if you want to run a command at startup, see /etc/local.d/README (partial copy inline; see file for full notes): Code: | This directory should contain programs or scripts which are to be run
when the local service is started or stopped.
If a file in this directory is executable and it has a .start extension,
it will be run when the local service is started. If a file is
executable and it has a .stop extension, it will be run when the local
service is stopped. | Enable the local service in the default if it is not already enabled. If unsure, enable it anyway. Enabling it when it is already enabled should be harmless. Next, write a simple shell script conforming to those conventions and make it run the command(s) needed to configure the system. Then, reboot and check whether it works as desired. |
|
Back to top |
|
|
BoGun n00b
Joined: 16 Jul 2023 Posts: 12
|
Posted: Sun Jul 16, 2023 5:18 pm Post subject: |
|
|
Hu wrote: | Enable the local service in the default if it is not already enabled. If unsure, enable it anyway. Enabling it when it is already enabled should be harmless. Next, write a simple shell script conforming to those conventions and make it run the command(s) needed to configure the system. Then, reboot and check whether it works as desired. |
Dear friend, I sadly don't understand much of what you're telling me :-/ ...
I understand a little and guessing a lot, I looked in the /etc/local.d directory and there's some text files there which I suppose should tell me that local is in use and I checked with command rc-service local status and got started so I guess that part is OK?
Also (think I) understand from reading the suggested README file in local.d that some kind of text file could/should be placed in the said directory and if it shall start at boot it needs to have .start as extension? But next ...? I'm lost.
I only know that my earlier learned command, e.g = setpci -s 00:03.0 0x7b.b=0x19 makes the Mini boot after power failure IF I give the command from the CLI after every reboot. Got no idea how to do what you suggest with yours "Next, write a simple shell script conforming to those conventions" unfortunately :-/.
Can I just paste my command in a text file and name it "boot_after_power_failure.start" or how is this done? Can't be that easy I'm certain? |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 22578
|
Posted: Sun Jul 16, 2023 5:42 pm Post subject: |
|
|
Almost, but not quite. For any script, you need an appropriate #! line so the kernel can find the right interpreter. Also, you did not specifically mention setting the permissions on it. It must be executable to be used, and text editors usually write new files as non-executable, so you will need to fix the permissions after it is created.
The below might do what you want. It is untested. Code: | printf '%s\n' '#!/bin/sh' 'setpci -s 00:03.0 0x7b.b=0x19' > /etc/local.d/50_setpci_boot_on_power.sh; chmod 755 /etc/local.d/50_setpci_boot_on_power.sh | Run that as root. Try out the resulting script. Then question the wisdom of running as root commands you found on a forum and do not understand. |
|
Back to top |
|
|
BoGun n00b
Joined: 16 Jul 2023 Posts: 12
|
Posted: Sun Jul 16, 2023 6:17 pm Post subject: |
|
|
No that doesn't work. I checked and permissions are as the other files in that directory.
But what about what is mentioned in that README you earlier mentioned, ie
"If a file in this directory is executable and it has a .start extension,
it will be run when the local service is started. If a file is
executable and it has a .stop extension, it will be run when the local
service is stopped."
The file you just helped me with creating has a .sh extension? I mean it clearly states "If a file in this directory is executable and it has a .start extension[u],it will be run when the local service is started." Nothing about that other file extensions will be run at start. Pardon me if my question is dumb. |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 22578
|
Posted: Sun Jul 16, 2023 6:37 pm Post subject: |
|
|
No, your question is good. .sh is a typical extension for shell scripts, and when I wrote up a sample command for you, I forgot that this directory is special, so I used .sh out of habit, which means my command will not work as written. For this use case, the name needs to end in .start. A revised (and still untested) command: Code: | printf '%s\n' '#!/bin/sh' 'setpci -s 00:03.0 0x7b.b=0x19' > /etc/local.d/50_setpci_boot_on_power.start; chmod 755 /etc/local.d/50_setpci_boot_on_power.start | You can remove the .sh file created by my prior command. Alternately, instead of running my new code block, run mv /etc/local.d/50_setpci_boot_on_power.sh /etc/local.d/50_setpci_boot_on_power.start to move the existing script to a usable name. |
|
Back to top |
|
|
BoGun n00b
Joined: 16 Jul 2023 Posts: 12
|
Posted: Sun Jul 16, 2023 7:52 pm Post subject: |
|
|
Success!!
Fantastic this "boot at power failure thing" as been bugging me for such a long time I'm so happy it's finally solved.
Dear friend, thank you so much!
May I ask one question more, during the time after the first attempt and your correction I was checking out those other files in the local.d directory and their startline is #! /bin/bash while your script starts with #!/bin/sh ...may I ask what's the difference?
I found this in Gentoo wiki : "In Gentoo, the /bin/sh file is a symlink to the default system shell, and as such can link to one of several different POSIX shells. After following the Handbook, the default shell will be bash"
but also this : "GNU Bash (Bourne-again shell) is the default shell on Gentoo systems and a popular shell program found on many Linux systems. "
But all though I can perfectly read english I don't understand what that tells me.
I understand from the file you helped me with creating, that making what initiated people call a "script" likely must have some sort of "start" to work as expected.
So I kind of thinking of that first line as sort of hitting enter after a command in CLI ...could that be a fairly accurate simile?
But as I said earlier, "i don't know shit" so please forgive my dumb questions.
Once again thank you very much for your kind assistance! |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 22578
|
Posted: Sun Jul 16, 2023 9:47 pm Post subject: |
|
|
BoGun wrote: | Fantastic this "boot at power failure thing" as been bugging me for such a long time I'm so happy it's finally solved. | May I ask why this matters so much? My understanding is that this only applies at all if your system crashes due to the electrical provider ceasing to provide power. I would be more worried about why you have power failures so frequently. Secondarily, why does the system need to automatically restart when power is restored? BoGun wrote: | May I ask one question more, during the time after the first attempt and your correction I was checking out those other files in the local.d directory and their startline is #! /bin/bash while your script starts with #!/bin/sh ...may I ask what's the difference? | Sometimes there is none. When /bin/sh is /bin/bash, you get almost the same result either way. (In some specific cases, GNU Bash may behave differently if called as /bin/sh. For this discussion, we can ignore that.) For the very simple use you wanted, any POSIX Bourne shell will work, so any implementation of /bin/sh is acceptable. For scripts which use GNU Bash specific features, the more specific /bin/bash must be used, so that the script always gets GNU Bash, even when /bin/sh is not /bin/bash. BoGun wrote: | I found this in Gentoo wiki : "In Gentoo, the /bin/sh file is a symlink to the default system shell, and as such can link to one of several different POSIX shells. After following the Handbook, the default shell will be bash"
but also this : "GNU Bash (Bourne-again shell) is the default shell on Gentoo systems and a popular shell program found on many Linux systems. "
But all though I can perfectly read english I don't understand what that tells me. | Some people may choose to point /bin/sh to some other Bourne shell, such as dash. Gentoo's default is to use bash, because it is widely understood and relatively powerful. BoGun wrote: | So I kind of thinking of that first line as sort of hitting enter after a command in CLI ...could that be a fairly accurate simile? | When you run a program, if it is not an executable, then it can be a script that starts with #!, then a path to an executable that can be invoked to interpret the script. This causes the kernel to invoke the named interpreter and pass it the script filename as an argument. For this example, we picked /bin/sh because your needs were simple. Execute a specific command, with fixed arguments. You did not need text processing, nor file redirections, nor conditional logic. If you needed a much more powerful language, we could have used /usr/bin/python to make the Python interpreter load this script, giving you the full power of the Python programming language. |
|
Back to top |
|
|
BoGun n00b
Joined: 16 Jul 2023 Posts: 12
|
Posted: Mon Jul 17, 2023 8:41 am Post subject: |
|
|
Ah ok, so do I understand it right if I say that start with only #! is like a "shortcut" to point to some other directory like for instance your example /usr/bin/python?
Could it then point to any directory or is there restrictions? And also, would /bin/bash have worked just as good in this scipt you helped with?
Re. the power failure thing, no problems with power in the country I live. It all come downs to that I would like to remotely control things, "home automation" is the popular name I think. I have Z-wave and 433MHz power plugs for all kinds of stuff. The Daphile Mac minii is part of my home HiFi system together with an external DAC.
And yeah,I'm fully aware of "suspend and WOL" but I have choosen a different path. The mini can be gracefully shutdown and then one cut the power with a plug and when power comes back it turns on again. The system doesn't need to "crash" so to speak from a power failure. It works just as good with a normal shutdown. |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 22578
|
Posted: Mon Jul 17, 2023 4:00 pm Post subject: |
|
|
BoGun wrote: | Ah ok, so do I understand it right if I say that start with only #! is like a "shortcut" to point to some other directory like for instance your example /usr/bin/python? | I would say interpreter rather than directory, but yes. This shortcut enables the caller to run the file as if it were a freestanding executable (as by running /etc/local.d/50_setpci_boot_on_power.start), rather than needing to know that it is a shell script that must be invoked as /bin/sh /etc/local.d/50_setpci_boot_on_power.start. This is particularly convenient for a collection directory like this, where the caller can execute each file in the directory in turn, without caring whether they are native executables, shell scripts, Python scripts, etc.
BoGun wrote: | Could it then point to any directory or is there restrictions? | It must point to a native executable, which can be executed by the current user. For example, you cannot point it to /etc/issue and expect anything to happen, since /etc/issue is not executable. See Wikipedia: Shebang for details. BoGun wrote: | And also, would /bin/bash have worked just as good in this scipt you helped with? | Yes, for two reasons. GNU Bash scripting is heavily derived from Bourne scripting, so most (perhaps all, but I cannot guarantee that) valid Bourne scripts are also valid Bash scripts, with the same semantics. Your requirement was so simple that it is easily implemented with basic Bourne script, so any shell that can read Bourne would work.
As a second reason, there is a good chance that on your system /bin/sh is a symlink to /bin/bash, in which case using #!/bin/sh is a longer way of stating #!/bin/bash. (It is longer since the kernel needs to resolve the sh -> bash symlink.) BoGun wrote: | Re. the power failure thing, no problems with power in the country I live. ... | I see. That is an interesting use of the functionality that I had not considered. I so rarely see remotely controllable power supplies that I tend to think of wall power as being guaranteed except when the utility cuts out or someone manually turns off the power strip via a physical button, and in the latter case, anyone who can turn the strip on is directly present to power up the computer, too. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|