JL64-704 Slackware-14.2

Message

Dry Falls · #81 Post by **Dry Falls** » Thu 08 Sep 2016, 16:00

@gc, your answer is there in the pburn error message. You need to establish a working area or cache prior to running the operation. It's on the first dialog box. With a large iso the ram (/tmp) may not be up to the task. I always make a directory (I name 'Temp') on the root partition for multiple caching. That gives you a working area the size of the free space on the drive without interfering with anything else on the drive/partition.

gcmartin · #82 Post by **gcmartin** » Thu 08 Sep 2016, 17:00

Thanks @DF, but here is the system from yesterday. For a cleaning disc operation, I find it hard to believe that 9GB is too small for a 1.5GB disc or even a 4.5GB disc. There has to be a bug somewhere that affects the "FULL" cleaning operation. The system does NOT generate any error when I write an ISO to the USB. Some, I am only left to believe this a "bug" in either the operation or its internal calculation. Notice, too, that this error pop occurs at the end of the cleaning cycle.

Yet to do is to reboot with the newly created JLH7 and test again
I have re-downloaded the Sept JLH version, not "LT", and have checksum'd. I will start the disc clean operation after I reboot. For now, here's the current settings on the running JLH version; I will be rebooting after sending this post.

Code: Select all

bash-4.3# free            
             total       used       free     shared    buffers     cached
Mem:       4045760    1542240    2503520     510356     171304     962448
-/+ buffers/cache:     408488    3637272
Swap:      4192928          0    4192928

Update
New download and booting of JLH7. Same problem occurs in pBurn when "Full" blanking is selected. This could very well be a bug. This is NOT attempted in conjunction with writing an ISO. This is merely a blanking operation that fails after reaching the end of the disc.

zigbert · #83 Post by **zigbert** » Sat 10 Sep 2016, 06:57

gcmartin wrote:Notice, too, that this error pop occurs at the end of the cleaning cycle.

Does this mean the disc got blanked - or did it fail?

gcmartin · #84 Post by **gcmartin** » Sat 10 Sep 2016, 21:12

Not sure as I never checked. Following this error message, I redo blanking choosing the "Fast Blank" selection which always succeeds after experiencing the error shown here.

An interesting note: By design, if you Fast blank a disc, then follow that with an attempt to either Full or Fast blank, pBurn will issue a message that indicates the disc is already blank and returns to the main screen taking no action. But, if I use Full blank first, then following the error, it will proceed and Fast blank the disc with NO such message. THUS, I had assumed that Fast blank had detected that the disc was not blank and therefore proceeded.

I assumed that pBurn, by design, runs the blank detection+message sequence no matter if the user selected Fast or Full.

zigbert · #85 Post by **zigbert** » Sun 11 Sep 2016, 17:40

In the advanced-tab in the burn-option dialog you'll find the actual blanking command. Remember that pBurn is a frontend for cdrtools and dvd+rwtools. We have tried for years to build the most correct set of commands, but because of differences in media and burners, it has been hard to settle on one set of attributes. Especially blanking has shown diversity in behavior on different systems. That is the reason for the message/info in the blanking dialog... If you/someone are able to improve the commands, I will of course update pBurn, but it is not enough to test it on one device... and testing is hard these days when burning is not common - I have experienced trouble in getting burning-functionality widely tested.

Dry Falls · #86 Post by **Dry Falls** » Mon 12 Sep 2016, 01:08

Thanks Zigbert.

For cd/dvd tools, JL64-700 still has 2010 software!
These updated packages are available with gslapt and may be necessary for newer drives:

cdrtools-3.01-x86_64-3.txz
dvd+rw-tools-7.1-x86_64-2.txz
libburn-1.4.2-x86_64-1gv.txz
libisoburn-1.4.2-x86_64-1gv.txz
libisofs-1.4.2-x86_64-1gv.txz

df

newpet · #87 Post by **newpet** » Mon 12 Sep 2016, 07:16

gcmartin wrote:Firewallstate keeps popping up using cpu-cycles in Conky window even though I have turned it off and requested removal via right-click on taskbar icon.

It's not a JL thing, I report the same weird behaviour in my tahrpup 6.0.5 32b.
Definitively a bug.

Dry Falls · #88 Post by **Dry Falls** » Mon 12 Sep 2016, 13:50

newpet wrote:Definitively a bug.

firewallstate is not the firewall. It is a status daemon only, with access to multiple tray functions. .3 to .5% is hardly demanding on the cpu. Remove it with "quit & Remove". It starts up via the ~/Startup folder, so to prevent it from starting up at reboot, move its icon. Frankly, I don't see the problem. The firewall is disabled during bootup for network discovery and doesn't kick in till after X.

newpet · #89 Post by **newpet** » Mon 12 Sep 2016, 18:41

Dry Falls wrote:
newpet wrote:Definitively a bug.
firewallstate is not the firewall. It is a status daemon only, with access to multiple tray functions. .3 to .5% is hardly demanding on the cpu. Remove it with "quit & Remove". It starts up via the ~/Startup folder, so to prevent it from starting up at reboot, move its icon. Frankly, I don't see the problem. The firewall is disabled during bootup for network discovery and doesn't kick in till after X.

The problem is that the status daemon icon gives a false information. It remains green. therefore the real fw status is hard to guess.
I remember to myself that what we call firewall, for convenience, is just a software able to format the real firewall, that rely on a plain script and is not dynamic.
Quitting either the fw or the status daemon has not effect on fw functionality or effectiveness, as far we do not modify the script. Actually, the firewall continues to do its work.
Hope this helps.

/

gcmartin · #90 Post by **gcmartin** » Mon 12 Sep 2016, 19:47

Couple of items

Firewall
IMHO, the "bug" is more structure and operational than in individual feature.

I will open a thread to try to frame this for developer attention, as, it is more universal with PUPs built by WOOFCE. And post here the link.

Desktop use
"Hover & click" seems to add to use and is a definite problem for touch screen users. Hover you finger over any window causes unintended screen changes. Even as I know how to turn it off, The default for users should be to NOT have this in pristine boot; which was the default in past.

Dry Falls · #91 Post by **Dry Falls** » Tue 13 Sep 2016, 04:08

for the touch screen sensitive, drag this to the desktop (or wherever is handy):

ps., the tray icon changes color for me. It seems to me that the reason firewall was no longer activated by default was that older pups were having a hard time connecting to the interweb/network. I've run fatdog, slacko, quiirky and lxpup with firewall enabled and have had no problems with connecting to the network. I think it's a kernel thing. I think it might only interfere with remote desktop and I'm not sure that's a bad thing. Anyone with enough savy to configure a firewall manually or set up rdesktop can probably figure out how to disable the firewall. If you don't like it, remaster or pick a distro more suitable to your security needs. I happen to like the psychological security the little icon gives off. No doubt it won't stop the geeks at the nsa/goofle/microdick. Please do correct me if I'm wrong.

newpet · #92 Post by **newpet** » Tue 13 Sep 2016, 10:02

gcmartin wrote: Firewall
IMHO, the "bug" is more structure and operational than in individual feature.

I will open a thread...

Exactly. Thanks.

Dry Falls · #93 Post by **Dry Falls** » Tue 13 Sep 2016, 17:26

uploaded:
2cf372cdbb4ca9d077074ea27ba0801f Just-Lighthouse64-700f.iso 461M

f as in final

df

Dry Falls · #94 Post by **Dry Falls** » Tue 13 Sep 2016, 19:37

Here is a pet which addresses firewallstate gui:

stemsee · #95 Post by **stemsee** » Tue 13 Sep 2016, 20:37

Re gslapt 'mark all upgrades'

Dry Falls, you advised not do that. I wondered why? So I did it! After the upgrades I restarted x but it stayed at commandline prompt. I typed 'xinit' and X started up as normal. After a search I found the /usr/X11R7/bin/xwin was gone. So I copied it back from /initrd/pup_ro2/usr/X11R7/bin/xwin. No other problems! I also never had a problem with firewall icon. I just need firmware for bcm43142.

Everything is running well. I upgraded pmusic too. I hope you did too for the recent upload!

Cheers!

Dry Falls · #96 Post by **Dry Falls** » Wed 14 Sep 2016, 03:20

Thanks stemsee. for your bcm, were you able to use the full firmware sfs or did you find it elsewhere? As to the upgrade, slackware uses /usr/X11R6/bin so some other items might come up missing. Also bin items. Some scripts use busybox and some *-FULL. Might be some problems with the shutdown and changewm scripts. For the most part, though, there should be little problem.

df

stemsee · #97 Post by **stemsee** » Wed 14 Sep 2016, 07:56

bcm43142 comes as a source package with patches for specific kernel. It must be compiled to get 'wl.ko'. I haven't been successful yet.

Dry Falls · #98 Post by **Dry Falls** » Wed 14 Sep 2016, 19:52

I don't have wireless, but on your machine, wouldn't it be easier to recompile the kernel with ubuild.sh to get the module and firmware builtin to the huge package -- then replace kernelmodules.sfs in the initrd.xz? Or does it work differently. You first mentioned firmware, but it seems you're talking driver. Also, could you provide a link to proprietary drivers? I'd like to update the help files.

df

gcmartin · #99 Post by **gcmartin** » Wed 14 Sep 2016, 20:55

Booted the latest on a BIOS PC. Straight to desktop without issues. It starts consistent with LH/JLH in getting to the desktop. The proper ethernet adapter, the one with the active wire is selected and the DHCP assignment occurs, as has been happening since the very 1st LH.

Set the hostname for local use. And let it idle after FirstRUN completes. System appears smooth.

I do like the feature where after no activity it goes to sleep. I had left the room for a few hours and when I returned, I noticed the PC appeared off. But touching the keyboard, it springs to life. Nice.

I haven't tested yet, but, I wonder if I have Netboot active when it goes to sleep, if JLH7 will awaken when a PXE request occurs for Netboot service? Not sure if something in BIOS will need review or if the system in its sleep has the adapter active to intercept PXE requests.

And, I need to also test to insure I can create a humongous that will have all the same SFSs that the main ISO has so that JLH boots on other LAN PCs without needed to cart boot discs to them.

Lastly, is the firewallstate PET you provide, available via the JLH's update subsystem?

Thanks for what you do.

stemsee · #100 Post by **stemsee** » Wed 14 Sep 2016, 21:47

broadcom supplies the package. It is proprietary and not in the kernel source, i think. You are right it is the driver not firmware.

https://www.broadcom.com/docs/linux_sta/README.txt

ubuntu source
https://launchpad.net/ubuntu/+archive/p ... rig.tar.xz
;
seems to support up to kernel 3.8: so I will need to compile that first

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

JL64-704 Slackware-14.2

touch firewall

upload