Why would a Puppy NOT load the zdrv.sfs? (SOLVED)

[rg66]

Here you go:
-- zdrv_wheezy_3.14.56.1.sfs
-- DISTRO_ZDRVSFS='zdrv_wheezy_3.14.56.1.sfs'

BFN.

That looks normal.

The init from testing has more zdrv code in it than master, diff attached below (fake .gz). Have you tried init from master to see if it loads the zdrv?

[Sailor Enceladus]

-- That the slackware repo doesn't have the latest version of less (rest assured I'll
double-check) is a poor excuse. Is Puppy so dependent on other distros' repos that
its developers cannot be pro-active? By not being pro-active, PuppyLinux will always
stay behind.

Yes, slackware 14.1 has less 4.51, and slackware current has 4.81. 14.1 is the "stable" branch and current is the "experimental" branch (as deemed by the slackware overlords) and Slackware's long-standing reputation is ease of use and stability, so I think it makes sense for Slacko to use the "stable" branch. Right now 14.1 is just receiving security updates and they are focusing innovation on the current branch, which will soon become 14.2. Maybe when 14.2 is released and becomes the new stable, we will see a Slacko 6.4 based on that one, which will have less 4.81. Looking forward to the release of 14.2 actually. But basically Slackware = stability first, innovation second (or something like that). This is kind of off-topic though.

If you are happy without a zdrv musher0, I say just keep doing it that way. Sorry if my message sounded like I was implying otherwise. Trying to load a kernel in puppy.sfs and a zdrv.sfs kernel together into ram at the same time sounds like a mess.

[LazY Puppy]

Here you go:
-- zdrv_wheezy_3.14.56.1.sfs
-- DISTRO_ZDRVSFS='zdrv_wheezy_3.14.56.1.sfs'

BFN.

That looks normal.

The init from testing has more zdrv code in it than master, diff attached below (fake .gz). Have you tried init from master to see if it loads the zdrv?

Where is it (the diff attached)?

mucher0 did you try the patched init script (patched from WoofCE init script)?

[rg66]

mucher0 did you try the patched init script (patched from WoofCE init script)?

Sorry, re-attached above. Musher is already using the testing init.

Edit: I've tried both init scripts and they both load the zdrv in X-slacko (slacko-6.3.0)

[jamesbond]

-- Well, jlst complained in the Pooch thread and elsewhere about not getting his ideas
accepted, that there was a lack of response from the Woof-CE leaders.

Well, not all of us can dedicate ourselves to doing our hobby. Sometimes real life takes over. And you get delays. I think jlst realised it later on.

I didn't get the impression that he was lying. I want to hear your comment about that -- coming from him.

No, I didn't imply that. I guess it's more of a misunderstanding and different expectation at the beginning, which seems to be solved now. Here is jlst's full list of *accepted* contributions: https://github.com/puppylinux-woof-CE/w ... esting?aut (the ones not accepted or pending is even longer).

-- As to feeding back my edits and findings, they are all in the "Pooch" thread
mentioned above. If that is not giving back to the community, what is? 01micko
tried to explain to me the push and pull at github, and it sounded as complicated as
any bureaucratic process.

It is getting back to the community, but not to Woof-CE. I know the process is not easy, but it helps everyone in the long run.

On the other hand, mavrothal said it was possible for pet archives to supersede
the defaults in Woof-CE. I understand this as follows: any and all interested people
can take any of my pet archives and introduce them in their Woof-CE process.

It works for your own personal build, but not for community work. Contributions needs to be sorted, and merged. Using your pets will use your enhancements but will overwrite others. So the exact changes from your enhancements mut be extracted and merged with others.

If the maintainers or admins of the Woof-CE do not want to go themselves search
for new potentially valuable stuff published through the forum, if they're not on the
look-out for it, if they absolutely want the faithful to bring their offerings to their
temple, they're partially proving my point.

You are just proving that they can't dedicate their entire time to enhance Woof-CE. If you want to help them, then you tell them how to fix the problem. Expecting them to come out and try to find fixes for problems they aren't even aware of is unreasonable.

-- As to becoming a maintainer of the Debian builds, given my lack of talent and
interest for any "bureaucratic process", the answer will be "no". There are already
people much more advanced than I am who are producing Debian builds: semme
and josejp2424, among others. Ask them.

Fair enough. You contribute where and when you want, and don't feel forced to do anything you don't like.

-- That the slackware repo doesn't have the latest version of less (rest assured I'll
double-check) is a poor excuse. Is Puppy so dependent on other distros' repos that
its developers cannot be pro-active? By not being pro-active, PuppyLinux will always
stay behind.

That's not an excuse, that's the rule. The reason why there is a tahrpup (or dpup, for that matter) is because want to use their packages. This requires binary compatibility. Binary compatibility demands that you make as little changes as possible to other packages - packages are like gears and cogs; they need to work together. If you add too many "foreign" (ie self-compiled PETs), some of these fine meshes may fail to work.

If you really want to always use the latest and greatest, you have to build everything yourself.

-- Finally, I'll dispute your opinion that obviously useful utilities such as less, tree,
any type of locate, and the inclusion of the latest versions of the core GNU utilities
are open to subjective choice.

Why do other distros have them by default and we don't? Give me a good reason
why PuppLinux should be making computer life more difficult and complicated for its
users than the other distros.

I will leave it on the record that we agree to disagree. One man's food is another's poison. Just because you like to use terminal doesn't mean the guy next door do.

I fought to have the real less included in Puppy, and I'll fight for the general concept
as well -- unless you guys manage to demotivate me completely about the Puppy.

There is no need to fight. You need to consider who you are building for. If it is for yourself, then by all means add any tools you want. If it is for others, perhaps it's good to run a short poll or something, to see that your favorite tool is actually favorite in the eyes of other too. One of puppy's objective has always been the size. The full tools almost always are bigger and requires more RAM to use. You may disagree but this is still one of Puppy's guiding principles. It's the one that avoid Puppy ballooning up to bcome a 2GB distro. We can disregard this principle (within reason of course) if there is good reason - and one of the good reason is "popular demand"; however, this demand must be substantiated, e.g. by holding a pool.

For the record, I use terminal heavily and I have many of the full tools (coreutils less etc) included by default in Fatdog. This is a conscious decision that kirk made years ago. The reason is simple. In 64-bit systems, the minimum amount of RAM avaialable is usually 1GB or more. Thus memory pressure is never a problem for us. Puppy is different.

Anyway, this is out of topic and is getting in your way to find a solution for your problem. I'll let you have the final words - and I'll bow out of this thread, unless you specifically invite me back.

[saintless]

How can I re-activate the zdrv?

Seems zdrv loading works for me.
Just made quick test downloading dpw-3.14.56.1.iso frugal install on sda1 using this boot code:

Code: Select all

title Pooch 
rootnoverify (hd0,0)
kernel /POOCH/vmlinuz pmedia=atahd psubdir=POOCH nosmp
initrd /POOCH/initrd.gz

No changes in initrd or anything else. Just extracting the sfs, vmlinuz and initrd.gz from the iso inside /media/sda1/POOCH folder.
Then I made 4 sfs files inside /media/sda1/POOCH :

Code: Select all

root@debian:~# ls -l /media/sda1/POOCH
total 152696
-rw-r--r-- 1 root root      4096 Mar 27 17:35 adrv_wheezy_3.14.56.1.sfs
-rw-r--r-- 1 root root      4096 Mar 27 17:36 fdrv_wheezy_3.14.56.1.sfs
-rw-r--r-- 1 root root   1324144 Feb  3 00:08 initrd.gz
-rw-r--r-- 1 root root 151293952 Feb  4 10:25 puppy_wheezy_3.14.56.1.sfs
-rw-r--r-- 1 root root   3556336 Jan 24 01:27 vmlinuz
-rw-r--r-- 1 root root      4096 Mar 27 17:36 ydrv_wheezy_3.14.56.1.sfs
-rw-r--r-- 1 root root      4096 Mar 27 17:36 zdrv_wheezy_3.14.56.1.sfs
root@debian:~# 

adrive...sfs contains only /adrive.txt file
zdrive...sfs contains only /zdrive.txt file
ydrive...sfs contains only /ydrive.txt file
fdrive...sfs contains only /fdrive.txt file

Then boot and starting xorg fails with some error about no dislpay found (but it doesn't make any difference for the test).
Fdrive sfs is not loaded but adrive, ydrive, zdrive are all loaded on boot because the system finds the txt files in / after boot. Here is the output of ls command:

Code: Select all

ls /
adrive.txt
archive
bin
boot
dev
etc
initrd
lib
mnt
opt
proc
root
run
sbin
selinux
sys
tmp
usr
var
ydrive.txt
zdrive.txt

Code: Select all

ls -l /

-rw-r--r--  1 root root     0 mar 27 10:34 adrive.txt
drwxrwxrwx  2 root root    41 jan 14 18:12 archive
drwxr-xr-x  2 root root  3132 fév  4 02:51 bin
drwxr-xr-x  2 root root    33 déc 21 09:54 boot
drwxr-xr-x 11 root root 14020 mar 27 14:40 dev
drwxr-xr-x 55 root root   280 mar 27 14:40 etc
drwxr-xr-x 17 root root   360 mar 26 11:39 initrd
drwxr-xr-x 14 root root   100 mar 26 11:39 lib
drwxr-xr-x 36 root root    60 mar 26 11:40 mnt
drwxr-xr-x  2 root root     3 jan 16 17:37 opt
dr-xr-xr-x 80 root root     0 mar 27 10:39 proc
drwxr-xr-x 41 root root    60 mar 27 14:40 root
lrwxrwxrwx  1 root root     3 fév  3 23:24 run -> tmp
drwxr-xr-x  2 root root  3327 fév  4 03:02 sbin
drwxr-xr-x  2 root root     3 jan 16 23:28 selinux
dr-xr-xr-x 12 root root     0 mar 26 11:39 sys
drwxrwxrwt  9 root root   480 mar 27 14:40 tmp
drwxr-xr-x 14 root root    60 mar 26 11:40 usr
drwxrwxrwx 23 root root   160 mar 27 14:40 var
-rw-r--r--  1 root root     0 mar 27 10:34 ydrive.txt
-rw-r--r--  1 root root     0 mar 27 10:34 zdrive.txt

I'm not sure what is the problem with kernel modules loading or how exactly each adrive, zdrive, ydrive layer should work, but they work for me loading new (not existing in main sfs) files.

Edit: Zdrv works fine in my opinion and seems the xorg problem I have is caused by the included kernel. Using older kernel from Slacko as zdrv.sfs with the same initrd.gz from the iso boots to desktop without issues.
Click here for screenshot.
If you like to test it here is temporary download link for kernel-3.4.93-slacko.zip
md5sum: 8d102600e8a981e9d8fd282c3c484964
Just rename vmlinuz and use the sfs and vmlinuz from the archive to boot Pooch frugal.

Toni

[LazY Puppy]

Just because you like to use terminal doesn't mean the guy next door do.

Agreed!

My only use of the/a terminal is on development/programming, as it is really useful then.

It's much less useful to execute GIMP etc.pp. by terminal and then to kill it accidentially by closing the terminal window accidentially without having the edited image stored!

I like and I prefer to use the Menu and/or Desktop Icons.

[musher0]

Many thanks to all of you: LazY_Puppy, nic007, rg66, Sailor_Enceladus, saintless,
for your valuable inputs, research and / or testing. I am quite grateful.

I'll need a few hours to apply your findings in a new alpha-2 "Pooch".

I think that I'll stick, for now, with the all-modules-in-the-main-sfs solution, as some
of you have suggested, for practical reasons -- reassured by tests by saintless and
others that the present init can indeed load zdrv, adrv and ydrv. Should a need arise
in the future to have a zdrv, for whatever reason, "The Pooch" will be able to do it.

This has been a very good thread. Vigorous, too, in some posts ! ( to jamesbond!)

I'll mark this thread as solved, but if you have other good ideas on the subject, don't
be afraid to post here again!

Again thanks, and Happy Easter, if it's still Sunday in your time zone!

BFN.

[gcmartin]

One of the ideas of recent days, by several members in this thread, focused on out-of-date GNU utilities. IMHO, there are 4 PUPs which seemingly make a conscious attempt to provide a full compliment of the utilities and also make attempts to keep current versions available. So from the standpoint that many mainline Linux distros do a creditable job seeing that current versions are present, it might be time for a Puppy Linux review of the benefit of keeping its versions up-to-date as a universal package. The 4 I've found are Lighthouse-JustLighthouse, Fatdog, Emsee, and.

Since GNU utilities are primarily universal across Linuxes, a full up-to-date "universal" package could be made available to ALL PUP WOOFCE builds. Thus, this would pave the way that any BASH/ASH script written would work in every PUP the same way as they would all have the same features. That is that tree/locate/other GNU commands would be current and present in new WOOFCE PUPs.

This is NOT a thought offered to retrofit all past PUPs. Rather it is one for updating WOOFCE with a more modern GNU packaging. 1GB+ RAM x86 PCs/Tablets are ever-present today. So all new PUPs can publish, in their Opening Post's credits, what the distro developer feels is the minimum machines that their distro will operate comfortably on.

In the past decade, I have not found ANY PUP distro that did NOT load or complain about RAM availability in its loading or operating. I run with SWAP files that match each PCs RAM. On EVERY new distro boot, I run FREE command and publish so that the developers can see system RAM use at starts.

This is hoped that WOOFCE developers consider whether this offers widespread community value for a fuller and more complete GNU for PUPPY use to both its developers and its users.

Hope this helps
P.S. Rather than picking and choosing specific GNU Utility commands (as has been done a decade ago) for WOOFCE, an idea; why not include a complete package GNU utilities that has not been indiscriminately cut down to some individual desire.

If this idea does not match, then maybe the WOOFCE packagers can provide a PET that is a complete up-to-date version in their REPOs.