Hello!
How could I solve the **hdparm -B 255 /dev/sda **command automatically run at every boot time?
Thanks for your answers!
(Opensuse 12.2 64 bit; Western Digital HDD)
You could try an entry in your root’s crontab. In a teminal window do:
su -
crontab -e
(this will ask for the root password)
You will then see the current crontab (probably empty except for some comment lines) in a vi/vim session.
Scroll down with the down arrow key and type the small letter o. This will put you in INPUT mode (see the bottom of the window) on a new line. Then type the cron entry:
@reboot hdparm -B 255 /dev/sda >/dev/null 2>&1
(The expressions after the command are to supress all output).
Hit the Esc key to quit INPUT mode. Then type
:wq
Do not forget to give a Return at the end. This will put you in command mode (: at the bottom of the window) and then w will write the changed file to disk and q will quit vi.
Type
exit
to stop your root session.
It seems, this is working fine!
Thank you Vm!
You are welcome.
There is some problem yet: When I turn off the computer, the command doesn’t run at the next boot time. Your suggestion works, but only after restart (for example with the reset button). Is there a solution with the crontab editing?
I usually add commands in /etc/rc.d/boot.local. It states there: ‘Here you should add things, that should happen directly after booting before we’re going to the first run level.’ Mine looks like:
hdparm -B 254 /dev/sda &&
exit 0
But I am not sure if it still works with systemd. And when yes, for how long.
Well, to be honest I was a bit baffled by the fact that the crontab man page did (only) talk about @reboot. For two reasons:
- how can cron know if the system was rebooted or booted? I allways had the idea that reboot is something you say when a system runs, meaning: stop the system and then trigger the boot function of the BIOS and boot is triggering the BIOS boot function by switching the power on. And thus IMHO the system, once the booting started, never knows if it was done by what. Let alone that the Operating System knows such a thing.
- when there is a difference or one can find out if it was a boot or a reboot, why then only have a functionality for one of both?
Silly. I then in fact know no better answer then what nightwishfan posted. Only it then should be done in the new systemd way. I guess that is lready answered here on the forums somewhere. Have to search for it.
EDIT: while searching on the internet, everybody seems to simply think that an @reboot entry is executed every (re)boot. I start wondering what happens in your system???
On 01/25/2013 07:06 AM, hcvv wrote:
>
> nightwishfan;2521893 Wrote:
>> I usually add commands in /etc/rc.d/boot.local. It states there: ‘Here
>> you should add things, that should happen directly after booting before
>> we’re going to the first run level.’ Mine looks like:
>>>
> Code:
> --------------------
> > > hdparm -B 254 /dev/sda &&
> > exit 0
> --------------------
>>>
> But I am not sure if it still works with systemd. And when yes, for how
> long.
My impression is that ‘boot.local’ will be maintained with systemd. Any problems
will be with ‘after.local’ due to a lack of meaning for “after” in systemd.
In addition, scripts with with boot.local have a very restricted environment.
Always say “/sbin/hdparm” rather than “hdparm”. I always do the same for crontab
entries.
Thank you very much for the tip.
I was a bit irritated by the fact that I could not explain why a reboot is not the same as any other boot, ecxept from the fact that it is called so at shutdwon to differenciate it from a halt.
Thus I did the following test.
Entered the following to root’s crontab
ech "Boot at $(date)" >>/root/myrootlog
And then I:
- did from my real console (logical screen 1, I was not loged in in the GUI):
shutdown -r now
- did from my real console (logical screen 1, I was not loged in in the GUI):
shutdown -h now
-
powered on the system, waited for the login screen, loged in into KDE and used from the main Kmenu the Leave button and then Reboot.
-
waited for the login screen, loged in into KDE and use from the main Kmenu the Leave button and then Shutdown.
After all four I first checked /root/mybootlog. Every time there was one entry added. And now it is:
boven:~ # cat mybootlog
Boot at Fri Jan 25 16:36:19 CET 2013
Boot at Fri Jan 25 16:38:17 CET 2013
Boot at Fri Jan 25 16:43:28 CET 2013
Boot at Fri Jan 25 16:46:20 CET 2013
boven:~ #
I think I have thus proven that the @reboot entry in the crontab works for every boot.
Then of course the next thing is asking @menopausa, please describe better in which case your crontab entry is executed and in which case it isn’t. You are talking about a reset button or so, but normal shutdown (either with reboot or halt option for what should be done ater the shutdown) is done by using software inside your system (e.g. as shown above).
On 2013-01-25 15:17, Larry Finger wrote:
> My impression is that ‘boot.local’ will be maintained with systemd. Any
> problems will be with ‘after.local’ due to a lack of meaning for “after”
> in systemd.
Humans understand that meaning very well 
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
On 01/25/2013 03:08 PM, Carlos E. R. wrote:
> On 2013-01-25 15:17, Larry Finger wrote:
>> My impression is that ‘boot.local’ will be maintained with systemd. Any
>> problems will be with ‘after.local’ due to a lack of meaning for “after”
>> in systemd.
>
> Humans understand that meaning very well
I’m sure you understand the distinction, but “after” in systemv meant after all
the start-up scripts had been run. In systemd, it is much more difficult to
determine that point. You can wait until all the service requests have been
started, but is that sufficient? Yes and no - it depends.
On 2013-01-26 00:04, Larry Finger wrote:
> On 01/25/2013 03:08 PM, Carlos E. R. wrote:
>> On 2013-01-25 15:17, Larry Finger wrote:
>>> My impression is that ‘boot.local’ will be maintained with systemd. Any
>>> problems will be with ‘after.local’ due to a lack of meaning for “after”
>>> in systemd.
>>
>> Humans understand that meaning very well
>
> I’m sure you understand the distinction, but “after” in systemv meant
> after all the start-up scripts had been run. In systemd, it is much more
> difficult to determine that point. You can wait until all the service
> requests have been started, but is that sufficient? Yes and no - it
> depends.
I know, but you can try at a sensible point.
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
Why do you need to start service after everything else? Could you provide a single example where it must be started after everything?
On 2013-01-26 12:46, arvidjaar wrote:
>
> robin_listas;2522073 Wrote:
>> I know, but you can try at a sensible point.
>>
>
> Why do you need to start service after everything else? Could you
> provide a single example where it must be started after everything?
My current after.local contains this:
#! /bin/bash
if test -n "$failed" ; then
cat /usr/share/sounds/au/computer.au > /dev/audio &
else
cat /usr/share/sounds/au/hal9.au > /dev/audio &
fi
and it only makes sense when all the scripts have finished.
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
OK
cat > /etc/systemd/system/late.service << EOF
[Unit]
Description=Very Late Service
After=multi-user.target graphical.target
[Service]
Type=oneshot
ExecStart=...
[Install]
WantedBy=milti-user.target graphical.target
EOF
systemctl enable late.service
Adjust ExecStart to taste.
On 2013-01-26 15:46, arvidjaar wrote:
>
> OK
> Code:
> --------------------
> cat > /etc/systemd/system/late.service << EOF
> [Unit]
> Description=Very Late Service
> After=multi-user.target graphical.target
>
> [Service]
> Type=oneshot
> ExecStart=…
>
> [Install]
> WantedBy=milti-user.target graphical.target
> EOF
> systemctl enable late.service
> --------------------
>
> Adjust ExecStart to taste.
multi-user.target is level 3?
I’ll take a note of this for reference.
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
That’s the closest match to “level 3” you get with systemd, yes.
I understand that you say, and I accept your opinion what’s more I think the same…but my hdd still make a clicking noise until I run the command in the terminal. The “hdparm -i” has the following output:
Model=WDC WD7500BPVT-22HXZT3, FwRev=01.01A01, SerialNo=WD-WXU1EB1KKPED
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=1465149168
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: unknown setting WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7
- signifies the current active mode
This is intresting because the command set the APM level 255 (or not?), and it shows APM= “unknown setting”. Even more intresting however the hdd doesn’t make the clicking noise. I don’t understand it.
ps.: I have tried editing the boot.local, that didn’t work too.