Puppy 4.1.2 (2.6.25.16 kernel) final - bug reports

[jrb]

rdate -s time-a.nist.gov (or other sites) resets my timezone to GMT+8 (Perth, Au) and sets the time to Perth time. See:
http://www.murga-linux.com/puppy/viewtopic.php?t=36730

[PuppyMac]

I downloaded Puppy 4.1.2 onto a MacBook however the trackpad does not work at all. When I get a text editor up and running, the keyboard repeats the first letter inputted into the system and does not repeating the text.

Thoughts?

[Botanic]

...not really a bug but sth quite annoying since version 2.16 at least :
Xarchive window is too little when opened, we need to extend it every time or click the arrow-down button to access "Extract"

EDIT: this will actually depend on the gtk theme used, but there's an issue anyway

[Béèm]

exProphecy, the 'copy bug' has been around since at least 4.1. The file(s) seem always to be correctly copied or moved even though Puppy reports that they weren't, so I haven't reported it.

Get indeed the same issue.
Altho I am happy that the move/copy seems to be ok, it makes people uneasy as an error message is an indication that something went wrong.

So I think the issue should be taken care of.

[Botanic]

"Set global font size" isn't working. It only changes the size of characters in the taskbar and the pinboard.

[Béèm]

I had hoped that the solution to have > 3 sfs files would have been applied.
Will this be for the next version then?

[PaulBx1]

/etc/rc.d/rc.sysinit creates the file /etc/rc.d/rc.local if the latter doesn't exist. It then calls that file.

When running the firewall wizard, lines are automatically appended to the rc.local to call rc.firewall - according to the comments in rc.local; however I suspect those comments are wrong and it just executes the rc.firewall. Those misleading comments should be deleted.

Unfortunately, rc.sysinit never made rc.local executable, so that rc.local is not executed.

Well, I'm not so sure of this. I have added lots of things to rc.local and they somehow get executed. However on another system with a virgin rc.local (just generated by rc.sysinit), if I run the firewall wizard and check by doing "iptables -L -v" in a console, I see the firewall rules. If I reboot and do the same command, the firewall rules are not there!

So I am kinda scratching my head about this one.

Another thing, rc.local does not have the "#!/bin/sh"... don't know if it needs one...

<later>
I have discovered another factor. For the firewall script to not be executed, I have to have modified it first. For example, if I made the 'INTERNAL_INTERFACES = "eth0" ' then reboot, I end up with no firewall rules. I don't know why; rc.firewall has the same permissions before I edit it, as after.

<later yet>
I finally figured it out. The firewall script first does some sanity checks. It found my internal LAN interface (eth0) not configured in the sanity check, so it just aborted! That's not too cool. There is no indication during boot that you are running without a firewall. This is particularly irritating that the firewall's protection on the external interface depends on the existence of a functioning internal interface which is not going to be firewalled in the first place!

[PaulBx1]

I tried to rename my system with the "hostname" command. I have seen the usual warnings (including in the 4.1.1 bug thread) about also changing /etc/hostname and /etc/hosts, but that didn't work for me. My system slowed down anyway. Not only that; the slow response from the LAN and WAN caused my firewall not to activate on reboot (perhaps connected to the above problem). Another symptom is that the command "iptables -L" takes about a minute to finish. BTW I have samba installed on this one.

Putting these two files back to "puppypc" made my system fast again.

On another system, with no samba installed, I renamed successfully.

I looked in all the files in /initrd for the string "puppypc" and found 50 files with that! Most of them were samba files which I had installed earlier. Looks like quite a chore to change the system name, which sure makes LAN work difficult. I wonder if all these references to system name might not go through one central point or environment variable or something of that nature, to fix this mess?

On another system with the devx file hooked into /initrd/pup_ro4, I saw several files in it containing the string "puppypc".

An unrelated problem (actually a nit): the file /etc/networks has the string "puppynet 192.168.1.0". When I listed my iptables, this string puppynet showed up in it. I'm guessing what is going on here is that the networks file holds strings that correspond to ip address blocks, and those strings are intended to make administration of large networks easier. However this mechanism seems out of place in Puppy, which generally won't be running complex networks. It actually added difficulty for me, since I didn't know what "puppynet" meant, in trying to interpret my firewall rules. I had to do a time-consiming global search for this string to figure it out. I suggest eliminating or commenting out (if that works) this string in the /etc/networks file.

[Evil20071]

Weird one. I restarted my computer and booted into Windows to set up some things from a recent re-format (Caused by a windows crash, of course). Came back to puppy and...

Xorg no longer boots either IceWM or JWM. I have to use Xvesa and JWM

IceWM is no longer around.


It's basically acting as though i did a new install with Firefox 3.0.5 being the default browser and adding the theme pets that I have acquired for it as well...

Any suggestions?



EDIT: apparently my driver for my intel gpu is corrupted. (Prolly from chkdsk in windows). Anyone know where they are located at? If so, I should be able to force a load of the puppy filesystem from my Live CD or usb install and just copy them over. I got Xorg to work using the "generic driver" tweak in the xorgwizard. Also got IceWM working under Xvesa and Xorg again.

[Botanic]

Every time a new package is added, /root/.icewm/menu is updated; the problem is that it removes "restart computer" and "shutdown computer" entries

[rolf]

I have searched and don't find a better place, so:

Just playing, trying to install to a 128M microSD in the usb card reader from puppy-4.1.2-k2.6.25.16-seamonkey.iso installed to livecd, md5sums and burn verified.

At first, I tried the advice found on the wiki: http://www.puppylinux.org/wiki/how-tos/ ... stallation

This involved a FAT format of the entire card as one partition, bypassing the defaults by choosing mbrfat.bin then syslinux at the appropriate steps. At first, I chose to copy .sfs to ram.

It boots, loads the kernel, then, after "Searching drives for" puppy files,

"pup_412.sfs not found. Dropping out to initial-ramdisk console
/bin/sh: can't access tty: job control turned off"

I can look around cat the README, see that / and /proc, etc. are mounted with `mount` but don't know what else to do.

I have tried formatting ext3 with gparted in the Puppy livecd session, leaving out the .sfs copy parameter and going with the default choices of the installer. There are settings in the BIOS of my Asus P5Q Deluxe for legacy USB (enabled) and I also enabled an 'ehci handoff from BIOS' for older OS and changed the switch for USB drive boot from (auto), which emulates floppy for devices less than 512M, hdd for larger devices to (hdd) to try as hdd.

My last attempt was with FAT16 formatted with gparted in Puppy livecd session, installer defaults. The contents of the drive are:

Code: Select all

$ ll /media/hd2                                                                 
total 96264                                                                                       
-rwxr-xr-x 1 root root  1289670 2008-12-27 19:25 initrd.gz*                                       
-r-xr-xr-x 1 root root    11493 2008-12-27 19:25 ldlinux.sys*
-rwxr-xr-x 1 root root 95641600 2008-12-27 19:25 pup_412.sfs*
-rwxr-xr-x 1 root root       55 2008-12-27 19:25 syslinux.cfg*
-rwxr-xr-x 1 root root        0 2008-12-27 19:25 usbflash*
-rwxr-xr-x 1 root root  1627180 2008-12-27 19:25 vmlinuz*

$ df /media/hd2
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdk1             120M   95M   26M  79% /media/hd2

All variations of my usb install strategy get to the same point in the boot process.

Strangely, booting the livecd failed with the same message one time. The next attempt to boot it succeeded.

The persistent failure to find pup_412.sfs is reminiscent of a driver not getting loaded and, hmm, I guess the usb controller is on ICH10:

[Evil20071]

Do you have a Windows installation on that pc? If so, boot into it and open a Command prompt and issue:

Code: Select all

chkdsk -f

This will force a scan of all attached hard disks, and will force all found errors to be fixed. Make sure that the MicroSD is attached when you do it. That error is often associated with a filesystem problem. I also suggest you dont' have any downloads running when you do that. I was torrent downloading a new FreeBSD disk and did that and it broke the download by unallocating the disk space for the iso.

[rolf]

Yes, I have XP and will try that, thanks.

[rolf]

Yes, apparently the switch is chkdsk /F and I needed to point to a partition, e.g. chkdsk /F l: but I did get all the windows format partitions chkdsk'ed, including the microsd card. There was an ntfs partition that needed work from chkdsk but the results are not different. I also changed to cdrom emulation for the usb storage device but I don't see that those settings make any difference. I changed the usb port speed to the slower 1.1 option but the card reader did not get detected at that setting.

[linuxcbon]

Not a bug, but wlan wizzard is not straightforward, with template, select a profile.

[rolf]

I have installed to a 128M ext3 partition on a usb key and that boots on the same machine. So I guess the problem is with the micro sd card or the reader.

[linuxcbon]

Seamonkey crashes too often, especially with flash videos.

[rjbrewer]

Rolf;

If I understand this correctly, you are trying to do a "full install" of
Puppy to a 128 mb card.
Puppies' 94mb size expands to a little more than 250mb when a
full install is done; decompresses.
Don't think it will fit.

rjb

[rolf]

Hi, as I said, I tested the size issue by installing to a 128M partition on usb key. The .sfs files are not expanded to the installation medium, just copied, aiui. Then, they can be expanded to ram entirely with pfix=copy or not and, apparently, the necessary parts can be extracted on the fly for low-ram systems, iianm.

[Botanic]

the partitions are obviously not treated correctly at shutdown !!
everytime i start OpenSuse after a Puppy session their is some kind of disk check...