Booting CD, /usr not found
-
- Posts: 14
- Joined: Mon 04 Jul 2005, 19:13
- Contact:
Booting CD, /usr not found
Not sure what to make of my problem. Am using 1.0.3, booting directly from the CD. Puppy won't do anything more than text mode; it gives several messages saying that it cannot find the compressed file containing the /usr filesystem, which contains X. I'd like to help fix this. Am running XP as main OS. What kind of diagnostic data would help?
a few questions to help clear some things up first.
Does the CD work on other PCs?
Has the CD ever worked - or is it a new download?
Did you check the MD5SUM to verify the download?
Did you burn the iso image at the slowest speed available?
( you may have noticed that all the questions here are pointing to the CD itself. This turns out to be the problem more often than not. )
Also, did you download and unzip the pup001 file to the C: drive?
Pup001 file is what puppy uses as a partition. It shows up on drive C as 1 file, 256mb in size. This does not interfere with anything in windows. It's seen as just another file.
Does the CD work on other PCs?
Has the CD ever worked - or is it a new download?
Did you check the MD5SUM to verify the download?
Did you burn the iso image at the slowest speed available?
( you may have noticed that all the questions here are pointing to the CD itself. This turns out to be the problem more often than not. )
Also, did you download and unzip the pup001 file to the C: drive?
Pup001 file is what puppy uses as a partition. It shows up on drive C as 1 file, 256mb in size. This does not interfere with anything in windows. It's seen as just another file.
-
- Posts: 14
- Joined: Mon 04 Jul 2005, 19:13
- Contact:
ISO verified. Here are specs.
I just verified my downloaded ISO using md5sum.exe and the .iso.txt. So that's out.
I did try building the C:\pup001 via pup001.zip. No change.
The CD is a new download. I will reburn it at lower settings (I used 40x).
I'll post a PC hardware rundown if the reburning doesn't solve.
I did try building the C:\pup001 via pup001.zip. No change.
The CD is a new download. I will reburn it at lower settings (I used 40x).
I'll post a PC hardware rundown if the reburning doesn't solve.
-
- Posts: 14
- Joined: Mon 04 Jul 2005, 19:13
- Contact:
Still no dice.
Used CD-RW this time, turned off all background apps incl. antivirus et al., burned at 6X instead of 40X; still no dice.
Many system specs are below. If any relevant data are missing, please let me know, and I'll post them.
Storage data:
C drive is 40G EIDE on primary controller on motherboard.
Boot CD-ROM is EIDE DVD RW+ on secondary controller on motherboard. Boot is controlled simply from motherboard BIOS.
There is a PCI IDE controller which runs another CD-ROM, which is a CD-RW. This is a Promise controller, with a Silicon Image 0680 chipset, seen by XP as a SCSI device. This is not bootable.
There is another 80G EIDE hard drive also attached to the Promise controller. Not bootable.
From CPU-Z:
CPU-Z Report
CPU-Z version 1.21.
CPU(s)
Number of CPUs 1
Code Name Spitfire
Specification AMD Duron(tm) processor
Family / Model / Stepping 6 3 1
Extended Family / Model 7 3
Package Socket A
Technology 0.18
Many system specs are below. If any relevant data are missing, please let me know, and I'll post them.
Storage data:
C drive is 40G EIDE on primary controller on motherboard.
Boot CD-ROM is EIDE DVD RW+ on secondary controller on motherboard. Boot is controlled simply from motherboard BIOS.
There is a PCI IDE controller which runs another CD-ROM, which is a CD-RW. This is a Promise controller, with a Silicon Image 0680 chipset, seen by XP as a SCSI device. This is not bootable.
There is another 80G EIDE hard drive also attached to the Promise controller. Not bootable.
From CPU-Z:
CPU-Z Report
CPU-Z version 1.21.
CPU(s)
Number of CPUs 1
Code Name Spitfire
Specification AMD Duron(tm) processor
Family / Model / Stepping 6 3 1
Extended Family / Model 7 3
Package Socket A
Technology 0.18
I just downloaded the iso this afternoon and did a burn on a cdrw disk. Puppy's burner defaulted to 4X. Same problem, unless I booted with the option to allow files to be written to the hard drive.
I have found that on cdrw disks, Puppy needs to be burned at 2X on a cdrw disk.
4X seems to work fine on a good quality cd-r disk.
The Puppy iso file need to be burned slow. Very slow.
I have found that on cdrw disks, Puppy needs to be burned at 2X on a cdrw disk.
4X seems to work fine on a good quality cd-r disk.
The Puppy iso file need to be burned slow. Very slow.
I love it when a plan comes together
--Hannibal Smith
--Hannibal Smith
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Jonathan,
When you boot Puppy and get to the prompt, try this and let us know what it returned:
This is the code that the boot script uses to detect your CD drives.
If this code is not detecting your drive, try "dmesg | more" and see if your CD drive is being detected at all.
When you boot Puppy and get to the prompt, try this and let us know what it returned:
Code: Select all
dmesg | grep -i "cd" | grep -i "atapi" | cut -b 1-4 | grep "hd[a-z]:"
If this code is not detecting your drive, try "dmesg | more" and see if your CD drive is being detected at all.
-
- Posts: 14
- Joined: Mon 04 Jul 2005, 19:13
- Contact:
Ran the CD detection command line, and...
I ran
and received the following:
I also examined the dmesg output, and found one oddity: "hda:" is the CD-ROM on the Promise PCI ATAPI card (not bootable), and "hdg:" is the CD-ROM on the motherboard secondary controller (bootable)!!! Frankly, on the surface I find this somewhat bizarre (reversed), but probably there's some strong logic for it written in Linux kernel source comments
So now the big question: Does Puppy know to look on "hdg:"?
Code: Select all
dmesg | grep -i "cd" | grep -i "atapi" | cut -b 1-4 | grep "hd[a-z]:"
Code: Select all
hda:
hdg:
hda:
hdg:
hda:
hdg:
So now the big question: Does Puppy know to look on "hdg:"?
I've found a similar thing (using vmware). Puppy cannot find the usr file from the cd, but I can mount the cd from the command prompt, copy the usr file onto the hard disk and reboot. The usr file is then found from the hard disk and everything seems to work fine. (The cd and hard disk are mapped to files on my XP system)
The dmesg command line finds the cdrom drive (hdc:) 3 times.
The dmesg command line finds the cdrom drive (hdc:) 3 times.
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Yes, hdg should work.
Now, let's try the next part of the boot script:
...try this and find out if disktype is detecting the string "ISO9660" on the CD.
Now, let's try the next part of the boot script:
Code: Select all
# disktype /dev/hdg 2>&1 | grep "ISO9660"
Besides following Barry's instructions to find out the root of the problem so it can be properly solved in puppy, you can try the following:
Boot from windows and copy the usr_cram.fs from the cd to C:\
Then reboot puppy from CD
This has two effects:
- Puppy will find that file without looking for the CD drive
- Puppy will boot very fast as the usr_cram.fs will be mounted at HDD speed and not at CD-drive speed. (In My case it went from about 3 minutes to under a minute)
Please note that I am advising this 'Besides' helping finding the root cause.
Boot from windows and copy the usr_cram.fs from the cd to C:\
Then reboot puppy from CD
This has two effects:
- Puppy will find that file without looking for the CD drive
- Puppy will boot very fast as the usr_cram.fs will be mounted at HDD speed and not at CD-drive speed. (In My case it went from about 3 minutes to under a minute)
Please note that I am advising this 'Besides' helping finding the root cause.
-
- Posts: 14
- Joined: Mon 04 Jul 2005, 19:13
- Contact:
Interesting news this time...
Now this is getting interesting. The command given:
produced nothing at all. Zip, zero, nada. I then ran this:
and it said that the device did not exist. I then ran this:
and the highest device on that list was hdd. The /dev directory, when I run the Puppy 1.0.3 CD on this machine, does not contain /dev/hde, or /dev/hdf, or /dev/hdg. So something definitely is up. What, I don't know...
I should have realized something like this before. Rereading the boot messages yet again, I saw that it spotted an NTFS bootable partition at /dev/hdc1, and advises me to build the pup001 folder on that partition. This time, I mounted /dev/hdc1, and checked it out. To understand the result, here is my drive/partition/controller layout in some detail as reported by the Windows XP storage administration applet:
I then put the usr_cram.fs data on my Windows V drive, and Puppy booted up very nicely indeed. It is obvious to me that Puppy is a very sweet piece of work. I will be testing it a lot. I have been looking for a really good, simple, fast Linux desktop for old hardware, and for people who don't configure their own desktops, for a very long time.
Once Puppy was booted in this way, by the way, there was indeed a /dev/hdg and hde, all drives visible. So perhaps the problem is somewhere in the live-CD capability.
Code: Select all
disktype /dev/hdg 2>&1 | grep "ISO9660"
Code: Select all
disktype /dev/hdg
Code: Select all
ls /dev/hd*
I should have realized something like this before. Rereading the boot messages yet again, I saw that it spotted an NTFS bootable partition at /dev/hdc1, and advises me to build the pup001 folder on that partition. This time, I mounted /dev/hdc1, and checked it out. To understand the result, here is my drive/partition/controller layout in some detail as reported by the Windows XP storage administration applet:
- Windows Disk 0 is an 80G IDE on my Promise PCI card. It has two partitions, both NTFS, which in Windows are M and V. Neither are bootable.
- Windows Disk 1 is a 40G IDE on the primary controller of the motherboard. It has three partitions. The first is NTFS, C drive. The second and the third are Linux data and swap respectively, upon which is currently installed SimplyMEPIS.
I then put the usr_cram.fs data on my Windows V drive, and Puppy booted up very nicely indeed. It is obvious to me that Puppy is a very sweet piece of work. I will be testing it a lot. I have been looking for a really good, simple, fast Linux desktop for old hardware, and for people who don't configure their own desktops, for a very long time.
Once Puppy was booted in this way, by the way, there was indeed a /dev/hdg and hde, all drives visible. So perhaps the problem is somewhere in the live-CD capability.
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Okay, in an rxvt terminal you type:
# disktype /dev/hdg
I would like to know the exact error message returned -- just drag the mouse pointer over the message to highlight the text and it will automatically go into the clipboard when you release the left mouse button -- then ctrl-v to paste it into this forum.
Also try this:
# probepart
...if this works, what i could do is modify the bootup code so if disktype returns error msg, then use probepart.
Although you have worked around the problem i would like to solve the original problem!
# disktype /dev/hdg
I would like to know the exact error message returned -- just drag the mouse pointer over the message to highlight the text and it will automatically go into the clipboard when you release the left mouse button -- then ctrl-v to paste it into this forum.
Also try this:
# probepart
...if this works, what i could do is modify the bootup code so if disktype returns error msg, then use probepart.
Although you have worked around the problem i would like to solve the original problem!
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Jonathon,BarryK wrote:Okay, in an rxvt terminal you type:
# disktype /dev/hdg
I would like to know the exact error message returned -- just drag the mouse pointer over the message to highlight the text and it will automatically go into the clipboard when you release the left mouse button -- then ctrl-v to paste it into this forum.
Also try this:
# probepart
...if this works, what i could do is modify the bootup code so if disktype returns error msg, then use probepart.
Although you have worked around the problem i would like to solve the original problem!
where are you?!!
I'm keen to get feedback on this.
In my case I have
# disktype /dev/hdc
--- /dev/hdc
Block device, size 60.42 MiB (63358976 bytes)
CD-ROM, 1 track, CDDB disk ID 00000001
Track 1: Data track, 0 bytes
# probepart
ext3
ext3
/dev/hdc|iso9660|0|VMware Virtual IDE CDROM Drive
/dev/hda1|ext3|4016187|Linux Ext3FS
/dev/hda2|swap|803250|Linux Swap
/dev/hda3|ext3|3566430|Linux Ext3FS
#
Note that the 'CD' is a VMware virtual CD, mapped to the .iso file (as opposed to a virtual CD mapped to a real drive)
I had to type the above data in, so there might be typos.
# disktype /dev/hdc
--- /dev/hdc
Block device, size 60.42 MiB (63358976 bytes)
CD-ROM, 1 track, CDDB disk ID 00000001
Track 1: Data track, 0 bytes
# probepart
ext3
ext3
/dev/hdc|iso9660|0|VMware Virtual IDE CDROM Drive
/dev/hda1|ext3|4016187|Linux Ext3FS
/dev/hda2|swap|803250|Linux Swap
/dev/hda3|ext3|3566430|Linux Ext3FS
#
Note that the 'CD' is a VMware virtual CD, mapped to the .iso file (as opposed to a virtual CD mapped to a real drive)
I had to type the above data in, so there might be typos.
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Thanks for the response.
That is very interesting. In my case, with a real CD drive:
The rc.sysinit boot script looks for that string "ISO9660", but in your case it ain't there. Hence failure.
But, probepart does report "iso9660", so I will modify rc.sysinit to use that as a fallback test.
...or, did you just not type in the entire response from disktype?
Bye the way, you don't have to type it in.
From a rxvt terminal, drag mouse pointer over text to highlight it, release mouse button, text is automatically placed in clipboard. ctrl-v to paste it.
That is very interesting. In my case, with a real CD drive:
Code: Select all
# disktype /dev/hdc
--- /dev/hdc
Block device, size 60.35 MiB (63277056 bytes)
CD-ROM, 1 track, CDDB disk ID 02019B01
Track 1: Data track, 60.35 MiB (63277056 bytes)
ISO9660 file system
Volume name "CDROM"
Application "MKISOFS ISO 9660/HFS FILESYSTEM BUILDER & CDRECORD CD-R/DVD CREATOR (C) 1993 E.YOUNGDALE (C) 1997 J.PEARSON/J.SCHILLING"
Data size 60.31 MiB (63242240 bytes, 30880 blocks of 2 KiB)
El Torito boot record, catalog at 32
Bootable non-emulated image, starts at 33, preloads 2 KiB
ISOLINUX boot code
Joliet extension, volume name "CDROM"
But, probepart does report "iso9660", so I will modify rc.sysinit to use that as a fallback test.
...or, did you just not type in the entire response from disktype?
Bye the way, you don't have to type it in.
From a rxvt terminal, drag mouse pointer over text to highlight it, release mouse button, text is automatically placed in clipboard. ctrl-v to paste it.
That was the entire response from disktype. The track shows as 0 bytes, so I suppose it can't look to see if there is a file system there. Possibly a problem in the vmware cd emulation.
Cut and paste was not available as I was doing it from the text only boot up, and didn't have the network running, so I had to type it into firefox on my main system.
Cut and paste was not available as I was doing it from the text only boot up, and didn't have the network running, so I had to type it into firefox on my main system.