From: [email protected]

begin Stephen Gran schrieb am Thu 19. Aug, 14:27 (-0400) :

This one time, at band camp, J�rg Sommer said:

What doesn't match your requests in my version of the script? It handles the mount and /p/mounts problem by falling back to the old behaviour.
Well, it is not callable direct, but don't think other one-time scripts like bootmisc or bootclean do so.

The problem is that it adds complexity without adding functionality,
at least in my setting. That seems like a drawback to me. If I/we
can figure out a way to address the fact that /proc/mounts dumps out
the wrong information,

I googled a little bit and found this:

http://lists.debian.org/debian-user/2004/03/msg17601.html

This problem concerns much more packages and programs. http://www.google.de/search?q=%2Fdev2%2Froot2&ie=UTF8

I think ultimately we need to find a way to transform the output of /proc/mounts into something useful, or put a marker in /etc/hdparm.conf (ROOT_FS=/dev/hda1 or something). If this is done, then I like your approach.

Yes, this might be a solution.

Have a nice weekend.

Bye, J�rg.
end.
--
Thema: Der FSR bringt die Evalusationshefte erst ein Semester nach der Evaluation raus.
Prof: Was will man auch von Leuten erwarten, die f�r ihre Arbeit nicht
bezahlt werden.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBJga1Oyr72Bm2GZcRAmSBAJsE+h8k57PLehph4RD/OMhT8i6AIACcCbHH oZ1JYzXvm0zPkZILBbUXjTE=
=1wjC
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

begin Stephen Gran schrieb am Thu 12. Aug, 00:03 (-0400) :

This one time, at band camp, J�rg Sommer said:

begin Stephen Gran schrieb am Sun 08. Aug, 18:20 (-0400) :

Yes, the test -e is exactly the problem. test -e rootfs is not true,
so $ROOT_FS remains unset.

Well, this is a mistake. I toke the assumtion a root fs is ever existing. But on the other hand, this cause is caught by "case $ROOT_DEV in *)"

Reading from /proc/mounts gives a broken answer, and so there's 2 choices:
hdparm does not run on the root fs before it is mounted, or
hdparm runs on all drives twice.

No. I would prever the old way, that all is run early at boot time.

Agreed, however there is a third way - I realize. Read from the output
of mount(1), instead of /proc/mounts. This gives accurate information
about what is mounted where, in a very compatible way.

Sure? The first time hdparm should run is before the rootfs is mounted
rw, so mount could never access /etc/mtab before and write there any
valid informations.

I also am uneasy about the the end user running
/etc/init.d/hdparm start, and not having all their drives processed -
not that they should be doing this frequently, but it seems
counterintuitive otherwise.

This can be caught by the same mechanism without printing the warning the rootfs isn't found. I see the greater problem, how you will find out it
the script is run by hand or by init. i.e. I use invoke-rc.d to restart
reload a process.

Maybe you use restart/reload for this. The normal user shouldn't call start/stop and use restart/reload instead.

I think the last script I sent does the following:
If run as /etc/rcS/S06hdparm.first,

Beware of relying on symlink names. I use file-rc and this doesn't call S06hdparm.first. There aren't any symlinks so the scripts called from /etc/init.d/ - like users do.

it only runs on the root disk, but
reads from mount, rather than /proc

So it may use invalid data. see above. What happens, if you delete the
line of the rootfs from /etc/mtab and then reboot.

If run as /etc/rcS/S29hdparm, it does the rest of your disks, skipping
the root disk
If run as /etc/init.d/hdparm, it runs on all disks.
Also includes new parser code to allow people to put straight hdparm
lines in hdparm.conf in the following format:
command_line {
hdparm (options) /dev/hda
}

Which I think is a nice addition.

Do you have an example? I don't understand what should happen.

Bye, J�rg.
end.
--
Wer eher stirbt ist l�nger tot.
(Un B. Kant)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBG2tAOyr72Bm2GZcRAvWJAJ427AIGmQGSEanbuno4Z10pr5uCVwCfex/j MzkjDqXIlgw/2ULVGXVUcHk=
=/1OM
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

This one time, at band camp, J�rg Sommer said:

begin Stephen Gran schrieb am Thu 12. Aug, 00:03 (-0400) :

Sure? The first time hdparm should run is before the rootfs is mounted
rw, so mount could never access /etc/mtab before and write there any
valid informations.

Right, but I think mount still does the right thing in this case.

I also am uneasy about the the end user running
/etc/init.d/hdparm start, and not having all their drives processed -
not that they should be doing this frequently, but it seems counterintuitive otherwise.

This can be caught by the same mechanism without printing the warning the rootfs isn't found. I see the greater problem, how you will find out it
the script is run by hand or by init. i.e. I use invoke-rc.d to restart reload a process.

Yes, this is what I'm trying to solve.

I think the last script I sent does the following:
If run as /etc/rcS/S06hdparm.first,

Beware of relying on symlink names. I use file-rc and this doesn't call S06hdparm.first. There aren't any symlinks so the scripts called from /etc/init.d/ - like users do.

Hadn't thought of this. Will need some consideration. Any pointers? I suppose $PPID or $$ could be checked, but I think those are bashisms
(not that the script isn't already ridiculously bash-specific, but ... :)

it only runs on the root disk, but
reads from mount, rather than /proc

So it may use invalid data. see above. What happens, if you delete the
line of the rootfs from /etc/mtab and then reboot.

I will test when I'm done working today. I don't have time for a reboot
right now :)

Also includes new parser code to allow people to put straight hdparm
lines in hdparm.conf in the following format:

Do you have an example? I don't understand what should happen.

command_line {
hdparm -q -m16 -q -W0 -q -d1 /dev/hda
}

The command is run as is. Some people may prefer to just use straight
command line syntax, instead of rewriting what they already know into my attempt at user friendliness. Saves steps if you know hdparm.

--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : [email protected] |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBG3gASYIMHOpZA44RAsUfAJwLlWXgUnzUoHUafR5vlp4hFpmznwCfWs10 ScAHemXrYgG+NO10+FZ08Bw=
=0XzZ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

This one time, at band camp, J�rg Sommer said:

begin Stephen Gran schrieb am Thu 12. Aug, 00:03 (-0400) :

Agreed, however there is a third way - I realize. Read from the output
of mount(1), instead of /proc/mounts. This gives accurate information about what is mounted where, in a very compatible way.

Sure? The first time hdparm should run is before the rootfs is mounted
rw, so mount could never access /etc/mtab before and write there any
valid informations.

You are correct - editing mtab and rebooting gave invalid results (well,
it gave the 'will run on all' result).

So, where to from here? /proc/mounts gives invalid information for 2.6 kernels, and mount can't be relied on to be accurate. Coupled with that,
the use of file-rc makes it difficult to guess what is calling the script.

Hrmph.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : [email protected] |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBHDi1SYIMHOpZA44RAsLJAJ9+1ElBQ62hBwQx1IKm2yGAxCkMPwCgvC5t Vqs1afMKUUsQJ8noP2EokUo=
=xtIZ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)