Bringing the Woof-CE template for Dpup Wheezy up to date

[musher0]

musher0, I did not have any problems with input devices...

I am booting from Precise Puppy, 'huge' kernel 3.14.55 from slacko 6.3.0. Woof-CE scripts and stuff, already there. A weird remaster, but it works.

musher, I undid all these changes:
http://www.murga-linux.com/puppy/viewto ... 851#883851

setup-netsound was executed as a service and fixed sound and ethernet at the first bootup, the timing issue I was having since I was testing tahrpup...

My next message will be after booting correctly from this problematic dpup whezzy.. maybe the day after tomorrow..

Very well. I too will be busy for a couple of days. TWYL.

[jlst]

dpup wheezy: first boot ... sound and ethernet working

*** First Boot ***
Waiting 5 seconds before kicking in...

=============================
SOUND
=============================
- Running /etc/init.d/10alsa start
* /dev/mixer NOT available
- Running /etc/init.d/10alsa start
* /dev/mixer NOT available

*** Trying with internal method...

* /dev/mixer NOT available

Your SOUND hardware:
via technologies, inc. vt8233/a/8235/8237 ac97 audio controller (rev 50)

- Loading snd-hda-codec-via
- Running /etc/init.d/10alsa start
* /dev/mixer NOT available
- Unloading snd-hda-codec-via
- Loading snd-via82xx-modem
- Running /etc/init.d/10alsa start
* /dev/mixer NOT available
- Unloading snd-via82xx-modem
- Loading snd-via82xx
- Running /etc/init.d/10alsa start
@ Sound is working
+ Set snd-via82xx as default in /etc/modprobe.d/alsa.conf

=============================
ETHERNET
=============================
NETCHOICE=connectwizard
* eth0 NOT available
- Running /etc/rc.d/rc.network start
route: SIOCADDRT: File exists
Waiting for interfaces to initialize...
ifconfig: eth0: error fetching interface information: Device not found
* eth0 NOT available

*** Trying with internal method...


Your ETHERNET hardware:
via technologies, inc. vt6102 [rhine-ii] (rev 74)

- Loading via-rhine
@ Ethernet is working.
- Internet connection is down.
- Running /etc/rc.d/rc.network start
dhcpcd[4164]: eth0: executing `/lib/dhcpcd/dhcpcd-run-hooks', reason BOUND
dhcpcd[4164]: forking to background
dhcpcd[4164]: forked to background, child pid 4334
Success!
* Wired ethernet hardware is already detected
+ Set 'alias eth0 via-rhine' in /etc/modprobe.d/puppy.conf

[jlst]

dpup wheezy: second boot

Waiting 5 seconds before kicking in...

=============================
SOUND
=============================
- Running /etc/init.d/10alsa start
@ Sound is working

=============================
ETHERNET
=============================
NETCHOICE=net-setup.sh
dhcpcd is running
dhcpcd is running
@ Ethernet is working.
- Internet connection is down.
- Running /etc/rc.d/rc.network start
dhcpcd[4220]: eth0: executing `/lib/dhcpcd/dhcpcd-run-hooks', reason BOUND
dhcpcd[4220]: forking to background
dhcpcd[4220]: forked to background, child pid 4966
Success!
* Wired ethernet hardware is already detected

That is the log when setup-netsound is executed as a service. I also added a GUI.

I'm very pleased from what I'm seeing, this can become serious business.. need testers with ethernet/sound problems.

I'll also include 10alsa with this change:
https://github.com/puppylinux-woof-CE/woof-CE/pull/734

I'll be testing a bit more before uploading the script again...

[musher0]

Excellent, jlst! Simply excellent!

I look forward to seeing -- and using -- your script!

~~~~~~~~~~
Can I bother you (and perhaps other knowledgeable readers) with a side note:
I have been using the prototype's twin that has the 3.14.56 kernel today, and it
seems to be less buggy.

1) However, I noticed the "teflon" effect again. I'll try to explain:

I had modified the .xinitrc file with a couple of lines where qiv can load the ROX
backdrop as "a picture behind the backdrop". Complicated to explain; let's just say
conky needs this for a real transparent window. And it works nicely, conky sees
the "backdrop behind the ROX backdrop" and since they are the same, you get
the illusion of transparency between the conlky window and your ROX backdrop.

Except that on 2nd boot, the default .xinitrc squished my edited one. (This
happens as well with the PuppyPin in a remaster if you don't double check the
copy. Anyway...)

I was wondering: are the pupsave and the zdrv.sfs really loading after the
puppy.sfs, as BK explains in his doc for this technique? I observed the process
carefully and no, the puppy.sfs is loaded after he pupsave. That would explain the
teflon effect -- AND PERHAPS the fact that your script is needed to bring to the
forefront (please forgive my lack of technical terms for a proper explanation) the
modules in the zdrv.sfs.

Is it only in this "Pooch" -- which would be an exception --, or does this happen in
every Puppy? I mean: the puppy.sfs loading over ("squishing") the pupsave and
the zdrv.sfs.

2) I also noticed that the various modules listings in the /lib/modules/bla-bla of the
puppy.sfs and of the zdrv.sfs are not identical in this "Pooch". Could that be
another explanation?

3) Finally, how important is the name and number version-ing in Puppy? You look
at the DISTRO_SPECS where you're supposed to have the version's name and
number, and then BK has a little sentence that says something like: "the data here
doesn't really matter, it's all done in /etc/rc.d/PUPSTATE anyway." Confusion,
confusion... I thought the DISTRO_SPECS data in the pupsave and the DISTRO_
SPECS data in the puppy.sfs had to match.

If you or anybody has ideas or experience about this, please report?
Many TIA. BFN.

[jlst]

I've edited/added like 50-100 lines (that I haven't tested yet) after that test. However, there is something filling my body with rage... this video explains https://www.youtube.com/watch?v=xh_9QhRzJEs

rc.network is not in woof-ce/woof-cpde/rootfs-skeleton ... it's part of the net_setup package
Here is a revised version which addresses timing issues
http://www.murga-linux.com/puppy/viewtopic.php?t=56473

To be honest, I would make a fork and put stuff where it belongs and look for the most updated version and continue with the work by applying new patches/changes made by the original author(s) or by the woof coders.

I believe Puppy is too disorganized that it doesnt make sense at all, out of the 500kb of shell code I've written, at least half of the time I felt like a fool, though I knew I was wasting my time, I still did it, rewriting stuff, etc.. It's no use, that's the way coding is... somehow this comes to mind..

[musher0]

Thanks for sharing your feelings, jlst.

Feeling like a mermaid who wants to go back to singing in the ocean after a love
tryst has gone sour on land is a very nice image.

I too feel let down by Puppy sometimes. As you say, it's quite disorganized. Info or
experience notes about a particular problem are scattered. I suppose this is what the
woof process is trying to counter, by grouping best experiences and practices in a
central place.

Still, Puppy is a good distro, very versatile; provides easy access to Linux for
newbies. And they can personalize it more easily than other distros.

However, because of its "layers" concept, developing for it is not that easy!

"Put your fabric back on the loom 100 times if you need to -- until it's perfect."
(French proverb from the text of an 18th century author. My "very free" translation.)

You've done good research and made good progress. Take heart!

~~~~~~~~~~
PS. Just a thought: if your detection routine works for sound and ethernet, it
may also be good also for detecting mouse and video card types. Who knows, with
your script, you may be on your way to recognizing and loading many other modules.

[musher0]

Hello all.

I am happy to report a breakthrough, a solution for the versioning and lss16
splash image problems mentioned earlier. (Please see attached!)

I'll explain the solution to the versioning problem only if asked! For now, I'll just
say that it's also linked to the loading problem I reported earlier.

This on a brand new iso called dpw-3.14.56.1, which has the 3.14.56.1 kernel,
the same as the Tahr Pup. Besides the kernel, it is exactly the same as the
prototype distributed to a few members +/- a week ago.

I am writing this message from it.

@jlst: do I have your permission to integrate your latest "sound-ethernet"
discovery service in this iso? Do you feel it's ready for publishing? TIA. (Don't feel
pushed if it's not ready yet. The draft you provided earlier works ok as a stop-gap,
but it's better to wait and have something more solid and final.)

This new iso has Links2 as the default browser -- until you use it to fetch a big
fellow such as firefox, etc., and install that. Shaves almost 50 Mb's off the iso.

More later. We continue!

BFN.

[jlst]

It's not ready yet, in fact, something that could describe the app correctly is "fixnetsound". It will check ethernet/sound status and rerun services.

But the app shines when somehow the interfaces are not available (modules are not loaded), but the hardware is recognized by Linux (lspci).

Today I made it work when there is more than 1 ethernet device, actually this change is critical and makes the gui misbehave when there is more than 1 ethernet device (I bet you don't know how to trigger it), basically it will analize network interfaces against the actual hardware, it became a little complex, there is a gui called net-setup.sh that will configure ethernet devices, so a gui for this is actually unneeded work, just run it, it will fix issues so you can work in the current session.

So, this what I think: no gui, just a script that can be run as a service and can be run from the command line that will just print information and attempt to fix ethernet/sound issues, nothing else.

If it doesn't solve your problems, use the -report option and send the report to me...

In short: the script will be 'fixnetsound'

[gcmartin]

Even though we have long since past the day when an ethernet adapter was an option, I had wondered where best to place this.

For example, on a couple of distro, when netbooting a PC over the LAN, some distros will end booted to desktop with either the ethernet adapter or the sound card missing when control is turned over to the running distro at FirstRUN. So, I was wondering if there is a way (I'm sure there is) to have this work be able to test and invoke without user intervention prior to or in conjunction with FirstRUN.

Reason: FirstRUN has features which require ethernet if their box(s) are checked. Thus, if this resolved the missing components on a pristine start, all subsequent apps/services/utilities would function without user need for problem determination (PD). In theory, this utility would only run once. Of course, there are other system/subsystem locations, including placement within FirstRUN, where this could land and assist system's operation, automatically. Benefit: PUP distro developers having the distros fully operational; and users not having this to complain about.

It is just an idea of "where is a good location for this automation to occur in a pristine boot when these peripherals are not adequately started?"

[jlst]

gcmartin, this script could help, this dpup wheezy booted without recognizing any of the 2 ethernet devices (through interfaces eth0 eth1... drivers were not loaded!) , then my script made both devices available, of course only one of them has the cable plugged in (eth1).. it did a good job!

[gcmartin]

Neato! I have one PC which has 2 LAN adapters on its motherboard. Using this utility, it would enable, for DHCP, the adapters which is wired and connected to a switch to the DHCP server(s).

I see you thinking ahead with the kinds of motherboard configurations that a user might have acquired.

Will try to test before the week's end. That PC with eth0 not wired and eth1 wired is a main PC and almost NEVER comes down.

Impressive logic.

[jlst]

]1) However, I noticed the "teflon" effect again. I'll try to explain:

I had modified the .xinitrc file with a couple of lines where qiv can load the ROX
backdrop as "a picture behind the backdrop". Complicated to explain; let's just say
conky needs this for a real transparent window. And it works nicely, conky sees
the "backdrop behind the ROX backdrop" and since they are the same, you get
the illusion of transparency between the conlky window and your ROX backdrop.

Except that on 2nd boot, the default .xinitrc squished my edited one. (This
happens as well with the PuppyPin in a remaster if you don't double check the
copy. Anyway...)

I was wondering: are the pupsave and the zdrv.sfs really loading after the
puppy.sfs, as BK explains in his doc for this technique? I observed the process
carefully and no, the puppy.sfs is loaded after he pupsave. That would explain the
teflon effect -- AND PERHAPS the fact that your script is needed to bring to the
forefront (please forgive my lack of technical terms for a proper explanation) the
modules in the zdrv.sfs.

Is it only in this "Pooch" -- which would be an exception --, or does this happen in
every Puppy? I mean: the puppy.sfs loading over ("squishing") the pupsave and
the zdrv.sfs.

2) I also noticed that the various modules listings in the /lib/modules/bla-bla of the
puppy.sfs and of the zdrv.sfs are not identical in this "Pooch". Could that be
another explanation?

3) Finally, how important is the name and number version-ing in Puppy? You look
at the DISTRO_SPECS where you're supposed to have the version's name and
number, and then BK has a little sentence that says something like: "the data here
doesn't really matter, it's all done in /etc/rc.d/PUPSTATE anyway." Confusion,
confusion... I thought the DISTRO_SPECS data in the pupsave and the DISTRO_
SPECS data in the puppy.sfs had to match.

If you or anybody has ideas or experience about this, please report?
Many TIA. BFN.

Um zdrv.sfs should not interfere with anything, as it only contains kernel modules/firmware

Well, it would seem that udev is not doing its job, however i'd like to try a new ISO from your work, with the new kernel you're talking about, my script would the last step to add and its scope is limited to ethernet and sound. I would be testing wireless ethernet with my remastered precise and your puppy, but that will require some time...

So, my advice, if you have a new kernel, upload a new iso.. and take it as an exercise, with Puppy you have to be more like a bounty hunter, it could be very easy to have all the essential scripts in the same place ready to work to benefit all puppies and remasters.. some essential static arch specific apps to be used by all puppies (this solves minimum 'requirements'), latest kernel firmware to be installed or shipped with puppies, etc... but it isn't so..

[musher0]

jlst?

Except for the # 2) above, you're late! I have already found the solution to this.
Please see this post.

It is related to the fact that the first 26 lines of the DISTRO_SPECS files in /etc
and in the initrd ramdisk MUST BE THE SAME. The one in /etc can have a few
add'l lines.

At Puppy boot-up, the original init file reads its DISTRO_SPECS file and looks for
a match in the puppy sfs and in the filenames and numbers. No match, no go.

Also, there has to be two DISTRO_SPECS files in any pupsave and they must be
the same as the ones in the main sfs at /etc and at /initrd. If not, at boot-up you
will be asked if you want to update.

Finally, the version name and number of the Puplet must match for the puppy sfs
file itself, the zdrv, the adrv and the ydrv.

Get those version names and numbers mixed up in the same save file or between
the component files (like I did, a "beginner's mistake" after I initially woofed this
pup) and your Puppy may refuse to boot, or not boot completely.

BFN.

[jlst]

Hahaha I actually think scripts should attempt to use /initrd/DISTRO_SPECS if available, because that is the real DISTRO_SPECS.

For example, DISTRO_SPECS from the sfs file and initrd.gz differ in my precise install, the initrd.gz/DISTRO_SPECS has this line:
DISTRO_KERNEL_PET=Huge_Kernel

and it makes a big difference, so this modified rc.sysinit takes care of it...

Code: Select all

. /etc/DISTRO_SPECS
[ -f /initrd/DISTRO_SPECS ] && . /initrd/DISTRO_SPECS ## this is more reliable

DEVTMPFSFLG=0 #this line is modified by 3builddistro
if [ "$DISTRO_KERNEL_PET" = "Huge_Kernel" ] ; then
	# always use devtmpfs
	mount -t devtmpfs devtmpfs /dev 
	DEVTMPFSFLG=1 #this line will remain untouched
fi

[musher0]

Thanks for the feedback jlst.

Yeah, I read part of Puppy's init, and it uses the DISTRO_SPECS within the initrd
for directions, as a "plan" or reference of what to do.

~~~~~~~~~
I have a new iso ready, based on kernel 3.14.56. Will upload to adrive.com and
make available shortly. It's still an alpha.

Meaning: ally, stay away! I don't want posterity to know my mistakes!

I still encountered the "teflon" problem, but to a lesser degree. This time, I think that
it is the "burst" copy mode < cp -a > that is skipping some important files. Again
the copy of the busybox was truncated, but this time also some of the large (+/-
512k) aufs utilities in /sbin. This is beginning to be worrisome.

Would anyone know of a forum for the cp utility, where people can report bugs? We
shouldn't have to double-check "bulk" copies visually. We should be able to trust
the copy process as flawless.

~~~~~~~~~~~~~
Next big step would be to upgrade the eglibc to at least 2.17. Could we try for the
latest glibc 2.22, even ?

I have no idea how to do this successfully. I did compile glibc 2.22 and it went well
until I typed "make <Enter>"... Everything "froze" stiff. Lucky thing I had made a
back-up of my pupsave.

charlie6 came up with an interesting link on this pupjibaro-Wheezy thread.
That was over a year ago, and this particular libc seems to have disappeared from
the mepis repos. I can't find it.

As well, I am tempted to "pluck off" (you know, like feathers? ) the libs
from the DebianDog-Jessie. Obviously it isn't kosher to do that, but can it even be
done technically?

BFN.

[jlst]

musher0, you must the use --remove-destination option

Code: Select all

cp -a --remove-destination source dest

--remove-destination first removes the target file, so the copy is secure.

If you use cp incorrectly, symlinks might end up pointing to the wrong binary, etc... that happened to me.

Besides if you replace some busybox symlinks with the full version, errors will occur, some apps are actually scripts like "ps"...

[musher0]

musher0, you must the use --remove-destination option

Code: Select all

cp -a --remove-destination source dest

--remove-destination first removes the target file, so the copy is secure.

If you use cp incorrectly, symlinks might end up pointing to the wrong binary, etc... that happened to me.

Besides if you replace some busybox symlinks with the full version, errors will occur, some apps are actually scripts like "ps"...

Thanks, jlst, I'll try your trick next time -- and double-check for reassurance!
The diff utility is very useful for that.

About the "apps-are-actually-scripts" thing, I did up the version of some utilities
using the most recent coreutils 8.25 package, but I'm not touching BK's scripts --
unless they seem to bring nothing.

As I said, I reviewed the copy "visually and manually". Besides, I'm talking about
the "burst" copy mode from point a to point b.

BFN.

[musher0]

So here it is, follks!

The first public alpha for Dpup Wheezy-3.14.56, named: dpw-3.14.56.1. The "1"
stands for this current attempt.
-- https://www.adrive.com/public/yXxyZu/dpw-3.14.56.1.iso--

~~~~~~~~~~~
Known issues:
* smoother activation of the sound card is still needed, IMO.

* pburn is de-activated; I've made it into a zip-lzip archive in /usr/local for the time
_ being. Feel free to unpack it and use it if you wish. This is NOT a comment on
_ zigbert's work, BTW. pfind works fine in other Pups.
_ I just have to debug this. In particular, the mount-FULL seems to hang when
_ using pfind in this Puppy. It's very stange.

* You cannot save your sessions to DVD. More debugging in sight.

* This alpha was created on a 1920x1080 monitor. Further work needs to be done
_ to place the icons on variously sized monitors. A script, probably. In the
_ meantime, simply move the icons where you like them to be on the ROX
_ background. Sorry for the inconvenience.

~~~~~~~~~~~
Plus-es:
* aemenu support not found in any jwm-powered Puppy

• -- for various stats: RAM usage, system temperature, current desktop, etc.
  -- for a time menu when you click either on the analog clock on screen or
  _ the digital clock in the jwm bar.
  -- to access +/- any part of the Linux tree (as in the screen capture).
  -- provides a "Recents" list and a "What's_Running" interface.

* jwm bar divided in two parts. (The icon and desk tray is in the middle at the
_ bottom.) This leaves more room for the list of runnning programs on the full bar

* some background (core) utilities have been updated to coreutils version 8.25.

* All programs in the jwm sub-menus have icons. (They didn't before.) The 1st level
_ does not show any icons, however. That is intentional, for harmonization with the
_ supporting aemenu menus.

* For convenience, some add'l archivers are included: lzop, lzip, lz4; also SFR's
_ PackIt and UExtract.

* A 2nd folder of jwm themes.

* The exceptional 3-degrees shadable (and beautiful) AkizaSans font (used
_ everywhere, in the jwm menu and for the ROX-desktop icons) and the Liberation
_ TTF font series (just as efficient as the DejaVu series, but it takes less space.)

* A brand new SLocate script, which allows you to save your results as text and to
_ skip the search on some partitions. Provides an info panel and a mini-launcher as
_ well. Only in this Pup!

~~~~~~~~~~~
Other features:
* Same kernel as the tahrpup-6.0.5-CE

* real acpi utility included for system temperature. (It's independent of the "acpid".)

* Real utilities replacing links to busybox applets: less-4.81, top-3.2.8, htop-1.09.
_ (Now we can really work!)

* Other: lsof, for ports monitoring in particular. But it also shines when you need to
_ know all the hierarchies of an app.

* osmo is gone, replaced by various gnumeric and notecase templates, plus a
_ memo script. I specifically wanted to annoy my good buddy French member pelo,
_ who simply adores osmo!
_ (Not true! Actually, I wanted to prove a point in favor of using templates. I've included
_ a number of templates usable OOTB at /root/my-documents/modeles.)

* Similarly I exiled the shamefully UTF-8 unfriendly gmeasures. I replaced it by our
_ own don570's very complete Puppy_Units and by the older (1995) but very
_ reliable tkmeasures, for people who prefer this type of interface.

* Speaking of tk, a couple of old tcl/tk games are now provided. Have fun!

~~~~~~~~~~~
Large browsers:
* You need to download and install a "big" browser. Until you do, the default browser
_ will be Links2. Now Links2 has outstanding performance considering its small size,
_ but it cannot do everything the big fellows do. For ex., using webmail is awkward
_ with Links2.

If you download one of the large browsers, may I suggest that you install it in your
/mnt/home directory and use symlinks to integrate it in your Puppy. For ex.:

* create a directory in /mnt/home/firefox(version_number)

* copy your firefox archive inside it and
_ unpack it.
_ You will now have a firefox directory with the most recent firefox inside it.
_ drag this firefox directory to /usr/lib as a symlink

* Now move the directories /root/.cache and /root/.mozilla to
_ /mnt/home/firefox(version_number)
_ now drag them back to root as symlinks

* The advantage of installing large browsers this way is that it does not penalize
_ your pupsave, it does not take away any space from your pupsave file.

~~~~~~~~~~~
Finally, I would be unforgivable not to thank:
* jlst for his module discovery script, without which I could not have come this far;
* gcmartin, for his indispensable moral support and testing;
* 666philb, for a test of the prototype and general encouragements;
* darry1966, for mouse tests; and of course:
* Barry Kauler, without whom there would be no PuppyLinux.

~~~~~~~~~~~
So... enjoy! Please click everywhere and test! Your feedback will be most welcome!

We continue!

[musher0]

Almost forgot the checksum:

76cf6a3473c6287c951f6201028dff48 dpw-3.14.56.1.iso

[gcmartin]

Hello @Musher0.

I downloaded Alpha1, burned to DVD, and booted without boot-option changes on the X2 that was running the pre-Alpha to the FirstRUN desktop window. Here, I check for wired ethernet and found the entry for setup missing. So, I filled in FirstRUN with localization needs, hit enter, allowed the desktop to restart (hostname) and on subsequent, the system has acquired its LAN and there is a window awaiting for sound. (shown below)

RAM usage, thus far

Code: Select all

Croyez pour être forts; aimez pour être heureux. (Hugo) | Thu 04 Feb, 22:13
[~]>eject
Croyez pour être forts; aimez pour être heureux. (Hugo) | Thu 04 Feb, 22:13
[~]>free
             total         used         free       shared      buffers
Mem:       2851404       338360      2513044            0        23740
-/+ buffers:             314620      2536784
Swap:      4235672            0      4235672
Croyez pour être forts; aimez pour être heureux. (Hugo) | Thu 04 Feb, 22:27
[~]>

Will continue to test. BTW: Seems much French in desktop even though FirstRUN choice was otherwise. You might want to "watch your language".

Question
Anyone else have trouble burning an ISO to DVD using Menu>Loisirs>Multimedia>PeasyDisc? After blanking a DVD+RW, Fast, I am getting the following:

Code: Select all

WARNING: /dev/sr0 already carries isofs!
About to execute 'builtin_dd if=/mnt/Laptop/Downloads/LInux/Puppy/DryFalls/Just-Lighthouse64-604.6.9.iso of=/dev/sr0 obs=32k seek=0'
:-( write failed: Invalid argument

Press Enter 

Hope this is useful