On Tuesday 19 September 2006 23:42, Steve Langasek wrote: > It would be equally valid to say that aoetools does not support > automounting, and therefore /usr/sbin is appropriate.
So you're saying that a person that has an aoe driven SAN should have to mount it by doing something like: mount /dev/etherd/e1.1 /exports/blah This doesn't make any sense. The point of the aoetools is to make using the aoe devices possible. Making them manual boot only seems somewhat suboptimal. The closest thing I could conceive to this is if the device mapper had to be manually setup on boot instead of having scripts that setup the lvm and evms stuff. Those subsystems provide block devices just like the aoetools. > So I don't believe this makes the package completely unusable, and is not a > reason to exclude the package from release if it goes unfixed. I guess it technically provides more functionality than nothing, but it's pretty near useless in a production environment where a machine should be expected to boot without intervention. However, I guess I can agree that it doesn't cause additional problems by being installed. I think it is RC bug in that it provides basic boot functionality and is not on the root volume. I have the init script (/etc/init.d/aoe) and the default config file (/etc/default/aoetools) being tested on a dev server right now. I have it where it can be mounted upon boot. I will attach them to #387552 asap. I will attach versions that assume the binaries are in /sbin since assuming they are on /usr/sbin would require making sure /usr is mounted if it is not on the root volume, which I think is wrong. I mean, what if I wanted to put /usr on the aoe device? I couldn't unless all the tools required to set it up were on the root volume. Thanks, wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
