(old)Puppy Linux Discussion Forum

The eee module crashes the kernel on certain models with certain bioses (including my 1005ha) so I'm using a newer module called asus_eee (ubuntu uses this as well) that does the same thing but with more error checking. Eee-control should work. Though you may want to check my post here:
http://www.murga-linux.com/puppy/viewto ... &start=120 which may explain some of your overheating issue.

Thank you for such fast support. The asus_eee works perfectly for fan control and conky monitoring. I'm set, made the transition completely to your kernel/4.31.sfs.

It can be done with a pre-existing 4.31 puppy save file--mostly entails icon-work, jwm menu reconstruction, and other dressing. But all bluetooth pets work, and the speed of the kernel is just great.

Wifi return remains buggy, but since I have tempestuous' pets already installed, I click on his wlan.sh and I can bring it back.

Thank you again for your hard work and fine support.

Jake

The new version is up. I updated the url in the first post. Fixes include addition of madwifi modules, fixes to networking script, removal of automatic celeron overclocking, and swap support added to the kernel.

jemimah wrote:The new version is up. I updated the url in the first post. Fixes include addition of madwifi modules, fixes to networking script, removal of automatic celeron overclocking, and swap support added to the kernel.

Swap was not the answer. But, I still suspect there is something to do with the type of file system. The full 431 kernel boots without problems, even on the SD card which gave me trouble when your kernel and initrd.gz were used.

My 900A is the Linux version with the Xandros system. This has four partitions on the 16 GB SSD: sda1 ext2, sda2 ext3, sda3 labeled BIOS with type unknown, and sda4 with no label and type unknown. The SD cards I'm using have either FAT16 or FAT32 file systems, (so they can hold files put there by an OS we won't mention. )

If I am wrong about the problem being tied to the type of file system, we may have a case of different machines with the same model number having different parts. (Other people have reported this turning up on the EEE PC.) Whatever the cause, it takes place immediately after the linux kernel modules to access disk drives are loaded. The two files, vmlinuz and initrd.gz, are read, using the BIOS, before these modules are available.

If I am not bothered by the speed of the full kernel, what do I need to support the sfs for your puplet?

Prehistoric, boot regular puppy, then send me a copy of your dmesg and lsmod output. Then I'll be able to tell if you have hardware that's not supported.

Is it still failing to find the sfs? Have you tried a regular usb stick as opposed to SD card? Maybe the card reader needs a kernel module I didn't add...

Puppeee has the normal 4.31 sfs plus only a few utilities that you can get as pets, so there's no compelling reason to use it if the kernel doesn't work for you.

Everything is running with the new version.

If I wanted to install it onto the HDD, will it still load to memory?

Can I put it in an existing partition like a ubuntu ext4 partition in a folder and point grub to it?

I also got elantech touchpad working how I like it just opened flsynclient from the console.

Asus eeepc 901. The netbook with Fn+F1 to F9 keys AND four extra "silver" keys (normally bluetoh, toggle touchpad and suspend screen) also they can be configurated with the propietary as eee-control from greg.geekmind or eeepc-acpi utilities from fewt-statux (or older elmurato scripts)
In your pupeee last revision beta 1_3 I can´t use them. Only the bright. The volume keys (fn+f7, mute, -f8, down or f9, up) only a box with the word VOLUME appears top screen but without up/down possibilities. Fn+f2 turns wifi off but not on after doing again fn+f2
Waiting script or utility like greg.geekmind or fewt-statux
Regards
jtouso

@Jemimah,

The mystery deepens. I woke up this morning with the conviction I must have messed up the usbwait=1 boot parameter. When I examined syslinux.cfg, I found that I had indeed clobbered that edit when I copied your latest files.

Excitement! Fix the boot line, and try it again. Disappointed again.

Now, I get dangerously tricky. I use 431 to copy your sfs files from SD card to sda2, the big Xandros partition, and edit syslinux.cfg to make pdev=/dev/sda2 and pmedia=ideflash. The BIOS is still set to boot off the SD card, which holds vmlinuz and initrd.gz.

This crazy set up works! It gets kernel and init ram disk off the SD card, then picks up the sfs files without a hitch. The bizarre thing now is the way the drive icons appear. There is a floppy icon which is mounted as sda1. This is the SD card we booted from. There are three partitions shown as sdb1 sdb2 and sdb3. These are the internal SSD partitions.

At this point, I can get into the trouble others have had with wireless and wpa, but that is another story.

The final bizarre thing is the way the same SD card I used works as sda1 for saving the pupsave-jemimah.2fs file, but then gives a "boot failed" BIOS message when I attempt to boot again. NB: the ordinary 431 SD card still works as before.

I remain suspicious of the usbwait=1 parameter.

I recommend you leave the ability to handle swap partitions in the kernel; someone is bound to use swap.

I've attached the dmesg and lsmod output from the working standard 4.3.1 system on an SD card. I neglected to get the dmesg from your kernel because i assumed if it booted once I could get it to boot again.

More experiments lie ahead.

Regards,

prehistoric

ad4mm, It will load into memory if you copy the files to the HD and modify your Ubuntu grub as you suggested. My grub looks like this:

jtouso, The keys are supposed to work, but apparently your keys have different keycodes than everybody else. I'm going to need you to get the keycodes for me and I'll fix the scripts. Does your sound work? It's really weird you'd get "Volume" with nothing else. I'm guessing your soundcard was not properly detected. Puppy does have an eee-control utility, but it's only for overclocking and fan control. I have not included it because I don't want anyone who doesn't know what they are doing to cook their processor by turning off the fan.

To find out what the function codes for your keys are you need to kill acpid and run it as 'acpid -d -l'. Then press a function key and see the code in the acpid debugging output as shown in the screenshot below. You can make the keys do whatever you want. If there is demand for this, I'll create a gui that allows you to remap them.

Prehistoric, I changed the boot parameter to nousbwait when you complained last time. Usb waiting is now the default. I removed the usbwait parameter from the syslinux.cfg. Your story definitely suggests your card reader is not being detected. I'll check out your dmesg output and see what I can determine.

Prehistoric, your Flash drive looks just the same as mine in dmesg so I'm not sure what the issue is. I made a change to the initrd that could possibly help. Can you try the attached initrd?

If it doesn't work and you get a prompt, can you try a few things? First type dmesg and see if anything interesting is there (shift-PageUp to scroll up). Then try 'mount' and see if /proc/bus/usb is there. If it is, try 'cat /proc/bus/usb/devices, and see if anything is there with 'Driver=usb-storage' on the 'I:' line.

jtouso, I found your extra keycodes on the internet and added them to my scripts. What do you want the default actions to be?

I suspect your volume/wifi is just broken for some reason but I need more info from you to figure out how. Does alsamixer work? If you click /etc/acpi/wlan.sh does it correctly toggle your wifi?

jemimah--

Since my pup save file is now on my eee 900 sda drive, I'm trying to replicate the save process I had earlier with your first kernel, a save process that saved as I went along, rather than save everything at the end (which slows down the shutdown time).

Before you released a full iso, you had released the kernel and syslinux.cfg. Then, when I used the command:

kernel /vmlinuz pdev=/dev/sda1 pmedia=ideflash fastboot

I was able to save as I went along. Is there a similar command I can use to do the same with the kernel/ISO? [This command won't allow booting now]

Jake

This is what I use

kernel /vmlinuz pdev=/dev/sda7 pmedia=satahd nousbwait=1 fastboot

Keep in mind, the reason for the saving at the end is to extend the life of your SSD. Flash wears out after a certain number of writes, and I don't think it's too easy to replace the EEE hard drive. Of course, EEEs are so cheap you'll probably want to replace the whole thing after a year or two anyway so you probably don't care and just want it to shutdown fast.

You can try removing the pmedia parameter entirely, I'm pretty sure that will work.

I found the working command, by pure accident. It happened to be left over from an unentbootin syslinux.cf:

default unetbootin
label unetbootin
kernel /vmlinuz pdev=/dev/sda1 pmedia=ideflash fastboot
#append initrd=/initrd.gz pmedia=ideflash
append initrd=/initrd.gz pmedia=cd

It's this command that makes the pupsave on the sda keep itself up-to-date: append initrd=/initrd.gz pmedia=cd

I guess that command refers to a cd that doesn't exist, thus defaulting to the sda1. I dunno.

You bring up an interesting point--this way, while faster, does make the sda1 natter to itself.

On the other hand, since the OS loads into RAM, perhaps the write calls to the sda1 aren't particularly prolific.

Of course, almost any other OS--be it XP or arch--will work the sda constantly. I've read more than 10,000 writes are possible (forum.eeeuser.com), but can't remember the exact specs/expectations.

Jake

EDIT: what I wish is for a command that allows puppy to shut down without saving at all.

I can add a parameter that will allow you to force the pupmode if you want. I still think removing pmedia entirely will probably work.

Only the main sfs loads to RAM. Your save file stays on disk and puppy definitely writes to it at least once every few seconds. Linux is a lot worse than XP in this respect unless you go out of you way to prevent it.

I've been thinking about writing an init script that will copy your save file into RAM. Of course, then you need to keep it small enough to fit in RAM. Or you could remaster and just never create a save file. The sfs file is compressed so you can fit a lot more the second way. You'd have to adjust the shutdown script not to ask you to create a save file every time.

Since my pupsave is only 196mbs, I would love to test your savefile-to-ram script.

I'm still too much of a novice to understand fully your pupmode suggestion. Is there a command that allow puppy to shut down without prompting for save?

Jake

Here's some interesting links
http://www.puppylinux.com/blog/?viewDetailed=00647
http://www.murga-linux.com/puppy/viewto ... aad418e369

I'll think about the save file thing, or a perhaps a one-click remaster-sfs script.[/url]

@jemimah,

I'm on a different machine now, so I haven't tried your latest initrd.gz. Before I reached this point, I did some more experimenting and turned up something which strikes me as odd.

I moved all the read-only files into the SSD, sda2. I modified the Xandrox menu.lst to give me a menu at boot up, including a choice of pupeee 431. The root line in grub treats the partition as (0x80, 1). The kernel line in grub refers to the partition as /dev/sda2.

When I boot with no SD card, it asks me the questions you would expect, and ends up with a desktop showing the internal SSD as sda1 sda2 sda3. I can now insert a blank SD card as sdb1 and create a pupsave file on it. When I reboot and choose the same entry on the menu, it returns to the saved desktop, except that the SD drive is now sda1 and the internal SSD is sdb1 sdb2 sdb3.

For comparison, when I boot the SD card for standard 4.3.1 it always appears as sdb1, with the SSD as sda1 sda2 sda3.