(old)Puppy Linux Discussion Forum

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.

Hi, in my usual quest to speed things up I was mucking around trying for a Static IP address. It will work okay until I reboot then it reverts to 0.0.0.0 and I cannot connect.

Also code to allow Network to be backgrounded is commented out. I have tested it and it takes about 4 seconds off my boot time but it seems to stop me accessing the network. I've also tried "Nice" and that also seems to stop the network connecting. Any thought on what is going wrong?

In /etc/rc.d/rc.local0 replace lines (289-290 in 2.12)
Code:

. /etc/rc.d/rc.network
check_status $STATUS

with Code:

nohup /etc/rc.d/rc.network 2>&1 >/tmp/rc.network.log &
echo " [backgrounded]" >/dev/console


Thanks
Tony

Yeah, there's a problem if rc.network is backgrounded, the program 'ifplugstatus' stops working. Or rather, it works differently, not properly. I'm totally puzzled why that is. ifplugstatus detects if a network cable is alive.

I wonder if it could be started earlier and backgrounded and that would solve things?
I've still no joy with saving Static IPs, will try some more things later.
Thanks Barry

I should add that the backgrounding as in my post worked fine in Rudy 2.13

rrolsbe wrote:

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

Just a quick note, Puppuy 2.16 Beta still believes my externally attached USB hard drive is a flash device, IE... The save button is on the desktop.

Just a quick note, Puppuy 2.16 Beta still believes my externally attached USB hard drive is a flash device, IE... The save button is on the desktop.

Yes, I haven't thought of a solution for that one yet!

BarryK wrote:

Just a quick note, Puppuy 2.16 Beta still believes my externally attached USB hard drive is a flash device, IE... The save button is on the desktop.

Yes, I haven't thought of a solution for that one yet!

I have a way of doing that, which requires mounting /sys by the init script (I tried it).

A simpler way might be to check the device description (which probedisk gives you): Plinej's external HD has "External" in it's name, Raffy's has "USB Disk" -- maybe there are a few things we can check for.

Well, it's not the best solution perhaps, but if I just test size of drive and if 20G or more then assume it's a hard drive ...that should be easy to implement. It's highly unlikely that anyone is using a Flash drive that big (?)

Largest I've seen are 16 and 32:

http://www.tigerdirect.com/applications ... CatId=2634

Probably pretty rare though.

Perhaps one addition way to try and tell is that they are always

1,2,4,8,16,32 (yet the bytes vary some).

Physical Drives are usually, 10,20,40..etc....(I think I've seen 12 and 32 also)

BarryK wrote:Well, it's not the best solution perhaps, but if I just test size of drive and if 20G or more then assume it's a hard drive ...that should be easy to implement. It's highly unlikely that anyone is using a Flash drive that big (?)

Bye the time affordable flash devices reach 20G puppy will be on version 4.20.

Thanks for considering my situation!

Regards
Ron