Hi apventer,
Curious about what VirtualBox might have in the way of tools for examining, from
outside the box, what is going on
inside the box, I took it for a spin. First I downloaded the .sfs packaged by forum member "TheAsterisk!", and available here:
VirtualBox 4.2.12: SFS4 Module. After experimenting with that for awhile, I downloaded the latest "All distributions" version from the VirtualBox site (
VirtualBox Downloads) and built it on my Racy 5.2.2. (That was 4.2.16 early yesterday, the same as the version you tried. Today I see that sometime later yesterday they released 4.2.18.) Both 4.2.12 and 4.2.16 versions exhibited the same behavior that you described. For me they both hung after "Making the filesystem usable..." with Precise 5.6 and 5.7.1, but not with Slacko 5.5 or Precise 5.5. (All of these, like all Puppies I have ever tried, will boot fine on my hardware.)
I found that VirtualBox does have some very limited ability to examine what is going on inside the box -- well, more exactly, what
did go on inside the box at a certain point in time. That is to say that it allows you to take a "snapshot", which (among other things) contains the raw contents of RAM.
So, in theory, you could take a snapshot, examine the resulting file, find the layered filesystem within the RAM data, then find the /tmp/bootsysinit.log within the filesystem, and examine it. That, of course, would require learning the format of the snapshot file, learning where to look for the layered filesystem, and learning the format of the layered filesystem. Life is short. I opted for another method.
Since "Making the filesystem usable..." happens within /etc/rc.d/rc.sysinit, I opted to extract that file from the .iso file, add some debug code to it, and plug it back into the .iso file.
What I learned is that looking at /tmp/bootsysinit.log wouldn't have done any good in this case because the hang happens before an error message is logged.
What is happening is that rc.sysinit calls mount to mount /dev/shm. On Puppy, mount is a script. By adding a little debug code to that script, I found that it calls grep when setting $DASHOPTS, a list of options passed to mount. And grep never returns!
Further experimentation with the mount script showed that nothing called from that script would ever return when booting in VirtualBox.
Further experimentation with the rc.sysinit script showed that nothing called from
any script that is called from rc.sysinit would ever return when booting in VirtualBox.
Thus, adding a couple of scripts to /bin/:
script1
Code: Select all
#!/bin/sh
echo "script1 line2" >/dev/console
script2
echo "script1 line4" >/dev/console
script2
Code: Select all
#!/bin/sh
echo "script2 line2" >/dev/console
echo "script2 line3" >/dev/console
echo "script2 line4" >/dev/console
Then adding these lines early in rc.sysinit:
Code: Select all
echo "rc.sysinit line 95" >/dev/console
script1
echo "rc.sysinit line 97" >/dev/console
Will cause this output:
Code: Select all
rc.sysinit line 95
script1 line2
script2 line2
script2 line3
script2 line4
At that point, VirtualBox hangs and maxes the processor at whatever limit you have set in VirtualBox. So script2 never returns to allow script1 to complete, and so script1 never returns to allow rc.sysinit to complete.
Why does this problem appear with Precise 5.7.1 and not Slacko 5.3? I do not know. One possibility would be the kernel. When I noticed that Precise 5.7.1 is using the relatively recent 3.9.11 kernel compared to kernel 2.6.37.6 in Slacko 5.3, I guessed that that was likely the important difference. But then I noticed that the kernel in Precise 5.6, which also hangs in VirtualBox, is kernel 3.2.44, while Precise 5.5, which boots OK, has kernel 3.2.29, which certainly
could make a difference, but it seems less likely, especially since one would hope that if VirtualBox had serious issues with kernel 3.2.44 and newer that they would be resolved long before we got to kernel 3.9.11. Of course it is possible that if VirtualBox had issues with 3.2.44, whatever it didn't like happened to disappear in newer kernels and reappeared in 3.9.11 -- but that seems unlikely. So maybe the kernel is not the important difference here. But I don't know what is.
Anyway, if a machine running a Linux kernel that is known to be good is running a script which calls another script which is known to be good, and that script never returns, I think it is safe to say that the problem is likely to be in the machine, be it physical or virtual.
So, I could be wrong, but this does not appear to be a Puppy bug, nor a bug in any application contained in Puppy. If you still want to resolve this your best bet might be to contact the VirtualBox folks (
https://www.virtualbox.org/,
https://forums.virtualbox.org/). It would probably be a good idea to first try yesterday's new VirtualBox 4.2.18 in the off chance that it resolves the problem.