Drobo

Cross-compiling for DroboFS: bash 4.1

Hi everyone,

Here is another post on the cross-compile series for DroboFS.

Introduction: Why bash?

It is my favorite shell environment. YMMV.

Overall compiling complexity: Easy.

Step 1: Background info

To be able to make use of this post, you need a VM configured as indicated in this post.

Step 2: Enter the cross-compiling environment

See step 2 of this post to see instructions on how to enter the chroot environment.

Step 3: Dependencies

As far as I can remember, bash has no dependencies.

Step 4: Get the source code

bash’s website: http://www.gnu.org/software/bash/
Version: 4.1
Direct link: http://ftp.gnu.org/gnu/bash/bash-4.1.tar.gz

Make sure that you are in the folder /root/code, then type:

wget http://ftp.gnu.org/gnu/bash/bash-4.1.tar.gz tar zxf bash-4.1.tar.gz cd bash-4.1

Step 5: Configuration

The traditional configure command applies:

./configure --host=arm-none-linux-gnueabi --prefix=/usr/arm

This should return no errors. If it does, you have to check if you have all required packages in your chroot (although, if you have been following the dependencies, you should have all of them).

Step 6: Compiling

Within the folder /root/code/bash-4.1:

make

Again, there should be no errors. If any errors are reported, make sure you performed steps 3 and 4 correctly. If you still have errors, make sure that the VM is properly configured (e.g. like I did the first time around, when I got the wrong toolchain, or forgot to ‘export’ the proper compiler flags).

Step 6: Installing

As simple as it gets:

make install

…which will place the compiled library under /usr/arm.

Then we package the whole /usr/arm and copy it over to the DroboFS, as indicated on step 9 here.

As an additional step, I would copy /usr/arm/bin/bash to /bin/bash on the DroboFS, so that if you ever lose your disk pack you’d still be able to log in through SSH.

Changing the default shell for the root account is left as an exercise to the reader, since there is a lot of feedback from DR employees not to do that unless you really, really know what you are doing.

Congratulations!

Now you can run bash on your DroboFS.

When I try to run bash on the drobo, I get this:

# ./bash ./bash: line 1: syntax error: unexpected word (expecting ")")
It runs just fine on my VM though. I guess it isn’t cross-compiling?

EDIT: I got it, apparently running export commands in a .sh file doesn’t export them for the user. I feel empowered now.

I’m considering doing this - although it’s quite a bit of setup if one is only interested in bash (I understand the value of having the environment later, if more packages are desired). I don’t suppose there’s any way to package this up in a DroboApp like was done with OpenSSH is there?

I don’t know the structure of DroboApps or the number of dependencies involved for bash, so for all I know what I’m asking could be trivial or hellish.

Sure, anything can be packaged as a DroboApp. The problem is that this one in particular requires you to make a permanent change to a crucial system configuration file: /etc/passwd.

In other words, if you install bash and change /etc/passwd to make it your default shell, then you can never remove the bash DroboApp, or at least not until you set /etc/passwd back the way it was.

The odds of someone accidentally deciding that they no longer need bash, coupled with the fact that there isn’t a good way for an app to be warned that it is being uninstalled, make for a very dangerous setup.

I’d rather let it be the way it is right now than to provide something that is akin to give young children a pair of pointy scissors and tell them to run with it…

It is either that or packaging it in a way that cannot be uninstalled, which also makes me quite uncomfortable.

What I can do, though, is to make the bash binary available for download somewhere. That way only someone who really knows what they are doing could use it, but without having to setup the whole cross-compile environment.

Would it be possible to package up bash without the /etc/passwd portion modification, or document how to go about that (I’m half guessing you’ll point me to another thread of yours :slight_smile: )? Given those exact risks you mentioned, I was planning on running it manually each login. And of course, specifying it in shell scripts (which is where I need it most).

People can decide on their own if they’re brave enough to muck with /etc/passwd that way. :slight_smile: