Puppy 4.1.1 (2.6.25.16 kernel) final - bug reports

[Béèm]

Announcement 4.1.1

Feedback for 4.1.1
Please post any bug reports or any other feedback about Puppy 4.1.1 to the forum:
http://murga-linux.com/puppy/

There is a special thread for discussing the Network Wizard:
http://murga-linux.com/puppy/viewtopic.php?t=31522

There are some extra drivers posted here:
http://murga-linux.com/puppy/viewtopic.php?t=34159
If you have a Asus EeePC or MSI Win U100 mini-notebook, look at this thread.

[Béèm]

Altho Bary said the solution would be included in 4.1.1 final, it's not.

Two things lead me to a circumvention.
- Barry mentioning something about a ro6
- XFE complaining ro6 wasn't there

So in /initrd I created a pup_ro6 directory.

After reboot the third sfs was mounted on it.

Hope a final solution will be applied finally.

[raffy]

The pup_ro's are in initrd, so the change would have to be done there (so the pup_ro6 would be there after boot). But what you did is a welcome solution.

[Béèm]

I can't remember why also in a frugal install (Lin'N'Win) why the pup_xxx.sfs is to be copied in the root where the pup_save is. In this way it's two times on the HDD. I can understand that for speed of loading in a LiveCD operation it should be the case.

So now my case:
Installing 4.1.1 and saw the copy pup_411.sfs copy message.
Then I got the version update check which was rather short and not as usual.

Then I got the kernel panic:not syncing message.

So I rebooted.
This time no copy message but the load of pup_411.sfs.
Again I had the kernel panic: not syncing message.

Booted with pfix=ram and saw that the pup_411.sfs wasn't complete due to lack of space.
Removed the incomplete pup_411.sfs and some files and this time the copy of the pup_411.sfs and subsequent boot went ok.

The way I solved the issue is not a way a newbee would have found.

My conclusion is that a sanity check is missing in the script which copies the pup_411.sfs. A warning should have been issued.

Hope in the following version such a thing will be included.

[PaulBx1]

I just had the file system on my USB flash drive corrupted.

I have a hard drive with 3 primary partitions (Vista, ext2 and openbsd with 4 slices underneath). I also had a USB hard drive and the USB flash drive plugged in. In moving things around, I noticed that the access times were getting very long on the flash drive, and the rox window showed bogus icons or the names of files and folders were garbage. I tried to e2fsck and it complained about a bad superblock. So I finally gave up and reformatted.

I'm suspecting pup_event is not bulletproof yet. Other strange things I have seen: 1) two icons of the same device, a flash drive; and 2) sometimes it displays icons of all my openbsd slices, sometimes only one of them.

Probably some testing of plugging and pulling USB drives would be in order.

I notice gparted cannot handle openbsd partitions or slices. Not puppy's fault...

One nit: the universal installer still mentions zdrv.

However I complain, I really like this Puppy. It is slick!

[maddox]

I'm not sure if this is the right place to post... 4.1.1 (2.6.25.16) bugs

pmount jitters using Puppy 4.1.1 live-cd "pfix=ram", "mut" engine and a single internal 1.44MB floppy drive.
- I'm getting 1 or 2 floppy drives displayed with pmount (run from console under X) :
1st icon seems to be a fail-safe display ($FDDRIVE|vfat|1440 : no disk inserted : at least display something to the user)
.. if a floppy is inserted and contains a valid fs, the pmount script displays 2 drives : the fail-safe drive and the correctly detected floppy drive.
.. a pic is attached to illustrate my case :

- To get some more info, just a slight change to pmount to display the relevant info :
... echo "FINDFLOPPY $FINDFLOPPY DISKINFO $DISKINFO"
... echo "FDDRIVE $FDDRIVE PARTSINFO $PARTSINFO"

Code: Select all

#v409 mut2 lets us know if there are any floppy drives.
if [ "$PMOUNTENGINE" = "mut2" ];then
  FINDFLOPPY="`echo \"$DISKINFO\" | grep /dev/fd | cut -f 1 -d '|' | tr '\n' ' '`";
  echo "FINDFLOPPY $FINDFLOPPY  DISKINFO $DISKINFO"
  for FDDRIVE in $FINDFLOPPY
  do
    PARTSINFO="$FDDRIVE|vfat|1440
$PARTSINFO"
  done
  echo "FDDRIVE $FDDRIVE  PARTSINFO $PARTSINFO"
fi

pmount console results :
- Floppy not inserted or no valid FS on the floppy (low-level format) :
FINDFLOPPY /dev/fd0 DISKINFO /dev/fd0|floppy|3.5 floppy HD
FDDRIVE /dev/fd0 PARTSINFO /dev/fd0|vfat|1440


- Floppy inserted, contains a "minix" fs :
FINDFLOPPY /dev/fd0 DISKINFO dev/fd0|floppy|3.5 floppy HD 1.47MB 1 partitions
FDDRIVE /dev/fd0 PARTSINFO /dev/fd0|vfat|1440
/dev/fd0|minix|1474

- Floppy inserted, contains a "ext2" fs :
FINDFLOPPY /dev/fd0 DISKINFO dev/fd0|floppy|3.5 floppy HD 1.47MB 1 partitions
/FDDRIVE /dev/fd0 PARTSINFO /dev/fd0|vfat|1440
/dev/fd0|ext2|1474

- Floppy inserted, contains a "vfat" fs
FINDFLOPPY /dev/fd0 DISKINFO /dev/fd0|floppy|3.5 floppy HD 1.47MB 98-LITEBOOT
FDDRIVE /dev/fd0 PARTSINFO /dev/fd0|vfat|1440
/dev/fd0|vfat|1474

-------------------------------------------
using $DISKINFO (no info after HD) and $PARTSINFO (no display of two same devices)
if there is NO repetition of the same drive #no floppy inserted/no valid fs
then; display the fail-safe "vfat" icon in pmount
else; if there are 2 occurences of the same drive name, display the (single) correct floppy drive (fs) in pmount.
-------------------------------------------
mut displays this $DISKINFO for my floppy drive (no disk inserted or no valid fs) :
/dev/fd0|floppy|3.5 floppy HD

then this $DISKINFO (floppy inserted "vfat") :
/dev/fd0|floppy|3.5 floppy HD 1.47MB 98-LITEBOOT

a slight pmount display bug, using the "mut" engine
35 floppy HD 147MB 98-LITEBOOT
.. the dots seem to be ignored 3 dot 5 and 1 dot 47MB

I hope this helps ..
edited to retain the relevant info (floppy display problem with mut engine)

[Doglover]

Everytime I run BonEcho and gxine simultaneously X will drop to command line. I installed the full Xorg package in order to use hardware acceleration for my Via Unichrome chip. I enabled acceleration in the config, but I don't think that is the trouble because X did crash earlier.

I haven't tried any other browsers with gxine yet. Attached is my hardware report.

[PaulBx1]

Beem could you edit your first post to tell where Puppy 4.1.1 can be found? The announcement you mentioned had no information like that. Maybe you pointed to the wrong thread on Barry's blog? Looks like the previous thread there is the real announcement.

[Béèm]

Beem could you edit your first post to tell where Puppy 4.1.1 can be found? The announcement you mentioned had no information like that. Maybe you pointed to the wrong thread on Barry's blog? Looks like the previous thread there is the real announcement.

I thought the first link did point to the previous one, which was the announcement.
So didn't work.
Corrected now.

[rerwin]

1. I found that the delay I contributed to make PupDial wait until a connection was terminated, before setting the connect/disconnect button states, is insufficient for my 2.4 GHZ P4 PC, which is much faster than my 1.8GHz Athlon 2200+ test PC. If I increase the sleep value from 0.3 to 0.5, the buttons get displayed correctly. So, I conclude that the official value should probably be 1 second (sleep 1) to anticipate even faster PCs. Change line 74 of pupdial from:

Code: Select all

 [ ! -f /etc/ppp/peers/wvdial ] && sleep 0.3 #v409 allow kill completion

to:

Code: Select all

 [ ! -f /etc/ppp/peers/wvdial ] && sleep 1 #v409 allow kill completion 

2. I found that my test PC with only IDE CF cards as drives would not retain the (eth0) network setting across reboots (also reported in another Bugs thread). My solution is to insert after line 118 of /etc/rc.d/rc.network:

Code: Select all

  sleep 1

EDIT 11/22/08: Further investigation shows that if the added "sleep 1" is inserted before line 575 (instead of 118), Puppy boots with the previous network setting. That provides an alternative to delaying for all of the remaining invocations of the "testInterface" function. I am unable to test those other invocations knowledgably.
/EDIT

3. While attempting to use the Puppy Installer under Retro Puppy, the installer disappeared after I selected the CD option for obtaining the pup files. I was successful in the standard Puppy. I have not investigated the cause, although I did not see any error messages when I ran it from the command line.

My intent is to add any new bug discoveries into this posting, to keep them in one place.
Richard

EDIT 11/27/08:
4. The Intel alsa modems are not supported correctly, but the solution is simple! They are listed in /lib/modules/2.6.25.16/modules.pcimap as requiring both drivers snd-intel8x0m and slamr, although they should be assigned only to snd-intel8x0m. Without a workaround I provided during development of 4.0 (3.98), the correct driver gets assigned. But the workaround prevents that from occurring in 4.1.1.

The workaround, in /etc/rc.d/MODULESCONFIG, forces substitution of slamr, which apparently fails, because neither slamr or snd-intel8x0m get loaded. If line 14, beginning with "slamr", is deleted from MODULESCONFIG, snd-intel8x0m does get loaded and the modem operates without slamr being present.

Therefore, I request the following for 4.1.2:
a. That line 14 be deleted from the release.
b. In addition, line 13, which supports Lucent ISA modems on a particular ISA bridge can also be deleted; it results in false positives on some PCs without the modem installed, but that report them as present -- better to eliminate this special case, which the user can handle by forcing loading of driver ltserial.
Richard /EDIT

EDIT 11/30/08:
5. The problem of undetected mwave, Intel and Agere modems has not yet been addressed in 4.1, but I have now created a compromise solution. Instead of automating detection of these modems, I provide user notification in the modemprobe dialog. If no modem is automatically detected but one of the subject modems is installed and its driver is not already loaded, the probe dialog will explain this in the "Autodetected modems" section. It instructs the user to add the named module in BootManager. I feel this approach is nonintrusive and gives the user the option whether to make the change. A dotpet and difference files are attached.

The /usr/sbin/modemprobe difference file:

Code: Select all

28a29,45
> #v412 Check for any driver of a modem that is not detected automatically.
>  MODEM_MAP='Intel536 8086:1040 #v2.17 this info not builtin to module
> Intel537 e159:0001 #v2.17 this info not builtin to module
> mwave 1014:007d #not in modinfo.
> agrserial 11c1:048c #v4.00 nothing in modinfo. Agere chip.
> agrserial 11c1:048f #v4.00 nothing in modinfo. Agere chip.
> '
>  VENDEVS="`cat /proc/bus/usb/devices | grep '^P: ' | tr -s ' ' | tr '=' ' ' | cut -f 3,5 -d ' ' | tr ' ' ':'`"
>  [ "$VENDEVS" != "" ] && VENDEVS="$VENDEVS
> "
>  VENDEVS="$VENDEVS`lspci | cut -f 4 -d ' '`"
>  MODULE="`echo "$MODEM_MAP" | grep -E "$VENDEVS" | head -n 1 | cut -f 1 -d ' '`"
>  [ "$MODULE" != "" -a "`lsmod | grep -e "^$MODULE "`" != "" ] && MODULE=""
>  if [ "$MODULE" != "" ];then
>   MSGMDM1="HOWEVER, an undetected modem supported by driver module '$MODULE' appears to be installed (or plugged in). To use it, click on Menu > System > BootManager and add the new module, $MODULE."
>  else
> #v412 end
29a47
>  fi #v412

Since this fix substitutes for the modem PCI_OVERRIDES entries in /etc/rc.d/MODULESCONFIG, they can be deleted from that file. Also, the entry for yenta_socket can probably be deleted, if the revised PCMCIA/CardBus support loads yenta_socket independently of the general module-loading process. I would like feedback from someone using the "O2 Micro" CardBus controllers, to verify they work with 4.1.1+ -- the entry refers to only one of many such controllers and is not actually used in 4.1, anyway. These removals would leave the PCI_OVERRIDES variable to be set only as:

Code: Select all

PCI_OVERRIDES='dmfe 0x00001282 0x00009102 #r_hughes reports tulip module not work.
'

One more thing: The "/usr/sbin/listdriver" script I contributed as a workaround for 4.1 can be removed, since this fix replaces it and is much simpler. To summarize the changes:
- Update/replace /usr/sbin/modemprobe.
- Delete all but the first entry in PCI_OVERRIDES in /etc/rc.d/MODULESCONFIG.
- Remove file "listdriver" from /usr/sbin/.

Barry, I hope you can squeeze this in to 4.1.2, to resolve the last modem-regression issue I am aware of. Thanks.
Richard /EDIT

[Guitar Edman]

Subject pretty much says it all :
CD/DVD multisession boot no longer works on gateway laptop. 4.1RC boots on the machine fine but 4.1.1 a no go (I missed the 4.1 final )? Laptop in question is a M685-E so have pretty much eliminated it as the problem any help appreciated.
Thanks

[Béèm]

Subject pretty much says it all :
CD/DVD multisession boot no longer works on gateway laptop. 4.1RC boots on the machine fine but 4.1.1 a no go (I missed the 4.1 final )? Laptop in question is a M685-E so have pretty much eliminated it as the problem any help appreciated.
Thanks

A corrupted download?

[Guitar Edman]

Subject pretty much says it all :
CD/DVD multisession boot no longer works on gateway laptop. 4.1RC boots on the machine fine but 4.1.1 a no go (I missed the 4.1 final )? Laptop in question is a M685-E so have pretty much eliminated it as the problem any help appreciated.
Thanks

A corrupted download?

I wish its running great here writing this post using it on my desktop computer but the laptop refuses to boot the disk. After the laptop ignores it on boot up and launches windows I can look back at the disk (tried this with both CD and DVD with same results) and see all the required files are there the laptop just isnt using it on boot up where it does the 4.1RC without a hitch?

[Béèm]

So the md5sm is checked?
The CD (R or RW) is burned.
Boot ok on the desktop, not on the laptop.
Right?

Imagine there is some difference in the reading of the CD between the desktop an the laptop.
It could be that a marginal burn causes problems on one and not on the other.
Burning at a lower speed could be tried.
I don't see no other good reason, as, if I understand well, the HD is booted from shortly after trying to boot from the CD, right?

[Guitar Edman]

So the md5sm is checked?
The CD (R or RW) is burned.
Boot ok on the desktop, not on the laptop.
Right?

Imagine there is some difference in the reading of the CD between the desktop an the laptop.
It could be that a marginal burn causes problems on one and not on the other.
Burning at a lower speed could be tried.
I don't see no other good reason, as, if I understand well, the HD is booted from shortly after trying to boot from the CD, right?

Those were my initial thoughts also which is why I burned a second disk on a DVD using a different burner (at a different speed) and didnt post here until I got exactly the same result. the CD was exactly the same media that is working for the RC CD-R and the DVD is DVD-R? I can only assume it has something to do with the hardware detection or drivers at this point or maybe not allowing enough time for the cd to spin up but if that was the case why would 4.1RC be ok? really confused on this one....

[Béèm]

I am puzzled as well.
From your story, I understand the boot process from the CD doesn't even start, so the phase were drivers are involved wasn't there yet.
Maybe by using the puppysearch link in my sig, more is found on the issue. (unless you did already so)

[Guitar Edman]

I will definitely give it a try and thanks for your help with this! I hadn't thought it through, you are right the drivers as well as anything else on the disk never get the opportunity to load it seems... Probably not a Puppy bug after all but this being the case still at a loss why 4.1RC and previous versions work and this one doesn't ?

[PaulBx1]

I'd check the md5sum if I were you. All these other things are no substitute for verifying the checksum. I don't see why people skip this step, since it takes only a few seconds to get confidence you have a good download.

The other thing is that the burn needs to be verified. Unfortunately pburn still does not have a check (unless I'm mistaken). Do a burn in Windows with burncdcc, which verifies after the burn. Burn at the slowest rate, which will only cost you a few seconds.

Just running on another PC is not a proper check.

[rerwin]

While implementing a set of MS-file viewer interfaces (menu, OpenWith, default) I concluded that viewers should go into the *Utility category within each menu. I infer that because the ePDFview viewer is in DocumentUtility. (Although Fotoxx is described as a viewer, it is more than just a single-file viewer, so belongs elsewhere.) But I discovered that the Calculate menu does not include the seemingly standard Utility category, which is needed for file-viewers.

This is a request to add the CalculateUtility category to the /etc/xdg/hierarchy and /etc/xdg/puppy-calculate.menu files. That would not affect the menu if no .desktop files are found with that category, so I see no downside. I attach replacement files for 4.1.1 and include the difference file contents here.
hierarchy:

Code: Select all

# diff /etc/xdg/menus/hierarchy hierarchy
31a32
> Calculate  :Utility        X-CalculateUtility

puppy-calculate.menu:

Code: Select all

# diff /etc/xdg/menus/puppy-calculate.menu puppy-calculate.menu 
13c13,15
<   </Layout>
---
>     <Separator/>
>     <Menuname inline="true" inline_limit="10">CalculateUtility</Menuname>
>    </Layout>
33a36,43
>   <Menu>
>     <Name>CalculateUtility</Name>
>     <Directory>Puppy-CalculateUtility.directory</Directory>
>     <Include>
>       <Category>X-CalculateUtility</Category>
>     </Include>
>   </Menu>
> 
# 

The new /usr/share/desktop-directories/CalculateUtility.directory file:

Code: Select all

[Desktop Entry]
Encoding=UTF-8
Name=Calculate Utilities
Icon=spreadsheet.xpm
Type=Directory

I hope these can be included in the 4.1.2 bugfix. Thanks.
Richard

[Lobster]

I recently created a simple puplet based on 4.1.1
Linux Tmxxine Dark Force
http://tmxxine.com/wik/wikka.php?wakka=LinuxTmxxineDF

During the construction I had to manually put LIT
(a program that runs on Startup) in the Startup directory. It disappeared from there and was put in a temp directory that the remastering process creates
A message comes up asking you to check the contents of the temp directory (that is useful)
Now as I understand it, the startup location inclusion should have been automatic?

Other than that the remastering process is much simpler in the 4.xx series.

Anyway there are signs all over the place asking for any anomolies during remastering to be reported.

So that is my report