TC fails to load extensions on my target hardware, but works in VirtualBox

[adam10603]

So I made a super basic installation (with tc-install from within TinyCore). Basically it's only Core + some extensions that I wish to use, which are supposed to be loaded at boot time. If I boot up the resulting image in VirtualBox, it works just fine, it loads my extensions on boot. But if I boot from the exact same image on my target hardware, it simply doesn't load my extensions. But the strangest thing is that if I manually load the extensions with "tce-load -i <filename>" after the OS has booted up, they work! They get loaded no problem. They only fail to load automatically at boot time. But again, they do load at boot time if I use the same image file to boot in VirtualBox, which I don't understand. My "onboot.lst" file contains the list of extensions to load, and I specified the "tce" switch correctly when using "tc-install". I uploaded the image files to Google Drive, so you can take a look yourself:

https://drive.google.com/file/d/0ByZv2ebI0aO4aF9fdWU5c0htVWc/view?usp=sharing

There are two files inside:
"tc_vbox.vdi" is a VirtualBox-ready hard disk image. Just attach it to a VirtualBox machine, and boot from it.
"tc_raw.img" has the exact same contents, but instead of a VirtualBox image, it's a raw image file. Copy it with a tool like "dd" to any storage device, and you should be able to boot from it. Note: you might have to run "sudo fsck.ext4 /dev/sda1" after the first boot on an actual machine to fix the partition.

As you can see it loads my extensions without any problem at boot time (you can test if they were loaded by trying to launch nano, as it's one of the extensions). Everything seems to work nicely in VB, but whenever I boot the same thing on my actual target machine, it fails to load my extensions. But again, I AM able to load them manually after the OS has booted. This is the strange part 

Btw, my target machine is a 266Mhz embedded x86 board, with 128MB of ram, so it's not the fastest thing in the world. Maybe this is some sort of a timing issue? I have no idea.

I attached an image that shows what I have in my extensions directory. Everything seems normal there.

[Misalf]

I think the  waitusb  boot code can be used to force the boot process to sleep for a while by not specifying the device.
Try adding  waitusb=5  to your boot loader's config file.

[adam10603]

I'm not booting from usb. I'm using another TC installation on an usb drive to copy the raw image file to the device's internal storage with dd, then the device boots from that. But I'll try it anyway, thanks.

[Misalf]

Yeah, the  waitusb  boot code waits for a specified amount of seconds for a specified device to be ready.
If no device is specified, it just blindly makes the boot process sleep for the specified amount of seconds.

If it doesn't work, you might increase the number of seconds. If it does, decrease.

[curaga]

Despite the name, it's useful for other slow devices. I remember someone had a SCSI cdrom.

[Juanito]

That would be me, but (sadly) it's gone now 

[adam10603]

Okay, I tried waitusb=15, and I got very interesting results. (Actually maybe this has nothing to do with using that switch, but it simply could have occurred at the same time by coincidence.) It sometimes loads my extensions. To be more precise, each installation is sort of predetermined to load them or not. After I install TC on my machine, that installation either always or never loads my extensions. If I install it again, that installation might behave differently. Here's what I'm doing:

(this part is not very important, feel free to skip it)
Basically what I want is to get TC running on that little embedded x86 board that I showed earlier (it's actually called an x-board), and each time it boots, it would automatically run a program that does stuff that I need. Here's my work flow:
I'm using a VirtualBox machine (on my laptop) that boots into Tiny Core with these extensions: tc-install, nano, compiletc, so I can compile stuff and make TC installations from within that virtual machine. That virtual machine also has an additional virtual hard disk attached to it, which is the exact same size as the x-board's internal flash storage. So what I do is I boot up my virtual machine, install TC (using tc-install) onto the secondary virtual hard drive, then compile my source code to make my executable, mount that secondary drive, run a shell script that patches core.gz on that drive (it unpacks it, includes my executable, places some startup scripts in there so it starts automatically, then packs it back up), and that's it. After this what I'm left with is a .vdi file that has what I want on my x-board. Next I convert the .vdi file to a raw image file (VirtualBox has some command line tools to do that), then I place that file onto a USB drive, which has a little bootable TC-based tool on it that backs up and restores the x-board's flash storage to/from raw image files (it's using dd internally). So I plug in this USB drive, the x-board boots form it, then I use that tool that I've booted up to copy my image file onto the x-board's flash storage, remove my USB drive, and reboot. At this point the x-board boots into the TC installation I have created in VirtualBox earlier.
I know this workflow is a little funky, but whatever

The important bit:

So I observed a strange thing. Once I boot up the x-board for the first time after all this, it either just works (which means it loads my extensions as well), or it doesn't. When it does work, the "waiting as requested... 5" does not count down! Even though it waits, the number doesn't decrease. But when it doesn't work, here's what happens: the number after that message counts down normally, then after some other messages I get something like "checksum for group 0 failed". It's basically a mounting error, it fails to mount the main storage, because some checksum values don't match up. At this point, if I run "fsck.ext4 /dev/sda1" and tell it to fix everything on the partition, it does mount successfully the next time I boot. However, TC still won't load my extensions from it!

I sort of get why this is happening. Since I don't install TC directly onto the x-board with tc-install, but rather to another (virtual) drive that I clone to the x-board afterwards, I guess the UUIDs or something like that just don't match up. But then why is it that sometimes it works? And also, why can't "fsck" fix this properly? I'm confused. 

[curaga]

The countdown halting is expected, when the desired UUID shows up the wait is aborted. You might try removing the UUIDs from the boot line altogether, leaving waitusb=5.

Ext4 errors would likely be from uncleanly shutting down your Virtualbox instance where you prepared the disk? It's also possible your flash is going bad, right in those crucial blocks. Maybe you have a way to check that?

[adam10603]

I don't have UUIDs specified in the boot options. Also, I'm paying attention to shutting down the VB machine properly: after I'm done preparing my installation, I unmount that drive, then I shut the machine down properly from within the OS. Copying the image to the x-board could be an issue, I have no idea. The tool I'm using simply uses dd internally to copy the image file to the x-board, and it displays a progress bar while the process is going. It doesn't quit immaturely or anything, since waits for dd to finish up by regularly checking what "pidof dd" says, and whenever it doesn't return any number, it assumes that dd has finished and only then it quits. That's how my tool works. Should be fine.

Although I think I've come across something: if I copy the exact same image file twice in a row to the x-board it seems to work. I'm still testing that, but so far that's what I'm seeing. Very interesting...

What I could do to verify the copying process is to copy back the contents of the x-board to a different image file after I copied the original one onto it, then compare the two files' SHA1 hashes or something like that. There's a problem though. The virtual hard drive I'm using (therefore the image file I'm copying to the x-board) is not exactly the same size as the x-boards flash storage. It's about half a megabyte short of it. The reason for that is that VirtualBox won't let me specify a virtual hard disk size in bytes, but rather only megabytes, and this is the closest I could get it without making it bigger. So if I would copy the whole thing back using dd, that file would be slightly larger, making the SHA1 hashes differ, even if the contents are the same. Maybe I could write a program that checks the size of the original image file, and copies exactly that many bytes from the second one to a new file, so I compare the original to that. But this seems overly complicated, and I suppose there's an easier method 

[curaga]

You can use dd to copy just N bytes. dd if=/dev/foo of=file bs=1 count=123456

[adam10603]

I think I'm just gonna copy the image file twice to the device. That seems to work.

I have a completely unrelated question now:

There's a program that needs to start up at boot time, which I've written in C++. Basically it needs to sync the system time every once in a while, and send it over to another device via serial. If I launch the program manually after TC has booted up, it works perfectly fine. However, if I launch it from any startup script, it fails to sync the system time. I tried launching the program from many different startup scripts like /etc/init.d/tc-config, /opt/bootlocal.sh, /home/tc/.profile, and a bunch of other ones as well, but non of them work. I mean the program does start up, but it fails to sync the system time. If I quit it, land back at the shell, and launch it again manually, it succeeds. This is super weird. The program works by calling the "system" function (in case you're not a programmer, what this does is it executes whatever command you give it on /bin/sh) with this command: "sudo ntpd -q -N -n -p 1.pool.ntp.org". What this does is it syncs the system time once, without creating a daemon, then after the time is set, it quits. In theory this is all fine, plus if I launch my program manually, it also works, but it doesn't whenever it's being launched from any startup script.

Any ideas?  The program does have root privileges whenever a startup script launches it, I tested that, so a missing "sudo" is not the problem.

Edit:

I found what the issue is. There's no internet connection yet when the startup scripts launch my program. But why?  I tried many different scripts, that are executed as late in the boot process as possible, but it still doesn't work. Should I just put a manual delay in there before launching my program? That's a little funky... 

[adam10603]

Okay, I solved it. I modified my program so that it waits until it detects an internet connection. It's all fine now. And for the original problem, I didn't quite solve it, but this little workaround seems to work nicely. That is to copy the image file onto the device twice. Weird, but that makes it work.

So everything's good now. Thanks for the help! 

[Rich]

Hi adam10603
For future reference, if you need to defer starting a program until after the network is up you can:

If you are running a GUI, the simplest fix is to create a file in the  .X.d  directory containing the command to start your
program.

If you are not running a GUI, place the following in bootlocal.sh:

Code: [Select]

SEC=60
while [ $SEC -gt 0 ] ; do
   ifconfig | grep "inet addr:" | grep -qv "127.0.0.1" && break
   sleep 1
done
*** Place the command to start your progrm here. ***