Kindle 3 sysvinit scripts

[Feathers_McGraw]

I have installed optware on my kindle 3, which works fine when I manually mount the filesystem, but I'd like to automount it at startup.

The wiki page (https://wiki.mobileread.com/wiki/Optware) has an init script (/etc/init.d/optmount), which I've copied here for reference:

#!/bin/sh
 
 _FUNCTIONS=/etc/rc.d/functions
 [ -f ${_FUNCTIONS} ] && . ${_FUNCTIONS}
 
 mount_us()
 {
         /bin/mount /mnt/us/optware.ext3
 }
 
 umount_us()
 {
         /bin/umount -d /mnt/us/optware.ext3
 }
 
 case "$1" in
         start)
                 mount_us
                 ;;
         stop)
                 umount_us
                 ;;
 
         restart|force-reload)
                 :
                 ;;
         *)
         msg "usage: /etc/init.d/$NAME {start|stop}" W >&2
                 exit 1
                 ;;
 
 esac
 
 exit 0

The script works fine when I run it manually, but I'd like to run it at startup. The wiki says:

Once done, create the appropriate sysvinit symlinks under /etc/RcS.d (Startup), /etc/Rc6.d (Restart) and /etc/Rc0.d (Shutdown)

I've created these symlinks:

ln -s /etc/init.d/optmount  /etc/rc.d/optmount
ln -s /etc/init.d/optmount  /etc/rc6.d/optmount
ln -s /etc/init.d/optmount  /etc/rcS.d/optmount

But the filesystem doesn't get auto-mounted when I reboot. My first thought was to change options in /etc/fstab to ...,auto,nofail, but I don't think that will work because the "filesystem" is a file on /mnt/us, so it has to be mounted after the internal storage...

Do I have to name the symlinks in /etc/rc*.d/ differently so that the names match the option I want to use (start, stop, restart) like how the symlinks reboot, shutdown, poweroff all point to systemctl in distros with systemd as init system, and the name the program was called as is used as the argument? Or do all of the scripts in those folders get called with additional options anyway?

Can anyone give me a pointer in the right direction? Any more information about the init process on Kindle would be great too, I'd love to learn it in detail. I've been running linux on the server for >3 years but never looked into sysvinit, despite the switch to systemd you still find it everywhere in embedded devices.

[HarryT]

Questions such as this belong in the dev forum, to where I'm now moving it.

[knc1]

Do not mount or symlink to anything or from anything in Visible USB mass storage (internally known as: /mnt/us).
It is a fuse file system on top of a FAT-32 file system and you can never be certain of its status, in fact, it might not even be present when you most want it.

Use the /var/local partition, it is always there beginning early in the boot sequence.

[Feathers_McGraw]

The /var/local partition is only 23.2M on my device, 20.6M of which is free, not sure that's enough for what I had in mind - the filesystem I created for optware was 250M and I thought that was on the small side!

Isn't mounting a filesystem contained in /mnt/us quite common? All of the optware and debian chroot posts and guides I've seen so far do that.

[knc1]

Originally Posted by Feathers_McGraw

The /var/local partition is only 23.2M on my device, 20.6M of which is free, not sure that's enough for what I had in mind - the filesystem I created for optware was 250M and I thought that was on the small side!

Isn't mounting a filesystem contained in /mnt/us quite common? All of the optware and debian chroot posts and guides I've seen so far do that.

"quite common" != correct or reliable nor recommended.

What happens when you try to run your little script while that file system is exported as USBMS?
Try it, you can always use Kubrick to un-brick it.

[Feathers_McGraw]

Yeah I take your point. Do you run a debian chroot or optware on any of your devices then? What do you do? I'm equally wary of filling up essential root partitions and bricking the device that way.

I hadn't considered what happens in that situation... would that really brick the device?

[knc1]

Originally Posted by Feathers_McGraw

Yeah I take your point. Do you run a debian chroot or optware on any of your devices then? What do you do? I'm equally wary of filling up essential root partitions and bricking the device that way.

I hadn't considered what happens in that situation... would that really brick the device?

It might disrupt the boot sequence enough so that it doesn't complete.

Question:
Why are you trying to run either a Debian chroot or Optware?

You must be reading some really, really old post on the Internet.
You know, the old "I read it on the Internet, it must be (still) true."

[Feathers_McGraw]

I'd like to have the ability to install standard commandline utilities on the kindle so I can use it for debugging servers, I quite like the eink screen for terminal work, and the battery life is killer.

[knc1]

Originally Posted by Feathers_McGraw

I'd like to have the ability to install standard commandline utilities on the kindle so I can use it for debugging servers, I quite like the eink screen for terminal work, and the battery life is killer.

The battery run-time on a single charge (assuming battery is in 'new' condition) is about 2 to 4 hours, depending.

You don't need either a chroot nor Optware to run what you want to run.

No insult intended, but . . . .

*) Linux, like nearly any other *nix system, uses ELF format binaries.
*) All ELF format systems support multiple, concurrent, system libraries.

A point overlooked, or unknown to the authors of all those old Debian chroot and Optware posts.

Translation:
You can just install binaries from your preferred Debian/ARMel release in the visible USB user mass storage area and run them from there.

twobob even wrote scripts that determine what dependencies are not already installed on the Kindle.

AND...
There is a 'standardized' file storage tree for USB mass storage.

You most likely will have to edit the interpreter entry and the rpath entry of the binaries.

But there is a tool for that (patchelf) - you can use Buildroot to build the most recent verison of patchelf for yourself.
In fact, you probably build all of the common things you want with the same run of a Buildroot instance.

You do have to deal with programs that expect a writable /etc and a persistent ~ for root.
But there is a good selection of ways to deal with those details.

I don't have a worked example for the K3 but the worked example for the 5.x series firmware is similar in principle.
See the thread:
ARMhf on Kindle
(or something like that, filter by my nickname and use ARMhf as a title keyword in your search here).

[Feathers_McGraw]

I know that's possible, but it's a lot less convenient IMO - as I see it, the choice is:

find all of the binaries I think I'll need in advance (probably won't think of them all), patch them all, update them manually etc.

vs

set up a functional package manger in a chroot, and then install whatever I need, when I need it, from a massive repo where everything "just works", with easy access to updates and dependencies...

[eschwartz]

Notwithstanding what knc1 said, you you might just really really want a chroot for some reason, so it is still interesting to know how to automount it.
(Package managers are one good reason.)

The most important thing to keep in mind, is that the Kindle uses Ubuntu's Upstart init system, so in the best case scenario your initscript did absolutely nothing regardless.
(/etc/init.d/ is not used by anything and I am unsure why it exists, /etc/rc*.d/ is basically empty and I am not really sure what they do either, /etc/init/ is a symlink to /etc/upstart/)

The following upstart service is what I use to start something (in this case, Aeris' KindleMenu launcher) after the Kindle has booted and the UI is properly initialized and everything:

[root@kindle root]# cat /etc/upstart/aeris_menu.conf
# vim: set ft=upstart:

start on framework_ready and started kb and started pillow
stop on stopping framework

export LANG LC_ALL

pre-start script
    /etc/upstart/aeris_menu &
end script

[fennectech]

Massive necrobump but for those who want to use this you need a simlink in /etc/rc5.d/ because the kindle's default runlevel is 5. I spent a few hours figuring this out The scripts in rc6.d are run at shutdown. And for those mentioning upstart The kindle 3 does not have it. Its pure sysvinit