Cerberus Alpha: Remastering the OS to Load the Program on Boot (Part 2)

Hello! I decided to take a break from the project, and the write up, because I got really busy at work and had to do some traveling. I will get back to the project when I can, but for now I'm going to fill in the rest of the write up while I can. I'm going off of memory at this point, so some things might be less detailed than I'd like.

When we last left off, I had finally discovered the correct method for integrating my program into the remastered iso of TinyCore Linux. The next step was to find the correct place in the boot process to load the program. Some of this really happened side by side, but I thought it would be better to describe the process in two parts. This was really a learning process for me because I needed to find the right time to run my script and TinyCore seems to have an atypical boot up process.

As mentioned previously, my first attempt was to place cerba.sh in /opt/ and modify /opt/bootlocal.sh to start cerba. According to the TinyCore Linux wiki, bootlocal.sh is run "later in the boot process." Unfortunately, it was not late enough. I tried a few implementations of this (changing around the order in bootlocal.sh), but they never worked. The behavior was that it would start cerba.sh, but the behavior was that it would run in an infinite loop (at the main menu) and ignore user input. It seems as though the bash interpreter was not yet running and that bootlocal.sh is more for things like selecting the keyboard layout.

If you search around the internet a bit, the bootlocal.sh option is mentioned a few places, as is placing your script in .X.d to boot, but this would not work because that only runs after the X window system has started and I did not want to wait for that process. My next attempt was to place start cerba from /root/.profile. This was good because it ran the script as root user, but it still had the flashing / looping issue. I tried /tc/.profile (tc is the default login user), but it still had the flashing issue. Another issue that I had was when calling on the script from the .profile I originally placed "exit" at the end of cerba's quit function. This would either exit the boot process entirely, or it would log out the existing user, interrupting the boot process awkwardly. There were other issues encountered that revolved around mounting the file systems and other commands in the script, but I can't quite remember when they were resolved. Either way, it had to do with running cerba at the correct time once all the utilities had loaded.

My next attempt was something that I had to do a little digging to figure out, but once I had it this was essentially the correct solution. I put the script in /etc/profile.d/ and this time it ran correctly without any errors (related to its placement in the boot process at least), except for one. When the program ran, it worked fine, but when I chose to "quit" from the program it would rerun itself! As it turns out, the program was being started from /etc/profile.d/ every time the user logged in, so when I quit the program it tried to login again and reran cerba. My simple solution to this was to place cerbastart.sh which was simply a script that did "sudo cerba" and then "rm /etc/profile.d/cerbastart.sh ." This was my way of ensuring that the program ran once and only once during the initial login. The added benefit of this is that cerba will run once and then continue to boot normally, including into the X window system if that boot option is chosen.

Around this time I placed a copy of the script as /usr/bin/cerba which meant that I could run the program just by entering "cerba" in the terminal. Every thing seemed to be working perfectly so I burnt a test CD and tried it out on my machine at home. When I ran it, though, there was an error about the file system being write protected! This was my next major hurtle, and later the problem of letter case would raise its ugly head again.