I have installed Virtualbox 4.2.16 r86992.
I created a VM with 512MB of RAM, an 8GB IDE harddisk and CD ROM.
I connect the Precise-5.7.1.iso to the CD. When I start the Virtual Machine, Puppy completes the first 5 steps of booting and then hangs at "Making the filesystem usable...".
The same thing happens when booting off precise-5.6.1.iso.
When booting off slacko-5.3-MAIN.iso, everything works!
What can I do about this problem?
Virtualbox Puppy 5.7.1 hangs
Not knowing your computers hardware.
Could try the retro version of Precise 5.7.1
Could try the retro version of Precise 5.7.1
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
Try this:
Boot with the Precise 5.7.1 live CD.
At the boot screen hit F2 key to bring up option screen.
Use option: puppy pfix=ram
Boot with the Precise 5.7.1 live CD.
At the boot screen hit F2 key to bring up option screen.
Use option: puppy pfix=ram
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
The log file is: /tmp/bootsysinit.log
For more info see: http://www.murga-linux.com/puppy/viewto ... 578#700578
For more info see: http://www.murga-linux.com/puppy/viewto ... 578#700578
How can I get to the log file when the system is not running. I presume that especially with pfix=ram, everything happens in RAM, including the /tmp directory. So when Puppy is hanging at "Making the filesystem usable", is there a way to see the contents of /tmp/bootsysinit.log? Remember that I am booting off the ISO image in VirtualBox...
Sorry, I misunderstood the question. Now I understand that you were asking how to see a log file, not just what file to look at.
I've never run VirtualBox, so am unfamiliar with it, but I assumed that it would allow you to examine things in the virtual box from outside the box, so provided the name of the log file. I don't know for sure if that is possible, or how to do it if it is. Perhaps someone familiar with VirtualBox will jump in and provide some hints.
I've never run VirtualBox, so am unfamiliar with it, but I assumed that it would allow you to examine things in the virtual box from outside the box, so provided the name of the log file. I don't know for sure if that is possible, or how to do it if it is. Perhaps someone familiar with VirtualBox will jump in and provide some hints.
This could just be a hardware issue.
Precise Puppy is not made to work on all computers.
Need computer specs to understand.
Not all versions of Puppy work on all computers!
Precise Puppy is not made to work on all computers.
Need computer specs to understand.
There is a newer version 5.6 of Slacko. Precise and Slacko are very close to the same Puppy with the latest updates. In fact, Slacko is a little more tested and bug fixed.When booting off slacko-5.3-MAIN.iso, everything works!
Not all versions of Puppy work on all computers!
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
-
gcmartin
Hi @Apventer
In looking thru this thread, I dont see the following:
Here to help
In looking thru this thread, I dont see the following:
- What is the HOST PC's hardware specs? (specifally CPU and RAM)
- What is the HOST PC's OS and version that you are using to run VirtualBox?
Here to help
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
script2
Then adding these lines early in rc.sysinit:
Will cause this output:
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.
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/consoleCode: Select all
#!/bin/sh
echo "script2 line2" >/dev/console
echo "script2 line3" >/dev/console
echo "script2 line4" >/dev/consoleCode: Select all
echo "rc.sysinit line 95" >/dev/console
script1
echo "rc.sysinit line 97" >/dev/consoleCode: Select all
rc.sysinit line 95
script1 line2
script2 line2
script2 line3
script2 line4Why 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.
-
shadower_sc
- Posts: 136
- Joined: Wed 21 Apr 2010, 23:03
- Location: Texas
Virtualbox Puppy 5.7.1 hangs
I am having the same problem using Virtualbox 4.2.18 r88780 to load Precise Puppy 5.7.1. It loads fine until it gets to the step "Making the filesystem usable.." and then it never continues. I tried Slacko 5.6 and it also hangs at the same spot. Ubuntu 12.04.3 loads fine. Debian Wheezy loads fine. Somewhere in the pipeline Puppy broke as far as the fact that it won't work in my Virtualbox. I do all my testing in Virtualbox and then load my remix onto the actual hardware it will end up on. I may have to stick with my Precise 5.4 kiosk for now.
-
bark_bark_bark
- Posts: 1885
- Joined: Tue 05 Jun 2012, 12:17
- Location: Wisconsin USA
Hi Guys,
I found a similar problem with precise puppy 5.6.1, but it is slightly more curious than it appears at first because things fail with specific physical cpus running the host environment (in my case, Windows 7 32 bit & 64 bit).
The machines it fails on had Intel P4s, Core 2 Duos, Dual Xeons, yet it works on a more modern AMD II X4 640 (3 GHz quad core). Some support virtualisation in hardware, some don't, but that shouldn't matter according to the VB documentation.
See my previous posts here:
http://murga-linux.com/puppy/viewtopic.php?t=86137
I'm not familiar enough with puppy to have done any testing / debugging but I offer my observations if it is of help to anyone.
BTW, I asked at the VirtualBox forum but got a rather superficial brush off. I guess it wasn't interesting enough to pursue.
It would be nice to run more recent pups in VB regardless of which cpu the pc has but I miss not being able to do that.
Incidentally I've tried the latest VB 4.3.6 & that doesn't help resolve the situation either.
It would be good if someone could get to the bottom of this as I always like to test out the latest Pups under VB before trying it on a real machine.
I found a similar problem with precise puppy 5.6.1, but it is slightly more curious than it appears at first because things fail with specific physical cpus running the host environment (in my case, Windows 7 32 bit & 64 bit).
The machines it fails on had Intel P4s, Core 2 Duos, Dual Xeons, yet it works on a more modern AMD II X4 640 (3 GHz quad core). Some support virtualisation in hardware, some don't, but that shouldn't matter according to the VB documentation.
See my previous posts here:
http://murga-linux.com/puppy/viewtopic.php?t=86137
I'm not familiar enough with puppy to have done any testing / debugging but I offer my observations if it is of help to anyone.
BTW, I asked at the VirtualBox forum but got a rather superficial brush off. I guess it wasn't interesting enough to pursue.
It would be nice to run more recent pups in VB regardless of which cpu the pc has but I miss not being able to do that.
Incidentally I've tried the latest VB 4.3.6 & that doesn't help resolve the situation either.
It would be good if someone could get to the bottom of this as I always like to test out the latest Pups under VB before trying it on a real machine.
algol68 ,
Thanks. Your observation that this issue is somehow related to specific physical CPUs is consistent with what 01micko found when he and others looked further into this. If interested, see the following thread:
Recent pups not booting in VBox as guests
Thanks for verifying that this problem still occurs with "the latest VB 4.3.6". And thanks for trying to make progress with the folks at VirtualBox.
Thanks. Your observation that this issue is somehow related to specific physical CPUs is consistent with what 01micko found when he and others looked further into this. If interested, see the following thread:
Recent pups not booting in VBox as guests
Thanks for verifying that this problem still occurs with "the latest VB 4.3.6". And thanks for trying to make progress with the folks at VirtualBox.
I lodged a ticket on woof-CE about this, really could not pinpoint the cause which leads me to believe it may be a vbox problem (of course that could be wrong). I am going to try a new puppy on my intel box (no vmx cpu flag) with an older vbox to see if this is the case.npierce wrote:algol68 ,
Thanks. Your observation that this issue is somehow related to specific physical CPUs is consistent with what 01micko found when he and others looked further into this. If interested, see the following thread:
Recent pups not booting in VBox as guests
Thanks for verifying that this problem still occurs with "the latest VB 4.3.6". And thanks for trying to make progress with the folks at VirtualBox.
Puppy Linux Blog - contact me for access
01micko wrote:. . . which leads me to believe it may be a vbox problem . . .
Agreed.
In my September experiments, which showed that under certain conditions, a simple shell script called from another simple shell script would never return when run in VirtualBox on my PC, I saw nothing to indicate that this is a Puppy problem.
[url=http://www.murga-linux.com/puppy/viewtopic.php?p=724426#724426]On 2013-Sep-07[/url] npierce wrote: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.
UPDATE...
Precise Puppy 5.7 Retro & Precise Puppy 5.7 are now working for me on a Core2Duo T7700 (HP 6910p running Win 7 Professional 64 bit).
It would seem to be a combination of:
1) Install VirtualBox 4.3.6 r91406
2) Enable Virtualisation. Select Settings>System>Acceleration
select the "Enable VT-x/AMD-V" option
I hope this works for anyone else that had all but given up on Precise 5.6 & later variants in VB. Enjoy...
Precise Puppy 5.7 Retro & Precise Puppy 5.7 are now working for me on a Core2Duo T7700 (HP 6910p running Win 7 Professional 64 bit).
It would seem to be a combination of:
1) Install VirtualBox 4.3.6 r91406
2) Enable Virtualisation. Select Settings>System>Acceleration
select the "Enable VT-x/AMD-V" option
I hope this works for anyone else that had all but given up on Precise 5.6 & later variants in VB. Enjoy...