Page 7 of 42
Posted: Sun 22 Jun 2014, 16:14
by mavrothal
SFR wrote:I finally realized that it's because aufs is not compiled as an external module anymore.
....
So, what we're gonna do? I see 2 scenarios:
1. If there's a way to detect if aufs is built into vmlinuz (dunno how) it would be a matter to add an additional test for it.
2. Don't check for aufs at all (and additionaly remove all stuff related to unionfs, if we're sure the latter won't be used in the future).
Good catch!
should do it but for some reason /proc/config.gz is not there
/etc/modules/modules.builtin is another place to check but not as safe as /proc/config.gz.
Though option 2 might be better. Is a long time that puppy stopped using unionfs
Posted: Sun 22 Jun 2014, 16:43
by zigbert
Something has happened to gtk since the alpha
This mis how it looks in the 591
Posted: Sun 22 Jun 2014, 16:58
by SFR
mavrothal wrote:SFR wrote:I finally realized that it's because aufs is not compiled as an external module anymore.
....
So, what we're gonna do? I see 2 scenarios:
1. If there's a way to detect if aufs is built into vmlinuz (dunno how) it would be a matter to add an additional test for it.
2. Don't check for aufs at all (and additionaly remove all stuff related to unionfs, if we're sure the latter won't be used in the future).
Good catch!
should do it but for some reason /proc/config.gz is not there
/etc/modules/modules.builtin is another place to check but not as safe as /proc/config.gz.
Though option 2 might be better. Is a long time that puppy stopped using unionfs
Yes, I also noticed that
/proc/config.gz is not present in k.3.4.x, but it is in 3.10.x.
Yeah, I would vote for 2 either, or eventually:
3. Check for unionfs and if not present, always assume aufs:
lsmod | grep '^unionfs' && unionfs || aufs
but I don't see a point TBH...
Greetings!
Posted: Sun 22 Jun 2014, 17:00
by jamesbond
SFR wrote:So, what we're gonna do? I see 2 scenarios:
1. If there's a way to detect if aufs is built into vmlinuz (dunno how) it would be a matter to add an additional test for it.
2. Don't check for aufs at all (and additionaly remove all stuff related to unionfs, if we're sure the latter won't be used in the future).
Let's opt for 1). The check is already done by initrd, this check should not be duplicated in every programs. To cater for full install, perhaps rc.sysinit could check too (because initrd isn't used in full install, innit?) and save the result, say, in PUPSTATE? In woof-next's initrd, aufs is assumed by default, except when overriden by "layerfs=unionfs" on kernel command line. So if you want to have a check, let's do that check (grep -q layerfs /proc/cmdline). You can of course go with /proc/config.gz test, but this assumes that CONFIG_IKCONFIG_PROC is set. Actually, on the second though, for stuff apps like these, what is their business detecting the layerfs system? They should only worry whether they're running on full install, ram layer, or direct savefile, shouldn't they? Then they should look at PUPMODE alone.
Posted: Sun 22 Jun 2014, 17:10
by peebee
shinobar wrote:5. Reboot PC. Got panic.
Occurs with any sfs.
Loading sfs-on-the-fly is ok. But gets panic at next boot.
I also get kernel panic on reboot if I install any sfs - tried quite a few different ones.
This is a manual frugal install to a subdirectory with the sfs's in the subdirectory. The panic occurs with both the old savefile and the new savedirectory after reboot.
Error messages are the same as SFR's screenie below.
Also, think the removal of broadcom b43 wireless firmware (and others?) is a really retrograde step as it removes one of puppy's great strengths of wifi support OOTB - does the saving of a a few mb's in the iso size really matter these days????
Cheers
peebee
Posted: Sun 22 Jun 2014, 17:18
by SFR
Me too, here's the shot.
[later]
From what I've seen in init, loading the additional SFS files starts from
/dev/loop4, so I think it's in conflict with
this:
Code: Select all
mount -r -t squashfs -o noatime /dev/loop4 /pup_z
Greetings!
Posted: Sun 22 Jun 2014, 17:37
by bigpup
Noticed the download size of Slacko-5.9.2.iso is
smaller than Slacko-5.9.1.iso.
Slacko-5.9.2.iso --167M
Slacko-5.9.1.iso --174M
Anything important get left out?
Why is this so big?
Firmware. I may trim that substantially -done.
What firmware did you delete?
Posted: Sun 22 Jun 2014, 17:59
by ttuuxxx
Hi Micko, I haven't downloaded 6 yet, but still using 5.7, I noticed that your Menu icons you included in 5.7 weren't changing all the icons when I tried the different ones included. So I spent a few hours and updated Bluemoon, it works with all the Desktop/menu icons and its now 21kb compressed smaller than before, its 88kb
Jeff
PS the Yasis theme has /usr/local/lib/X11/themes/yasis/shutdown24.png it should be /usr/local/lib/X11/themes/yasis/shutdown48.png It doesn't change the menu shutdown icon unless its changed from 24 to 48
Posted: Sun 22 Jun 2014, 18:05
by musher0
@01micko
You just renamed the devx, right?
slacko-6.0 beta
Posted: Sun 22 Jun 2014, 18:08
by Billtoo
Manual frugal install to an 8gb sdhc card.
video-info-glx 1.5.1 Sun 22 Jun 2014 on Slacko Puppy 5.9.2 Linux 3.4.94 i686
5.0 VGA compatible controller: ATI Technologies Inc Radeon HD 3200 Graphics
oem: ATI ATOMBIOS
product: RS780 01.00
X Server: Xorg Driver: radeon
X.Org version: 1.14.3
dimensions: 3840x1080 pixels (507x285 millimeters)
depth of root window: 24 planes
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RS780
OpenGL version string: 2.1 Mesa 9.1.7
AMD Phenom(tm) II X4 810 Processor
Core 0: @2592 1: @2592 2: @2592 3: @2592 MHz
I loaded the devx and used the zarfy.SlackBuild, then made a
package-zarfy-0.1.0.pet.
Unloaded the devx and rebooted because leaving it loaded creates a
kernel panic next bootup as others have reported.
Firefox runs as user spot now.
EDIT:
Here's the package-zarfy-0.1.0.pet if anyone else needs it, I copy /usr/bin/zarfy to /root/startup and it runs every bootup or whenever X is restarted to setup for 2 monitors.
EDIT:
I removed the package-zarfy-0.1.0.pet, the zarfy.SlackBuild worked for me but making it into a pet made an incomplete pet.
The zarfy.SlackBuild can be downloaded from here:
http://slackbuilds.org/repository/14.1/ ... arch=zarfy
Posted: Sun 22 Jun 2014, 19:39
by ttuuxxx
here's the stardust theme fixed. I renamed and drop what wasn't needed.
Ps
Its 5:38am I'll do the rest tomorrow if you want, Need to get some sleep
Jeff
Posted: Sun 22 Jun 2014, 20:37
by MinHundHettePerro
Hello!
Changing line 1651 of initrd_/init from
to
solves the problem with kernel panic for BOOTCONFIGged sfs-files. (At least for me ...)
Cheers
/ MHHP
Posted: Sun 22 Jun 2014, 20:47
by 01micko
peebee wrote:Also, think the removal of broadcom b43 wireless firmware (and others?) is a really retrograde step as it removes one of puppy's great strengths of wifi support OOTB - does the saving of a a few mb's in the iso size really matter these days????
Firstly .. wasn't on purpose of course. included wrong tarball
. I'll upload a new kernel package soon, which will have an identical set of modules but the missing firmware will be back.
Secondly... absolutely iso size is important! As James C can testify. this thing (well alpha) can run (crawl?) on an old coppermine and it is the reason i'm going no PAE. 64 bit will be a different story.
SFR and peebee and others wrote:kernel panic on reboot if I install any sfs
Conflict in init. If you want to keep testing use the old init attached.. expand initrd.gz and replace init. OR try MHHP's suggestion above this post.
zigbert wrote:Something has happened to gtk since the alpha
Only thing remotely related is the removal of gtk-chtheme.. so it beats me
musher0 wrote:You just renamed the devx, right?
No, but changes are not that big in devx so a rename is safe enough, but you need to roll back init as mentioned to use it. OR, try MHHP's suggestion above.
-
Thanks all.
Posted: Sun 22 Jun 2014, 21:05
by 01micko
MinHundHettePerro wrote:Hello!
Changing line 1651 of initrd_/init from
to
solves the problem with kernel panic for BOOTCONFIGged sfs-files. (At least for me ...)
Cheers
/ MHHP
Tested with devx, libreoffice, adrv (gimp sfs renamed) and ydrv (jre by shino sfs renamed) and it all works.
Posted: Sun 22 Jun 2014, 21:12
by MinHundHettePerro
Yes, I hope that small change is all that is needed.
Before, /dev/loop4 got mounted on /pup_z and the first EXTRASFS got losetup'ed on /dev/loop4 and then mounted on /pup_ro4 ...
Cheers /MHHP
Posted: Sun 22 Jun 2014, 21:20
by SFR
@Mick: what about those lsmod | grep '^aufs' tests?
I don't want to make any changes to the affected scripts, until we agree which procedure should be the standard from now on.
Greetings!
Posted: Sun 22 Jun 2014, 21:35
by 01micko
SFR wrote:@Mick: what about those lsmod | grep '^aufs' tests?
I don't want to make any changes to the affected scripts, until we agree which procedure should be the standard from now on.
Greetings!
2. Don't check for aufs at all (and additionaly remove all stuff related to unionfs, if we're sure the latter won't be used in the future).
Unionfs hasn't worked properly in the kernel for over 4 years. They have shifted to a userspace model.
I vote option 2.
/proc/config.gz has gone missing. CONFIG_IKCONFIG is not set. I don't *think* anything depends on it, but /etc/modules/DOTconfig is always there and /lib/modules/`uname -r`/modules.builtin has to be there else depmod doesn't work .. and of course it is.
Posted: Sun 22 Jun 2014, 21:47
by Billtoo
MinHundHettePerro wrote:Hello!
Changing line 1651 of initrd_/init from
to
solves the problem with kernel panic for BOOTCONFIGged sfs-files. (At least for me ...)
Cheers
/ MHHP
I did the edit, loaded the devx and kernel source sfs with SFS-Load on-the-fly, then rebooted and everything is good.
Thanks
Posted: Sun 22 Jun 2014, 21:55
by SFR
01micko wrote:2. Don't check for aufs at all (and additionaly remove all stuff related to unionfs, if we're sure the latter won't be used in the future).
Unionfs hasn't worked properly in the kernel for over 4 years. They have shifted to a userspace model.
I vote option 2.
Ok,
done.
Greetings!
Posted: Sun 22 Jun 2014, 21:58
by 01micko
@SFR .
The case where the user (KRG comes to mind) uses a FULL install and builds his own kernel without AUFS may be a problem.. like I said.. modules.builtin has to be there or else depmod fails.
Anyway, just seen you posted; option 2 should be good for the use case I just mentioned.