Booting CD, /usr not found

Booting, installing, newbie
Message
Author
JonathanBrickman0000
Posts: 14
Joined: Mon 04 Jul 2005, 19:13
Contact:

Booting CD, /usr not found

#1 Post by JonathanBrickman0000 »

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?

Rich
Posts: 278
Joined: Wed 04 May 2005, 19:00
Location: Middlesbrough - UK

#2 Post by Rich »

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.

User avatar
Ian
Official Dog Handler
Posts: 1234
Joined: Wed 04 May 2005, 12:00
Location: Queensland

#3 Post by Ian »

Have you verified that the download is not corrupt, there is a file at the download site to allow you to do this which you can use before you burn the iso.
Also could you supply details of your machine.

JonathanBrickman0000
Posts: 14
Joined: Mon 04 Jul 2005, 19:13
Contact:

ISO verified. Here are specs.

#4 Post by JonathanBrickman0000 »

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.

JonathanBrickman0000
Posts: 14
Joined: Mon 04 Jul 2005, 19:13
Contact:

Still no dice.

#5 Post by JonathanBrickman0000 »

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

User avatar
danleff
Posts: 294
Joined: Sun 08 May 2005, 13:11
Location: Albany, NY
Contact:

#6 Post by danleff »

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 love it when a plan comes together

--Hannibal Smith

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#7 Post by BarryK »

Jonathan,
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]:"
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.

Guest

#8 Post by Guest »

I've noticed, sorry bit off topic, but vmware/puppy has a problem finding usr_cram.fs when booting from an iso......but it can be manually mounted...


But Barry's suggesting kinda gives me a clue......

JonathanBrickman0000
Posts: 14
Joined: Mon 04 Jul 2005, 19:13
Contact:

Ran the CD detection command line, and...

#9 Post by JonathanBrickman0000 »

I ran

Code: Select all

dmesg | grep -i "cd" | grep -i "atapi" | cut -b 1-4 | grep "hd[a-z]:"
and received the following:

Code: Select all

hda:
hdg:
hda:
hdg:
hda:
hdg:
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:"?

Guest

#10 Post by Guest »

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.

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#11 Post by BarryK »

Yes, hdg should work.
Now, let's try the next part of the boot script:

Code: Select all

# disktype /dev/hdg 2>&1 | grep "ISO9660"
...try this and find out if disktype is detecting the string "ISO9660" on the CD.

User avatar
rarsa
Posts: 3053
Joined: Sun 29 May 2005, 20:30
Location: Kitchener, Ontario, Canada
Contact:

#12 Post by rarsa »

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.

JonathanBrickman0000
Posts: 14
Joined: Mon 04 Jul 2005, 19:13
Contact:

Interesting news this time...

#13 Post by JonathanBrickman0000 »

Now this is getting interesting. The command given:

Code: Select all

disktype /dev/hdg 2>&1 | grep "ISO9660"
produced nothing at all. Zip, zero, nada. I then ran this:

Code: Select all

disktype /dev/hdg
and it said that the device did not exist. I then ran this:

Code: Select all

ls /dev/hd*
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:
  • 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 checked /dev/hdc1 out. It's the V drive, above. /dev/hdc2 is the M drive, above. There was no /dev/hde1 to check, because were are no devices /dev/hde, /dev/hdf, or /dev/hdg in /dev, at all.

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.

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#14 Post by BarryK »

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!

Jesse
Posts: 466
Joined: Sun 08 May 2005, 16:07
Location: Auckland, NZ

#15 Post by Jesse »

Hi Barry,
There is code in the MUT program to create any additional device nodes for disks and cdroms in /dev so that the devices can be accessed. Is tcl in the initial image.gz ? If so you could almost copy and paste it.
Jesse

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#16 Post by BarryK »

No unfortunately, the tcl/tk libs are in /usr/lib, in the usr_cram.fs file.

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#17 Post by BarryK »

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!
Jonathon,
where are you?!!
I'm keen to get feedback on this.

Guest

#18 Post by Guest »

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.

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#19 Post by BarryK »

Thanks for the response.
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"
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.

Guest

#20 Post by Guest »

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.

Post Reply