cirrus,
looking back through my first post of 1am (here) I see that I didn't clarify my statement properly about being "a bit disappointed" that puppy4's weren't loading up from ye olde PCMCIA drives without difficulty, and it may have seemed - at a stretch, like I was diss-ing puplets that were dropping out as I was posting. Let me be clear: anyone who contributes to Puppy development is an absolute Legend, and well deserving of my adoration and awe. They are pushing the envelopes in so many directions it makes my head spin - I totally accept that not all 'antiques' can be brought up to speed with full hardware recognition on the release of every new puppy - just how many Miracles do I expect a day now that I've found Puppy Linux??
There are other workarounds that might help with the Puppy4/PCMCIA issue, listed here (for the 3480ct but it might help you too): http://www.murga-linux.com/puppy/viewto ... 17&t=26153
If you are on the path of emigrating from Windows, as I am, I can tell you that the latest CDBurnerXP (v 4.2.4.1351) now lets you burn (puppy) isos as "open" CDs and DVDs just like Puppy always has. Start a new 'data' disc, drag your iso file to the burn directory and say 'yes' to 'burn as iso?' - this gets you to the 'Write iso image' dialogue and if you ensure that "Disc at once" and "Finalize disc" are left UNchecked (and don't click on "burn as iso"), you will be able to burn live discs that are open for business. It's the only Windows equivalent I have found to the innovation that Puppy has had from the very start...
[update - ttuuxx's "puppies-431.1-main-Xserver.iso" and "puppies-431.1" can't load from PCMCIA drive like his 214X - am checking my download file integrity and burn properties to confirm this 'cos that will also give false negatives on what will and won't work on old hardware - provided the disc drive itself is not dying - that too can give hangs when the kernel is supposed to be loading up.]
Unable to boot Live CD or do 1-click install from CD drive
-
Bruce B
Yes, of course. I was not my intention to make anyone uncomfortable.Aitch wrote: Bruce, you may well be right, but as an old lag at this, please try not to make the noobies uncomfortable, just because they don't know
Facts are what they are, in retrospect I could have, should have presented them more gently, but the facts don't change.
It doesn't do any good - at all.Aitch wrote:You are probably better placed than many in getting this issue resolved by sending the devs your cli/bash scripting fix that you no doubt use, and telling them of your disdain - that would put the grunt where it's needed IMHO
*) I suppose if I had a computer that did it, I could fix the failure to find the pup*.sfs file
or
*) Lacking that, certainly write some debugging code
The problem is: Even if I did one of the above, it wouldn't help anyone but me.
You are a very good researcher. Suppose you can show me where any Puppy developer ever asked for help on this one? (not that I'm trying to obligate you to do the search)
Bruce
-
Bruce B
It is where it happens. Namely, topics where Puppy will not even run.Aitch wrote: You are probably better placed than many in getting this issue resolved by sending the devs your cli/bash scripting fix that you no doubt use,
and telling them of your disdain - that would put the grunt where it's needed IMHO
Here is the programming challenge:
For example 4.21.
The developer already knows exactly where pup_421.sfs is before the init script runs and fails to find.
The reason it knows this is the pmedia variable tells it's booting from an optical media. The layout of the media always has placed the pup_421.sfs at / of the media.
If only one optical drive, then it's a given the pup_421.sfs is at (cd)/pup_421.sfs on the only drive available. Making the find extremely easy.
How hard is it to write a script to find a file, when you already know where the file is? The answer is trivial!
If under these most ideal circumstances, the developer still cannot find the file, he can write a debug to trace where his script is failing to 'find the already know location of a file.'
When this problem occurs version after version and the script which is well known to fail never gets fixed, I wonder about the developers' bar. Which I suppose is: It works most of the time and that's good enough.
Actually, it is very easy to simulate the problem. Just rename your pup-xxx.sfs file to something else. Next time you boot, the kernel will complain and dump you to the "#" prompt.I suppose if I had a computer that did it, I could fix the failure to find the pup*.sfs file
You can do all sorts of stuff from the prompt. One useful thing is to type "probepart_init". Then you get a listing of all the partitions that the kernel sees, for instance:
/dev/sda1|ntfs|957312960
/dev/sda2|ntfs|19456000
/dev/sdb1|ext2|976767056
/dev/sdc1|vfat|8016372
/dev/sdd|none|0
/dev/sde|none|0
/dev/sdf|none|0
/dev/sdg|none|0
/dev/sr0|iso9660|0
If you don't want to write all this down, and if you recognize one of the partitions as a writeable device, you can record the results to a file on that device. For instance, from the above I recognize sdb1 as my primary Puppy hard drive. So I will mount it and re-run probepart_init, this time writing its results to a file on the hard drive:
Code: Select all
mkdir /mnt/sdb1
mount /dev/sdb1 /mnt/sdb1
cd /mnt/sdb1
probepart_init > results
cd /
umount /mnt/sdb1There is a ton of other stuff you can do when the kernel drops you to the "#" command prompt, but this is just the first thing that comes to mind.
-
Bruce B
Crash,
Yes, you can force a failure. But the problem happens with the CD disc booting and would require renaming the file in the ISO, wouldn't it?
And what we get is a known condition where it will fail.
Any idea how to reproduce it when the conditions are theoretically correct?
Bruce
Edited to add: I first encountered this with version 2.17 and where are we now?
We can get an idea how many people report the problem. We cannot know how many don't.
At one time I considered it a bug, but I now consider it part of Puppy's DNA due to the longevity of this one.
I feel frustrated for the user watching the user go though this, with him thinking it 'should' work.
On the other hand, I honestly think if I were to say, "Just try another Linux distro, any Linux distro, live or otherwise, you probably won't have this problem.
Yes, you can force a failure. But the problem happens with the CD disc booting and would require renaming the file in the ISO, wouldn't it?
And what we get is a known condition where it will fail.
Any idea how to reproduce it when the conditions are theoretically correct?
Bruce
Edited to add: I first encountered this with version 2.17 and where are we now?
We can get an idea how many people report the problem. We cannot know how many don't.
At one time I considered it a bug, but I now consider it part of Puppy's DNA due to the longevity of this one.
I feel frustrated for the user watching the user go though this, with him thinking it 'should' work.
On the other hand, I honestly think if I were to say, "Just try another Linux distro, any Linux distro, live or otherwise, you probably won't have this problem.
1-click install workarounds on old laptops
sorry folks (cirrus especially) I have to correct a statement I made earlier about ttuuxx's 214X11 puplet booting and loading from a laptop's external PCMCIA /cd-rom drive.
On rechecking the installation procedure I realized that I must have left a pup_214R.sfs on the hard drive, from a much earlier installation (perhaps 214X4, I'm not sure). Anyways, despite initrd and vmlinuz having been over-written repeatedly by other puplets (see my first post), 214X11 was able to piece the puzzle together and load from the surrogate files - and not via the PCMCIA cd-rom drive as I had supposed. But please don't quote this as gospel - I don't understand how this could happen without breaking the install as I'm still noobish to the technical innards of puppy...
rjbrewer's post here http://www.murga-linux.com/puppy/viewtopic.php?t=39513 seems the best bet generally in getting in through the "back door" and around PCMCIA and iLink cd-rom bootups in Puppy. Please let us know how you went, cirrus.
On rechecking the installation procedure I realized that I must have left a pup_214R.sfs on the hard drive, from a much earlier installation (perhaps 214X4, I'm not sure). Anyways, despite initrd and vmlinuz having been over-written repeatedly by other puplets (see my first post), 214X11 was able to piece the puzzle together and load from the surrogate files - and not via the PCMCIA cd-rom drive as I had supposed. But please don't quote this as gospel - I don't understand how this could happen without breaking the install as I'm still noobish to the technical innards of puppy...
rjbrewer's post here http://www.murga-linux.com/puppy/viewtopic.php?t=39513 seems the best bet generally in getting in through the "back door" and around PCMCIA and iLink cd-rom bootups in Puppy. Please let us know how you went, cirrus.
Bruce,
Yes, if you want to simulate the problem with a CD, you need to modify the .iso file, which isn't that hard to do. But I don't do that. Usually, I load the "big three" or "big four" files to a USB thumb drive to do the simulation.
My current computer has the opposite problem of the old Sony laptop, etc. machines. It is too new! It has a SATA CD ROM (actually, a DVD-RW). The older versions of Puppy, before 4.00 I believe, wouldn't boot up on it. The scenario is like this:
The BIOS recognizes the Live CD just fine, and Isolinux loads the kernel just fine. But the kernel, not having the correct driver, will never be able to access the SATA CD drive. It is a much bigger problem than simply not seeing the pup_xxx.sfs file. The kernel doesn't see anything on the CD! In this case, I boot up under some other operating system, like Windows (heaven forbid), and copy the files over to a medium that I think the kernel will see. Then I boot into that medium.
I know it seems like a band-aid to the real problem, but I am not about to re-compile Puppy Linux 2.17 just so I can boot the Live CD on this computer.
So to me, the secret is to find some media on the computer that the kernel likes, and use it to boot to.
Yes, if you want to simulate the problem with a CD, you need to modify the .iso file, which isn't that hard to do. But I don't do that. Usually, I load the "big three" or "big four" files to a USB thumb drive to do the simulation.
My current computer has the opposite problem of the old Sony laptop, etc. machines. It is too new! It has a SATA CD ROM (actually, a DVD-RW). The older versions of Puppy, before 4.00 I believe, wouldn't boot up on it. The scenario is like this:
The BIOS recognizes the Live CD just fine, and Isolinux loads the kernel just fine. But the kernel, not having the correct driver, will never be able to access the SATA CD drive. It is a much bigger problem than simply not seeing the pup_xxx.sfs file. The kernel doesn't see anything on the CD! In this case, I boot up under some other operating system, like Windows (heaven forbid), and copy the files over to a medium that I think the kernel will see. Then I boot into that medium.
I know it seems like a band-aid to the real problem, but I am not about to re-compile Puppy Linux 2.17 just so I can boot the Live CD on this computer.
So to me, the secret is to find some media on the computer that the kernel likes, and use it to boot to.
-
Bruce B
Crash,
I don't think it's been isolated to a SATA CD driver problem. Do you?
If I were the developer and I discovered I could not mount and read a SATA CD/DVD Drive, I'd want to do something about it. Especially as common as SATA is becoming.
And while on the subject, do you think Linux can't mount and read SATA optical drives?
Bruce
I don't think it's been isolated to a SATA CD driver problem. Do you?
If I were the developer and I discovered I could not mount and read a SATA CD/DVD Drive, I'd want to do something about it. Especially as common as SATA is becoming.
And while on the subject, do you think Linux can't mount and read SATA optical drives?
Bruce
I only mention SATA because it is an example of a problem I actually encountered. My computer wasn't yet built when 2.17 was developed, so it would have been tough to anticipate the need for the driver at that time. SATA is supported on all the Puppy Linux versions 4.0 and later, and they all work fine on this computer.
I notice the most number of complaints to be on laptops and on the more uncommon interfaces, like PCMCIA, etc. I've seen where some people have recompiled the kernel to include drivers for their own specific hardware, but I consider this to be beyond the capability of a newbee, or me, for that matter.
As long as the kernel can recognize the main hard drive, there is hope. Thus the suggestion to run probepart_init at the "#" prompt. Once you find an appropriate partition, you can test it by mounting it and typing "ls". If that brings up a listing of the partition's contents, you can probably get Puppy installed on that partition.
If Puppy had drivers for all the different hardware, it would start bloating up. Thus it is really about a 90% solution. This may seem inappropriate, but it is one of the compromises for a small operating system. I wish we had a library of drivers for more uncommon hardware, but so far that is not the case. It would maybe be a good project for someone, but it would take a lot of work.
I notice the most number of complaints to be on laptops and on the more uncommon interfaces, like PCMCIA, etc. I've seen where some people have recompiled the kernel to include drivers for their own specific hardware, but I consider this to be beyond the capability of a newbee, or me, for that matter.
As long as the kernel can recognize the main hard drive, there is hope. Thus the suggestion to run probepart_init at the "#" prompt. Once you find an appropriate partition, you can test it by mounting it and typing "ls". If that brings up a listing of the partition's contents, you can probably get Puppy installed on that partition.
If Puppy had drivers for all the different hardware, it would start bloating up. Thus it is really about a 90% solution. This may seem inappropriate, but it is one of the compromises for a small operating system. I wish we had a library of drivers for more uncommon hardware, but so far that is not the case. It would maybe be a good project for someone, but it would take a lot of work.
Thanks to everyone who has posted.
It's interesting to see that this has been a problem for so long. I'm not going to complain about it as I have to remember that it's free software and therefore no-one is under any obligation to fix it, but it is a shame. If the distro wants to attract people like me, the installer needs to just work.
I spent a couple of days trying to make it work, tried 3 different versions, reformatted my HDD to a variety of different file formats, re-loaded another linux distro to see if that was a better starting point, all to no avail. So I'm sorry to report that I installed Xubuntu 9.04 and it just works straight out of the box. I think I gave Puppy a good shot and really wanted it to work but I have other demands on my time and couldn't afford any more messing about!
Thanks again for all your suggestions.
John
It's interesting to see that this has been a problem for so long. I'm not going to complain about it as I have to remember that it's free software and therefore no-one is under any obligation to fix it, but it is a shame. If the distro wants to attract people like me, the installer needs to just work.
I spent a couple of days trying to make it work, tried 3 different versions, reformatted my HDD to a variety of different file formats, re-loaded another linux distro to see if that was a better starting point, all to no avail. So I'm sorry to report that I installed Xubuntu 9.04 and it just works straight out of the box. I think I gave Puppy a good shot and really wanted it to work but I have other demands on my time and couldn't afford any more messing about!
Thanks again for all your suggestions.
John
I think people maybe getting confused between a problem Puppy may have with some pcmcia connected CDs and cirrus's posted problem
Firewire has AFAIK been supported by the kernel since 2.4, though like scsi, I believe, has to be enabled....Did Barry enable it?....I don't know
I certainly struggled, even sending him scsi kit to get scsi booting sorted...as a few may remember....
When I was messing around with Firewire back in 2.14/2.14R, I think I recall something like modprobe 1394? was called for,
along with modprobe usb_ehci? for usb2, which was also giving problems, but it's been awhile since I used it - I got a usb2 DVDRW, which, although slower, was easier to transfer to other PCs without firewire, and usb2 is now fully functional in puppy
cirrus now says,
If someone knows a boot script that would enable firewire booting, it may help cirrus's problem, however....there are clearly other issues.....
.....or am I wrong/did I miss something??
The only thing I could find, which may help cirrus/people with the same problem as cirrus, is here
http://tuxmobil.org/firewire_linux.html
http://damien.douxchamps.net/ieee1394/coriander/
more work needed, methinks
Aitch
For iLink read Firewire, an IEEE1394 interface, - not your usual boot problem, IMOcirrus wrote:The cd drive connects to the laptop via an iLink cable
Firewire has AFAIK been supported by the kernel since 2.4, though like scsi, I believe, has to be enabled....Did Barry enable it?....I don't know
I certainly struggled, even sending him scsi kit to get scsi booting sorted...as a few may remember....
When I was messing around with Firewire back in 2.14/2.14R, I think I recall something like modprobe 1394? was called for,
along with modprobe usb_ehci? for usb2, which was also giving problems, but it's been awhile since I used it - I got a usb2 DVDRW, which, although slower, was easier to transfer to other PCs without firewire, and usb2 is now fully functional in puppy
cirrus now says,
.....as the impression given is, people know what the problem is, and how it could be fixed.....I tend to think it got lost in the historical fog from Bruce's rant...and no, Bruce, I don't know what to research, unless I follow my instinct, as here....It's interesting to see that this has been a problem for so long
If someone knows a boot script that would enable firewire booting, it may help cirrus's problem, however....there are clearly other issues.....
.....or am I wrong/did I miss something??
The only thing I could find, which may help cirrus/people with the same problem as cirrus, is here
http://tuxmobil.org/firewire_linux.html
http://damien.douxchamps.net/ieee1394/coriander/
more work needed, methinks
Aitch
-
Bruce B
Aitch,Aitch wrote:
.....as the impression given is, people know what the problem is, and how it could be fixed.....I tend to think it got lost in the historical fog from Bruce's rant...and no, Bruce, I don't know what to research, unless I follow my instinct, as here....
If someone knows a boot script that would enable firewire booting, it may help cirrus's problem, however....there are clearly other issues.....
.....or am I wrong/did I miss something??
I took an interest in this after it happened to me. ( a long time ago )
We can locate the point were the failure is reported. But it is not a simple mount / find operation failure necessarily, although it could be. There are a few things which must be successful prior to that operation.
Frankly, I'm about to give up interest, unless I'm lucky enough to find a machine which can reproduce the failure. (which could happen, because I have so much hardware lying around)
Bruce
cirrus-
I hope you didn't give up, because I think you can get there one way or another. I have yet to meet a computer that didn't eventually boot Puppy Linux, even if it took some detective work.
One really minor change to the Puppy distribution .iso file that greatly enhances your chances of locating the pup-430.sfs file is the following:
A single line in the isolinux.cfg file is changed:
from: append initrd=initrd.gz pmedia=cd
to: append initrd=initrd.gz
Explanation: This change in the isolinux.cfg file makes the kernel search everywhere for pup-430.sfs, including your hard drive.
So the thought process goes like this: If the kernel doesn't recognize the CD ROM in your particular computer, use some other operating system to copy the pup-430.sfs and zp430305.sfs files to the "/" directory of your hard drive. Then just push in the boot CD with the above change and it will boot to the hard drive. No install necessary.
Other thoughts: Getting rid of the pmedia parameter might be inelegant, and produce some unwanted side effects, but it works. I cut an edited .iso with this single change, and I can boot to NTFS, ext2, or fat file systems, and can boot to either hard drives or a USB thumb drive with it. At least it lets you get Puppy Linux running. For a first time user, the idea of just copying two files to the hard disk and pushing in a boot CD may be attractive.
I hope you didn't give up, because I think you can get there one way or another. I have yet to meet a computer that didn't eventually boot Puppy Linux, even if it took some detective work.
One really minor change to the Puppy distribution .iso file that greatly enhances your chances of locating the pup-430.sfs file is the following:
A single line in the isolinux.cfg file is changed:
from: append initrd=initrd.gz pmedia=cd
to: append initrd=initrd.gz
Explanation: This change in the isolinux.cfg file makes the kernel search everywhere for pup-430.sfs, including your hard drive.
So the thought process goes like this: If the kernel doesn't recognize the CD ROM in your particular computer, use some other operating system to copy the pup-430.sfs and zp430305.sfs files to the "/" directory of your hard drive. Then just push in the boot CD with the above change and it will boot to the hard drive. No install necessary.
Other thoughts: Getting rid of the pmedia parameter might be inelegant, and produce some unwanted side effects, but it works. I cut an edited .iso with this single change, and I can boot to NTFS, ext2, or fat file systems, and can boot to either hard drives or a USB thumb drive with it. At least it lets you get Puppy Linux running. For a first time user, the idea of just copying two files to the hard disk and pushing in a boot CD may be attractive.
- Attachments
-
- unsplit-pup-430-boot.sh.tar.gz
- Download the three pieces, then run this script to make the .iso
- (213 Bytes) Downloaded 324 times
Same thing happens here w/ 4.3.1 final, and a TP600e with internal CD and HD.Highman wrote:I get this same error when trying to boot on an IBM Thinkpad 600e. Would be interested in a resolution.
Also dpup 482beta3
Also likely similar cause (though no error message) on dpup477Beta1 retro
None of these are due to an external firewire or SCSI CD drive.
All are pfix=ram starts from LiveCD with 300 megs ram.
Okay, I'm writing this from the Thinkpad 600E after successful boot from LiveCD. It requires the 2.6.21.7 kernel version of Puppy 4.3.1.
It is available here:
http://distro.ibiblio.org/pub/linux/dis ... modems.iso
Incidentally that is the same kernel version that worked for other 4.xx versions of Puppy on this 10 year old computer.
This may not resolve the external CD problem posted by the OP, and others, but it would be interesting to find out. The scsi designation may mean something positive for this issue, as well as the earlier kernel.
It is available here:
http://distro.ibiblio.org/pub/linux/dis ... modems.iso
Incidentally that is the same kernel version that worked for other 4.xx versions of Puppy on this 10 year old computer.
This may not resolve the external CD problem posted by the OP, and others, but it would be interesting to find out. The scsi designation may mean something positive for this issue, as well as the earlier kernel.
-
linuxgeoff
- Posts: 8
- Joined: Sat 14 Nov 2009, 19:08
same problem - tosh 3110ct - cdrom timeout?
Same problems for me, using ext. pc-card cd drive on a tosh 3110CT. I have posted more details on other threads on this forum. I can confirm that with the pup_xxx.sfs on the cd, it falls over as decribed by others in this post. Put the file on the root of the HDD, however, and it will boot from the CD and allow a frugal install.
However, I need to do a full insatll to make this machine workable. If the authors can either solve the CD rom problem ( a timeout, perhaps?), or help me migrate from a frugal to a full install, I'd appreciate it.
It does seem to me that this is likely a simple bug to fix, and given how many people have suffered it - some who have given up with puppy and moved on - it would be worth fixing (and retro-fitting to the retro versions, please!)
Thanks, Geoff
However, I need to do a full insatll to make this machine workable. If the authors can either solve the CD rom problem ( a timeout, perhaps?), or help me migrate from a frugal to a full install, I'd appreciate it.
It does seem to me that this is likely a simple bug to fix, and given how many people have suffered it - some who have given up with puppy and moved on - it would be worth fixing (and retro-fitting to the retro versions, please!)
Thanks, Geoff
exact same problem as above. I've tried everything suggested that I could find in hours of searching these forums the past two days.
I can only get it to work by placing the "missing" sfs file in the root dir of the HDD.
I am stuck using an old version of Puppy Linux. Which is fine I guess but I would like to upgrade.
I can only get it to work by placing the "missing" sfs file in the root dir of the HDD.
I am stuck using an old version of Puppy Linux. Which is fine I guess but I would like to upgrade.