'better' usbstoragefunc in the init script

What features/apps/bugfixes needed in a future Puppy
Message
Author
User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#21 Post by BarryK »

Jesse,
in that scsi thread you mentioned needing a whole lot of scsi modules in the initrd.
But, what about one or two generic scsi modules? Has anyone looked in the DSL
initrd?

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

#22 Post by BarryK »

Can someone test this initrd?
It is supposed to boot from SATA HD, USB CD, plus has Jesse's improved
and faster USB drive detection.

Unfortunately I have one of those SATA systems that don't work. I bought a
new PC with SATA HD especially for testing Puppy, but found the motherboard
chip's SATA interface isn't supported -- I found out that it will probably be
supported in the 2.6.18 kernel.

So, my mods to the init script are theoretical...

Oh, I just realised the initrd.gz is too big to post to the forum, so I'll just post the
init script...
Attachments
init.gz
(13.3 KiB) Downloaded 383 times

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

#23 Post by Jesse »

Hi Barry,

I've had a look into DSL's minit24.gz (initrd.gz equivilent) and their init script.
Unfortunately there is no quick and easy fix like 'one or two generic scsi modules'

DSL initrd modules:

a100u2w advansys aha152x aha1542 aha1740 aic7xxx ataraid
atp870u BusLogic dtc eata ehci-hcd fdomain gdth hptraid
ide-cd ide-scsi ieee1394 initio megaraid mptscsih NCR53c406a
ncr53c8xx ohci1394 pas16 pci2000 pci2220i pdcraid psi240i
sbp2 seagate silraid t128 tmscsim u14-34f ultrastor usbcore
usb-ohci usb-storage usb-uhci wd7000

Looks like DSL uses a 2.4 kernel. Puppy is on a 2.6 Kernel, so these names may not have a 1-1 comparison, and the list does not show what is compilied directly into the kernel.

Nevermind, we should still be able to come up with a solution for Puppy.

I'm looking at DSL as it looks very different but similar, the inird is much smaller and I'm trying to understand why, it would be nice if we can cutout any unnecessary kb from our initrd.gz and still keep it Puppy! ;)

Jesse

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#24 Post by PaulBx1 »

Well, I made a lengthy post here but it seems to have disappeared. :x Probably previewed it but forgot to post it. :roll:

Anyway, my problem was detection of USB mice. I was having problems and wondered if Jesse's initrd would fix it. At first I thought it didn't, but today it is working. But today the stock initrd is working too. So it looks intermittent at this point. If it fails again I will list that elspci command that you wondered about. For what it's worth, here it is in a working condition:

Code: Select all

sh-3.1# /initrd/bin/elspci -l 
02:00.0 020000 168C:0013 <ndiswrapper>
01:00.0 030000 1002:4C4D <>
00:07.3 068000 8086:7113 <>
00:07.2 0C0300 8086:7112 <uhci_hcd>
00:07.1 010180 8086:7111 <PIIX_IDE>
00:07.0 068000 8086:7110 <>
00:05.0 040100 1013:6003 <Sound Fusion CS46xx>
00:03.0 078000 11C1:0449 <>
00:02.1 060700 104C:AC1B <yenta_cardbus>
00:02.0 060700 104C:AC1B <yenta_cardbus>
00:01.0 060400 8086:7191 <>
00:00.0 060000 8086:7190 <agpgart-intel>
sh-3.1# 
BTW it's a Thinkpad A21m with USB 1.1 port, a hub on that, and the mouse plugged into the hub.

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#25 Post by PaulBx1 »

OK, today it decided to not work. I first booted with the stock initrd, then when I saw it was not working I rebooted with Jesse's. Still not working. Here's the elspci:

Code: Select all

sh-3.1# /initrd/bin/elspci -l
02:00.0 020000 168C:0013 <ndiswrapper>
01:00.0 030000 1002:4C4D <>
00:07.3 068000 8086:7113 <>
00:07.2 0C0300 8086:7112 <uhci_hcd>
00:07.1 010180 8086:7111 <PIIX_IDE>
00:07.0 068000 8086:7110 <>
00:05.0 040100 1013:6003 <Sound Fusion CS46xx>
00:03.0 078000 11C1:0449 <>
00:02.1 060700 104C:AC1B <yenta_cardbus>
00:02.0 060700 104C:AC1B <yenta_cardbus>
00:01.0 060400 8086:7191 <>
00:00.0 060000 8086:7190 <agpgart-intel>
sh-3.1# 

pop-pop
Posts: 29
Joined: Sat 10 Dec 2005, 13:42
Location: US - North Carolina

#26 Post by pop-pop »

Barry asked:
Can someone test this initrd?
It is supposed to boot from SATA HD, USB CD, plus has Jesse's improved
and faster USB drive detection.
I was going to test the SATA boot for you but ran into a snag:

Code: Select all

sh-3.1# tar -xvzf init.gz
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
tar: Error exit delayed from previous errors
What did you pack the init.gz file with?

pop-pop
Posts: 29
Joined: Sat 10 Dec 2005, 13:42
Location: US - North Carolina

#27 Post by pop-pop »

What did you pack the init.gz file with?
Oops! brainphart on my part

It was packed with gzip.

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

#28 Post by Jesse »

Hi PaulBx1,

Thanks for posting, I can't tell you what the exact problem is, because I am still trying to put my finger precisely on it.
I've been messing about, trying lots of ideas, with a lot of rebooting involved, and all I can say for sure is that I am getting confused.
I think I might have stumbled on the key to understanding usb though, its very complicated and we need to be smarter ;)

Theres something about usb devices and usb controllers, some or all of the below I have reason to suspect is true:
1) They can keep their state past a bus 'reset'.
2) Loading kernel modules in certain orders that can make for all sorts of confusion, like devices registering with the first driver, then jumping to the second.
3) USB 2.0 controllers and devices are supposed to work (and do) with a USB 1.1 driver, from bios and Kernel OS.
4) USB devices must be able to switch between kernel and bios drivers, because they never loose power.
5) Resetting the computer part way through Windows boot sequence (or OS I suppose) can put the USB bus into a very confusing state.
6) USB bus will stay on after you 'shutdown' and computer has switched off.
7) Modern computers have a power supply that supplies power to USB even if you pull the wall socket, for about 10 - 20 seconds.
8) I'm probably missing other things that can affect things.
9) All sorts of interactions from all the above...

Ok, well, if I can cover all those things I might be able to find a solution that works at least as well as Barrys solution...
The "real solution" might involve getting the shutdown script in sync with the init script, and never having anything crash badly enough to require the 'reset' button to be pressed, and always getting the user to use the shutdown command (in all their OSs), and never having any 'momentary' power brownouts. hmmmm...
I'll try a few more things tomorrow.

Jesse

pop-pop
Posts: 29
Joined: Sat 10 Dec 2005, 13:42
Location: US - North Carolina

#29 Post by pop-pop »

I was going to test booting from an SATA hard drive with Jesse's "init" but I need some help.

I have a spare empty SATA HD that will be a RAID drive one of these days and I was going to use that for boot testing.

My plan was to first get the "init" working with my Puppy 2.02 installation on /dev/sda and install to the spare SATA drive from there. The existing "/sbin/init" is a symbolic link to busybox. Just replacing that link with the "init" file doesn't work.

Do I need to be working from a Puppy on CD or what?

karlandtanya
Posts: 8
Joined: Sat 02 Sep 2006, 14:56

new init and elspci with Dell Latitude D500

#30 Post by karlandtanya »

Jesse wrote: Attachment includes the init script and the elspci file.

Jesse

First, note that puppy 202 works beautifully from a CD, and I've successfully compiled the kernel, truecrypt, and a couple other packages I like to use.

I would, very much like to be able to run puppy from my USB memory device.

I'm running into a little issue with USB booting:
The laptop I carry with me is a Dell Latitude D500.
Here's what I've done so far:
I'm using superfloppy mode. (BIOS doesn't like the boot sector)
I'm using the init and elspci from for_initrd in this forum.
I can boot as far as loading initrd, but no farther.
See dmesg_out (attached)
init seems to fail to find the "cannot find Puppy on usbflash boot media"
See init_out (attached)
however, I can manually mount hda on tmpfs
See manually_mount_out (attached)
See ls_mnt_tmpfs_out

Notes
I have put the new /init in /sbin/init in initrd
checked that this is the updated one by finding the lines
#v2.10 jesse has created 'elspci' that improves usb detection (t=)...
#comment-out the old stuff...
in there after booting as described above.
Also, I have put elspci in /sbin on initrd, and the new /sbin/init seems to find it.

hardware:
Dell latitidue D500, BIOS ???? (I'll write it down next boot & follow up)
USB controller Intel 82801DB/DBM
Kingston Data Traveller II, 1G

I am not sufficiently proficient to improve the init script, but I'm guessing that if I can manually mount the filesystem on the memory stick, then there must be a way to automate that process.

Can anybody suggest what I might do differently or point me to the section of script I should be looking at?

I would very much appreciate any help you can offer

Thanks


PS
If anybody cares about truecrypt, I'll post; I have NOT yet made a dotpup because I'm not sure how to correctly append the lines to modules.dep (what about duplicates). I'm guessing just steal it from the truecrypt install script...
Attachments
outs.zip
all the referenced attachments
(3.51 KiB) Downloaded 329 times

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

#31 Post by BarryK »

Have you tested Puppy 2.10alpha?
That has the latest init script.

karlandtanya
Posts: 8
Joined: Sat 02 Sep 2006, 14:56

#32 Post by karlandtanya »

BarryK wrote:Have you tested Puppy 2.10alpha?
That has the latest init script.
Just did it; no help.

Works fantastic on CDROM;

Used the universal installer to install to the Kingston Data Traveller II, 1GB
Then, "failed to find Puppy on usb boot device"


dmesg > dmesg_out (please ignore the /dev/hda stuff; I fatfingered--see below)

After failing to find puppy on usb boot device, I tried to mount /dev/sda (the usb device)

I successfully mounted it with no arguments (it came up as MSDOS), and as vfat with -t vfat. See output of mount, also attached.


Thanks again for all the help and the great distro!

I booted from the CD at work and got right on the internet via the LAN. Very, very easy!
Attachments
outs.zip
output of dmesg and mount
(3.37 KiB) Downloaded 307 times

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

#33 Post by BarryK »

I looked at the dmesg output, the usb drive is being recognised.
It may be a problem with it being a "superfloppy" as we haven't done much
testing booting from such.

Can you try this:
# disktype /dev/sda
...zip or gzip the output and post here -- I think you can insert the text directly
in a reply to this thread, but be sure to choose "Code" button (see above) so
that it displays with all the correct spacing.

I did test booting from a superfloppy awhile back, but it is possible that it got
broken after that. Your o/p from disktype will help me to correct that.

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

#34 Post by BarryK »

While you're at it, try these also:

# probedisk

# probepart

karlandtanya
Posts: 8
Joined: Sat 02 Sep 2006, 14:56

output with usb superfloppy

#35 Post by karlandtanya »

OK, booted from CD & ran the specified commands
Attachments
cdboot.tar.gz
command output
(545 Bytes) Downloaded 337 times

shankargopal
Posts: 295
Joined: Sat 03 Dec 2005, 11:30

#36 Post by shankargopal »

Hi Barry and Jesse,

Just found this thread and hoping one of you all will respond...

Don't know if you have seen this yet. A lot of us are having trouble booting off of USB sticks because the revised init doesn't wait long enough for the drive to be recognsied (after it has failed saying "Cannot find...", usb-storage output comes up, so drive is in fact recognised - but too late). Instead it runs through the process pretty much directly, without pausing at all.

Any ideas what we can do about this? I don't think it's an acpi or other problem judging by the diversity of the drives and computers on which it's occurring - would make more sense that it has something to do with the revised init script. Would take a look at it myself but not that advanced in scripting yet... :)

sml
Posts: 162
Joined: Tue 10 Jan 2006, 02:56

#37 Post by sml »

There is another thread with more users experiencing this problem also ...

http://www.murga.org/~puppy/viewtopic.php?t=11016

Post Reply