(old)Puppy Linux Discussion Forum

John Doe wrote:

rrolsbe wrote:Looks like Puppy thinks the external USB hard drive is a USB flash.

You can specify to puppy like this:

puppy pmedia=usbhd
or
puppy pmedia=usbflash

I don't think there is anyway to tell the difference, for certain, in code. The USB class/subclass/protocol seems to be rather unrespected by hardware makers. There is a place for them, but my drives don't seem to fall in line.

Thanks for your suggestion but I am not booting from the USB hard drive I am just using it to store my pup_save configuration file. If I use either of the pmedia commands the boot process expects the boot files to be on the selected device. I agree it would be difficult to determine if the USB attached device was a USB flash, compact flash or hard drive; therefore, if there were a boot command to tell puppy my pup_save files were being stored on a hard drive attached via USB would solve this problem. I know most people do not use a USB attached hard drives and if they do, they boot puppy from the USB attached hard drive. Puppy is by FAR the most flexible Linux distribution I have tried and adding this capability would put Puppy further out in front. NOTE: Puppy works fine thinking the pup_save file is stored on a flash device it just could work better if puppy could be told the pup_save file was on a hard drive.

Again thanks for your reply!!
Regards
Ron

Puppy_2.16_alpha first test:

- No bugs found for now, seems quite solid, browsing among videos & audio never gave problems; new firewall version seems faster, requires only two OK's by user;

- Nice icons, grey background doesn't stress eyes - though won't raise wows from graphics enthusiasts; new background faultlessly loaded;

- Sound works well, at least on my old test-PC; Zmixer had no mute buttons, the Puppy mixer has but mutes an input device by throwing its fader to zero. It would be best then if it could keep the fader setting when muted, giving the same volume as before when un-muted, as in hardware mixers;

- Pmount seems to work well, more intuitive GUI.

More to come as testing goes further.
Anyway fine job Barry, always wondering how you manage to do all this...

Hello, Barry and all,

Above I wrote negatively about Gxine. I have just edited that out. Please disregard. I was not comparing Gxine with other players, just complaining that I couldn't get it to work. Well, I have finally got my installation fixed and it works. As usual Barry has shown good judgment in this selection.

But I like to run a tight ship, and have already dumped realplayer and the neat xfreecd I had used as bandaids. Sorry for any confusion caused.

Henry

1.
216 alpha is good when I take a full installation on ext2/swap partitions and on usb stick. But i was failed to make it run with the frugal install.
Is this a bug?
2.
216 alpha was not automount the my .sfs file with full installation?. How to?

Just a reminder that rarsa's newest mini-volume.tcl has not been updated in Puppy 2.16a.

http://www.murga-linux.com/puppy/viewtopic.php?t=8293

Kal

vanchutr
I run as a frugal install off of a cf card that presents as an ide drive formatted in fat and in fact thats what i am on writing this

one change in 216 is with how it loads sfs files and it is an enhancement not a bug

there is a new program called bootmanager under system i think and you have to use that the first time you boot to specify what sfs files you want to load - its a nice, simple program and allows for a lot of flexibility and granular control

George

To Vern72023,
Thank your fast reply.
I'd installed frugal installation with grub.exe and this menu.lst

But I was failed with this (with loadlin.exe) What difference between two installations?

Puppy 216 is not supposed to need a ramdisk parameter ... so root=/dev/ram0 and ramdisk_size=100000 should not be necessary

i think init=/etc/init should be init=/sbin/init ... i think the kernel uses /sbin/init by default, so that parameter also may not be necessary

the BOOT_IMAGE=pup_216.sfs parameter may also not be necessary

Thank Guesto for your fast reply (instructions)
I'd found some strange thing:
1. I must put the vmlinuz, initrd.gz and the pup_216 on the C: root (C:\)
2. And I edited the option.txt like that: 3. Now my pup216 ran successfully (I'd added the line 'PMEDIA=idehd'

Where in a full install do you place .sfs files? The boot manager shows the openoffice.sfs installed and the ignore box is not checked.

I placed openoffice.sfs in / just as the pup_save and zdrv.sfs were atomatically placed there.

The openoffice.sfs was downloafed from Barry's site and md5sum checked after download.

i had alook at aufs wh-files, and it looks like a big step foreward to me ! Please have a look at the attached file if you like to.

## partview broken ? ## ## bootmanager issue ##
bootmanager only shows *_216.sfs files (e.g. not kde.sfs)

## feature request: bootcode ##
can we please have an official cheat code PUPSAVE=ext3,hda3,/pup_save1.3fs
also: EXTRASFS=ext3,hda3,/kde.sfs ? too many people hacking initrd.gz ...

Very polished outfit... are we going mainstream ? I personnaly think it's now time to give something back to the hard working 'hobbyists' in the form of ... uuhhmm ... money ?

-fudgy

Flash wrote:

The iso I downloaded might be corrupted, but I thought I'd report this to see if anyone else is having the same problem with 2.16a multisession.

burniso2cd has been problematical on my system for the last 2 or threee versions of Puppy. Does not seem able to burn a normal ISO far less deal with multisession. I tried Gcombust - was OK with ISO but not OK with multisession.

I now use Xcdroast. It seem to work OK. This is the debian dotpup from Mark Ulrich's puppyisos server. Other versions including the standard version installed via petGet are missing dependencies and do not run.

Wonder if burniso2cd needs some attention.

GuestToo wrote:Puppy 216 is not supposed to need a ramdisk parameter ... so root=/dev/ram0 and ramdisk_size=100000 should not be necessary

i think init=/etc/init should be init=/sbin/init ... i think the kernel uses /sbin/init by default, so that parameter also may not be necessary

the BOOT_IMAGE=pup_216.sfs parameter may also not be necessary

G2, 2.16alpha uses a cpio initramfs and the init script is now at /init. And yes, /init is the default so no need to specify.

I'm back from the mini-holiday, and have made lots of notes on issues raised in this thread -- will get going on it!

The reports on GParted puzzles me.... it wouldn't be an upgrade problem by any chance?

Glad to have you back. I enjoyed your trip report and pix.
When I encountered the show-stopper with Gparted, I had booted from CD with pfix=ram so I could operate on the entire drive. No update/upgrade involved.
Richard

I Have installed Puppy-216-experimental to a ext2 partition, but grub wouldn't install properly. It doesn't give the choices like installing to mbr.

It wants to use uniofs as a default choice.

I had to boot with puppy-215 to get grub to install properly.

Anyway I got it fixed, I'm writing this to you from puppy-216-experimental, from a stepnote NC1500 laptop.

This Puppy Rocks!

All seems to work very well with this alpha.
I did a HD-install and everything just works, I installed Duke nukem and
Supertux dotpups and they were in the menu as dotpups.
After reboot the dotpups list in menu was gone.
This is the only thing I have had go wrong.

Great Puppy!

No problems installing Puppy-2.16alpha on a SecureDigital flash card through a USB card reader, boots OK from that card; but on closing, if the pup_save file has to be written on the card and this is write-protected, no warning message is given and the session data get lost.

I'm testing 2.16 alpha on different computers (4) and with different card readers (3).
I know nothing about hardware recognition, but in general it seems that MUT (default mounter in Puppy 2.14) has much better chances to access a flash card than Puppy 2.16's Pmount .
Some card types seem more difficult to access than others (SmartMedia is terrible, SecureDigital works almost always) and one card reader seems not to work at all with Pmount.

Anyone with similar experiences?

After more tests with Pmount and MUT in Puppy-2.16alpha, it is confirmed that MUT is far more prone than Pmount to "see" a flash card inserted in a USB reader. In one case only after restarting X (?) Pmount saw the card it didn't see before.
Anyway, after a card is inserted then taken away a couple of times, even MUT seems not to like the game and tends to ignore new card insertions (this happened already in preceding versions).

Of course, once MUT has found the card, Pmount also sees it.

One thing that surprised me: with a machine using a USB keyboard/hub (has a female USB connector on a side) the USB port to which this is connected works OK, but the mainboard's other USB port is simply not activated at all!
This was understood only after twiddling around for about half an hour, no card reader worked from there ... Probably happens with former versions too.

(As a byproduct of these tests, one of the card readers - the brand-new one! - was found to be defective at its SmartMedia slot. Gonna take it back to the dealer...)

I've taken that 2.16exp3 iso off ibiblio so that noone else will download it, as it can cause problems on your PC due to the ext2-compression.