(old)Puppy Linux Discussion Forum

Well...I'm working from a 2.15CE live-DVD, which is using a pup_save.2fs on hdd1...

Dougal's splendid --I say, SPLENDID-- new Puppy Universal Installer has put an Option 2 (full) install on hdb again; it makes the task so easy, I decided to use GPartEd to re-do hdb as a 512MB Linux swap partition hdb1 plus 9.5GB as the ext3 bootable partition hdb2. Wow. This is the greatest thing since green glow-in-the-dark GMO fishing worms...

Ah, but, alas, when I attempted to use Barry's therein-incorporated new grubconfig to put grub onto a boot floppy in fd0...

...even though the notification tells me I was successful...

...there is in fact nothing on the floppy.

The floppy drive was not mounted, which since the target disk partition needs to be not mounted I assumed should likewise be the case; was I mistaken?

...the floppy diskette itself was freshly formatted and double-checked with a scandisk surface scan in a Win 98 machine; it tested-out as defect-free, just before I attempted to turn it into a grub boot floppy.

...and it gets worse:

I just tried starting over with Dougal's new Puppy Universal Installer...this time, with the wannabe-boot-floppy already mounted...PUI wiped the files on hdb2 as commanded...then it copied a fresh full hd install onto hdb2, and this new install appears to be all there...OK so far...

...but, this time, I did not even get the offer to install grub. Puppy Universal Installer exits (vanishes) as soon as hdb2 is finished being freshly written. Grubconfig does not come up.

Dougal, I've been asked by SHS to post the following results here:

test-scsi
/dev/sda - Direct-Access - USB DISK Pro
/dev/sdb - Direct-Access - USB DISK Pro

probedisk
/dev/hdc |cdrom|TOSHIBA CD-ROM XM-1802B
/dev/hda |diisk|FUJITSU MHE2064AT
/dev/sda |Direct-Access | USB DISK Pro
/dev/sdb |Direct-Access | USB DISK Pro

Barry: I did add some modifications from the 2.16 version, but not all -- some are specific to the new Puppy, like not having the "ram0" in the grub code.
I'll have a look at the fixed grubconfig.

bostonvaulter: I'll have a look at your modifications. Yes, I could add some message telling the user that a full Linux installtion is not possible on a MS formatted partition... Maybe when I give the choice of partitions to choose from I should mention it?

There's somehting else that might need improving: when people want to install to a NTFS partition I give them a message pointing to some forum thread with help on installing to NTFS.
That thread is obviously outdated (it's not even "murga-linux", just "murga") so maybe someone who knows a bit about using a frugal install on NTFS can have a look at it, post here an updated link and possibly updated info?

Ardee: thanks, are those removable USB drives, or just flash-drives?

SHS: I'll try and find out why you didn't get the option of creating a floppy the second time 'round.

I will try and add usage of grubconfig for frugal installs, but I don't know exactly how it works, so what I might do is check if grub is already installed, in which case just add an entry, and if not run grubconfig -- I'm just not sure how it is with setting up entries for a initrd system (it has a function named "initrd"... will look into it).

Dougal,

The drives are actually a single 4G USB memory stick with two folders in the root.

@Dougal and @Ardee: Ach, my bad. I mistakenly thought they were removeable USB hard drives.

Dougal, okay, I guess with all the issues and feedback, the whole thing is under heavy development anyway, so I won't put your Universal Installer into 2.16alpha. But, by the time we get to 2.16beta it should be ready.
Yes, the /dev/ram0 thing ...hmm, a small thing really, perhaps the code could test /etc/puppyversion and decide accordingly whether to use it.

Just to clarify, the bug I fixed in grubconfig was the "unionfs" coming up in a dialog box when it should have displayed the target partition. I should have put the string 'v2.15' or 'v2.16' where it was fixed.

BarryK wrote: perhaps the code could test /etc/puppyversion and decide accordingly whether to use it

I thought of that, but since you've been using 2.15 in your experimental builds it could have been a problem.


Everybody: Please test this, at least the first few stages, when it just detects your HW -- it won't cause any harm to your devices...

It is also best to run it from a terminal, so you will see any possible error messages.

Everybody: Please test this, at least the first few stages, when it just detects your HW -- it won't cause any harm to your devices...

It detects my SATA harddrive and partitions correctly. I didn't actually try an install though.

Everybody: Please test this, at least the first few stages, when it just detects your HW

From 2.15CE live-DVD, with a pup_save on hdd1...your new PUI detects both a USB stick (sdb) and an SCSI hard disk (sda).

Sit Heel Speak wrote:

Everybody: Please test this, at least the first few stages, when it just detects your HW

From 2.15CE live-DVD, with a pup_save on hdd1...your new PUI detects both a USB stick (sdb) and an SCSI hard disk (sda).

You mean a "real" SCSI drive? Or SATA? If it's a real scsi, I need help in trying to figure out how to know it's scsi and not sata... (I know sata might have "ATA" at the vendor -- 1st part of the name in probedisk -- but don't know if scsi drives will have "scsi" written anywhere...

If it's a real scsi I can give you more things to test...

help in trying to figure out how to know it's scsi

Philosophy

Architecture
*****************

The Linux SCSI Generic (sg) Driver:

SG3 Utils

SG-IO

Great Fun All: sg_raw ~ cdrecord-scanbus( outputs much same data)

TOOLS
LSSCSI/MAPSCSI

Thanks very much, Dougal, for tackling the installer to make it more "universal". I have tested your new version (as of yesterday) and find that it does not correct a related problem introduced in 2.15. It relies on /dev/cdrom and /dev/dvd as set during initialization or by the drive wizard.

However, in 2.14 the wizard shows the detected drive correctly, as hdc; the 2.15 wizard incorrectly shows hdb. This causes the installer to persistantly prompt for insertion of a CD into hdb!

The workaround, of course, is to run the wizard to set hdc. This suggests that the dialog might recommend the user do that.

But the main problem is that the initial cdrom detection is invalid; however, the installer is what shows the crazy behavior when the user relies on the default detection. (My PC has only a primary-master HD and secondary-master CDRW. My other PC with 2 HDs gets even more bizarre -- the HDs are offered as the CDROM candidates.)

Here are the differing wizard dialog boxes:

2.14:
Puppy has probed your PC and found these CD/DVD drives:
/dev/hdc LITE-ON_LTR-48125W

Puppy thinks the default CDROM reader drive is: /dev/hdc
Puppy thinks the default DVD reader drive is:
Puppy thinks the default burner drive is: /dev/hdc

DEVICE LINKS:
/dev/cdrom is currently linked to: /dev/hdc.
/dev/dvd is currently linked to: .

2.15:
Puppy has probed your PC and found these CD/DVD drives:
/dev/hdc LITE-ON_LTR-48125W

Puppy thinks the default CDROM reader drive is: /dev/hdb
Puppy thinks the default DVD reader drive is: /dev/hdb
Puppy thinks the default burner drive is:

DEVICE LINKS:
/dev/cdrom is currently linked to: /dev/hdb.
/dev/dvd is currently linked to: /dev/hdb.

I also note that the 2.15 version misleadingly shows a DVD device, even though the device is only a CDROM.

I hope you can correct these regressions as part of your upgrade to the installer (and that on which it depends). Thanks in advance.

Richard

Dougal, the 'init' script distinguishes between sata and true scsi drives, well, it does so in the latest 2.16. Information is written to /etc/rc.d/PUPSTATE, and it has the variable 'SATADRIVES='
...I could put some more variables in there.
I think Pup 2.14 also creates SATADRIVES variable.

In the init script, USBDRIVES is the USB drives (but not USB CD/DVD drives), SATADRIVES is the SATA drives (but not SATA CD/DVD drives).
The USBDRIVES variable is not exported as that can change, but you can dynamically test if a drive is USB or SATA by checking against the SATADRIVES variable. The same thing holds for testing if it is a true SCSI drive.

Dougal wrote:You mean a "real" SCSI drive? Or SATA?

Real SCSI. Vintage-1998 Seagate ST32155W on an Adaptec AHA-2940UW PCI SCSI controller. Delighted to help...

Ok, BUT if installed on a scsii drive, WILL it boot from that drive???
That's what inquiring minds want to know??

Bob

Users of boot loaders: Please help.

Grub users: I am trying to get the script to autodetect a grub installation. Please run the attached script (in a terminal) and see if it gives the right results.
Note: do not place the script in /tmp as scripts don't work well from within there.

Lilo users: I'm thinking of possibly adding support for Lilo, so any info will be helpful.
Examples:
The output of "disktype /dev/hda" (if had has Lilo installed to it's MBR)
Same for "hda1" if Lilo is installed to that partition (is it possible with Lilo, or only with Grub?)
Also the output of "fdisk -l"
Where is the menu file? With grub it's called "menu.lst" and located in /hda1/boot/grub/ (for example).
Also what the entries look like for a full install and for a frugal.


I will reply to recent posts shortly.

SHS: I'm more interested in simple info on how to know (from within a script) that it's a scsi drive. I know of lsscsi, but that means adding it to Puppy and waiting for the next release so people test with it etc. and also I don't like to rely on such contraptions (see probedisk/probepart and all the trouble they cause in Puppy). Lsscsi also gives you a lot of info -- I just want to know: scsihd or satahd?

As for the "sg" module, if I recall correctly, when I worked on adding scsi modules to my initrd.gz I tried it on my machine (=no scsi devices) and it caused my two IDE cdroms to be given scd0 and scd1 -- as well as the usual hdc and hdd -- which will cause a mess (and dmesg had a warning saying not to use it since it's deprecated…).
So I didn't put "sg" in with the scsi modules.


Rerwin: I was wondering if I should use /dev/cdrom /dev/dvd or actually look for devices… the reason I chose it this way was
1) laziness… couldn't be bothered doing the whole looking for cdroms
2) it seemed simpler to write the code this way. I guess I could just create a loop that goes through the cdroms
3) I try and assume that if the code in rc.local0 does a lot to check the drives, then the links are ok…

I'll see, I might just go to using device names (not rely on anything…).

The wizard is beyond my control…


Barry: the SATADRIVES parameter is not very reliable, so I don't use it. When I added scsi modules to my init script I thought of also creating a SCSIDRIVES parameter, but it's not worth the trouble and I don't like to rely on it for finding files: for example, if PMEDIA is "satahd" I just scan all "sd" devices…


Bobn9lvu: I think that Sage keeps complaining about Grub not being able to boot scsi. Is that so? If so it's a matter of using Lilo (I might get to that…).
However, you also need the init to be able to boot scsi… Jesse just tried my modified version with a scsi drive and it worked, but froze in rc.modules… so that's another hurdle in the way to booting off scsi drives.