Puppy 4.1.2 (2.6.25.16 kernel) final - bug reports
- Béèm
- Posts: 11763
- Joined: Wed 22 Nov 2006, 00:47
- Location: Brussels IBM Thinkpad R40, 256MB, 20GB, WiFi ipw2100. Frugal Lin'N'Win
sfs > 3 solution
I had hoped that the solution to have > 3 sfs files would have been applied.
Will this be for the next version then?
Will this be for the next version then?
Time savers:
Find packages in a snap and install using Puppy Package Manager (Menu).
Consult Wikka
Use peppyy's puppysearch
Find packages in a snap and install using Puppy Package Manager (Menu).
Consult Wikka
Use peppyy's puppysearch
/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!
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!
Last edited by PaulBx1 on Tue 23 Dec 2008, 22:07, edited 1 time in total.
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.
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.
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.
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.
[url=http://totalelectronics.us]TotalElectronics.us[/url]
bug? probably not but...
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:
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:
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
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:
Do you have a Windows installation on that pc? If so, boot into it and open a Command prompt and issue:
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.
Code: Select all
chkdsk -f
[url=http://totalelectronics.us]TotalElectronics.us[/url]
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.
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.
Intel graphics card drivers missing
Theres is a bug which effect intel graphics chips, these are very commonly found on onboard graphics chipsets, and on laptops. It effects intel 810 and 915 chipsets I have seen so far.
Relevant threads
http://www.murga-linux.com/puppy/viewto ... 027#266027
http://www.murga-linux.com/puppy/viewto ... 474#263474
The bug manifests by disregarding users screen resolution selections, no error message is given. The bug is fixed by replacing the i810_drv.so driver file from puppy 3, instructions are in the threads.
Relevant threads
http://www.murga-linux.com/puppy/viewto ... 027#266027
http://www.murga-linux.com/puppy/viewto ... 474#263474
The bug manifests by disregarding users screen resolution selections, no error message is given. The bug is fixed by replacing the i810_drv.so driver file from puppy 3, instructions are in the threads.
Puppy Linux's [url=http://www.murga-linux.com/puppy/viewtopic.php?p=296352#296352]Mission[/url]
Sorry, my server is down atm!
Sorry, my server is down atm!
Botanic, glad you find this bug in openSUSE also. It is also in puppy/ubuntu setup. It is due to puppy not unmounting the partition it is run from properly at shutdown. Apparently it is harmless, but does need fixing from a usability point of view
http://www.murga-linux.com/puppy/viewtopic.php?t=37395
linuxcbon, the flash problem is well documented. It is because Adobe (who make the flash plugin) do not allow their code to be modified to fix the bugs that are in it, and they are unwilling (read "cannot be bothered") to fix them themselves. Considering the amount of flash content there is out there on the net, the free software foundation has made it a priority to get an open source version of flash running. They have had some progress but are hard pressed as Adobe wont release the technical specifications. It also means that flash isnt available for other platforms like powerpc (Apple Macs and PS3's) The project is called gnash, all we can do is donate them money and wish them the best...and complain to anyone with any power in adobe.
http://www.fsf.org/campaigns/priority.html
You could also try installing a newer version of flash from the puppy installer.
http://www.murga-linux.com/puppy/viewtopic.php?t=37395
linuxcbon, the flash problem is well documented. It is because Adobe (who make the flash plugin) do not allow their code to be modified to fix the bugs that are in it, and they are unwilling (read "cannot be bothered") to fix them themselves. Considering the amount of flash content there is out there on the net, the free software foundation has made it a priority to get an open source version of flash running. They have had some progress but are hard pressed as Adobe wont release the technical specifications. It also means that flash isnt available for other platforms like powerpc (Apple Macs and PS3's) The project is called gnash, all we can do is donate them money and wish them the best...and complain to anyone with any power in adobe.
http://www.fsf.org/campaigns/priority.html
You could also try installing a newer version of flash from the puppy installer.
Puppy Linux's [url=http://www.murga-linux.com/puppy/viewtopic.php?p=296352#296352]Mission[/url]
Sorry, my server is down atm!
Sorry, my server is down atm!
HP2133 notebook..puppy 4.12 / 2.6.25 kernel...
Bit of an ongoing strange one......boots ok from flash and can mount sata hard drive.....full install also works...frugal install will not find pup_412.sfs....seems unable to scan/mount hard drive .(manged to mount manually with one puppy from rdsh but not this one)
Found variations of this with various puppies...using compatability mode made no difference.
The via_sata driver seems to be part of the kernel so a mystery to me.
Also note uses vesa driver in xorg...seems like an extended via driver (chrome 9?) is needed though not so much a bug as a missing feature.
Plus point...wlan working 100% and auto connects.
regards
mike
oh managed to wipe the carefully preserved suse install backup as hard drive ended up mounted via /tmp during full install.../tmp is cleared at shutdown...happened via mount icons...probably a one off just wanted to whinge ...fortunately owner is fast becoming a puppy lover.....
Bit of an ongoing strange one......boots ok from flash and can mount sata hard drive.....full install also works...frugal install will not find pup_412.sfs....seems unable to scan/mount hard drive .(manged to mount manually with one puppy from rdsh but not this one)
Found variations of this with various puppies...using compatability mode made no difference.
The via_sata driver seems to be part of the kernel so a mystery to me.
Also note uses vesa driver in xorg...seems like an extended via driver (chrome 9?) is needed though not so much a bug as a missing feature.
Plus point...wlan working 100% and auto connects.
regards
mike
oh managed to wipe the carefully preserved suse install backup as hard drive ended up mounted via /tmp during full install.../tmp is cleared at shutdown...happened via mount icons...probably a one off just wanted to whinge ...fortunately owner is fast becoming a puppy lover.....
kernel 2.6.25.15 or 2.6.25.16
When downloading the devx_412.sfs and kernel source.sfs at:
http://distro.ibiblio.org/pub/linux/dis ... modules-4/
the kernel source file has "2.6.25.15" in its filename. Is this correct for Puppy 4.1.2? I was trying to install VMware Player 2.5.1, which requires compiling modules, and get a message saying that the header files are not correct, or something like that.
If the .sfs file does contain sources for 2.6.25.15, then where can I get the 2.6.25.16 source? If the file contains the 2.6.25.16 source, could the archive be renamed to reflect the correct version?
Thank you
http://distro.ibiblio.org/pub/linux/dis ... modules-4/
the kernel source file has "2.6.25.15" in its filename. Is this correct for Puppy 4.1.2? I was trying to install VMware Player 2.5.1, which requires compiling modules, and get a message saying that the header files are not correct, or something like that.
If the .sfs file does contain sources for 2.6.25.15, then where can I get the 2.6.25.16 source? If the file contains the 2.6.25.16 source, could the archive be renamed to reflect the correct version?
Thank you
yes...cured (improved??) it with flash 9.0.124 from adobe archive though I read that the latest flash 10 is supposed to cure this ('on linux')...we shall see.Seamonkey crashes too often, especially with flash videos.
Also firefox 3 was hopeless for crashing and not just flash...firefox 2 gives same stability as seamonky so must be a mozilla version bug....picked up the flash and gxine plugins from seamonkey no problem.
Not sure if this is a puppy bug but after a crash (eg flat battery!!) on a HP2133 laptop full install, usb detection times out during boot exiting to prompt....'reboot' and enter brings it back to normal life but the sound often goes and have to rerun the alsa wizard...not sure if the 2 are related.
regards
mike