Things YOU can help with.

[brokenman]

The following things require attention and I could really use the help of the community in getting them ready.

1. Graphics drivers ATI/nVidia (for current ISO on server)
2. Printer module (both architectures)

Unsolved bugs
1. The output of df shows loop devices. I am told this was not the case in v3.1.
2. Some systems take a long time to boot (network related) Without the logs from these machines I can do nothing.
3. For some languages, when the language tool is run and you reboot, folders in /home/guest are not replaced but additional ones are created.

[Blaze]

07-printing-x86_64-18.10.2016.xzm
For x86 (32 bit) at this moment I'm busy - may be so later, I have a many job now. Sorry.

[jssouza]

The output of df shows loop devices. I am told this was not the case in v3.1.

This could be the explaination:

On Porteus 3.2:

Code: Select all

guest@porteus:~/Downloads/coreutils-8.25$ find /var/log/packages/ -name *squashfs* -type f
/var/log/packages/squashfs-tools-4.3-x86_64-1

On Porteus 3.1:

Code: Select all

guest@porteus:~/Downloads/coreutils-8.25$ find /var/log/packages/ -name *squashfs* -type f
/var/log/packages/squashfs-tools-4.3-x86_64-1ftm

This may mean that coreutils was compiled on stock slackware without squashfs support (added later by porteus), while in slackware 14.2, coreutils was also linked with squashfs support.

On Porteus 3.2 the following could be used to hide loop devices:

Code: Select all

df --exclude-type=squashfs -h 

Why I say could be the explaination, is because actual mounting of the squashfs would be done by the kernel, which I guess was already supporting it during porteus 3.1.

[Ed_P]

FWIW

3.0

Code: Select all

guest@porteus:~$ df
Filesystem     1K-blocks      Used Available Use% Mounted on
aufs             1066224      5652   1060572   1% /
devtmpfs          887760         0    887760   0% /dev
/dev/sda1       13631484  10424964   3206520  77% /mnt/sda1
/dev/sda2         102396     32348     70048  32% /mnt/sda2
/dev/sda3       59834364  38157004  21677360  64% /mnt/sda3
/dev/sda5       87000060  67489048  19511012  78% /mnt/sda5
/dev/sda6      151995384 105834288  46161096  70% /mnt/sda6
/mnt/live/run     888516      2364    886152   1% /run
guest@porteus:~$ uname -a
Linux porteus 3.14.15-porteus #1 SMP PREEMPT Sun Aug 3 12:01:20 Local time zone must be set--s x86_64 AMD C-60 APU with Radeon(tm) HD Graphics AuthenticAMD GNU/Linux
guest@porteus:~$ 

3.1

Code: Select all

guest@porteus:~$ df
Filesystem     1K-blocks      Used Available Use% Mounted on
aufs             1421632      6168   1415464   1% /
devtmpfs          887760         0    887760   0% /dev
/dev/sda1       13631484  10424964   3206520  77% /mnt/sda1
/dev/sda2         102396     32348     70048  32% /mnt/sda2
/dev/sda3       59834364  38156104  21678260  64% /mnt/sda3
/dev/sda5       87000060  67489052  19511008  78% /mnt/sda5
/dev/sda6      151995384 105834288  46161096  70% /mnt/sda6
/mnt/live/run     888516      2280    886236   1% /run
guest@porteus:~$ uname -a
Linux porteus 3.14.15-porteus #1 SMP PREEMPT Sun Aug 3 12:01:20 Local time zone must be set--s x86_64 AMD C-60 APU with Radeon(tm) HD Graphics AuthenticAMD GNU/Linux
guest@porteus:~$ 

http://forum.porteus.org/viewtopic.php?f=81&t=4168&start=30#p31112

3.2

Code: Select all

guest@porteus:~$ df
Filesystem     1K-blocks      Used Available Use% Mounted on
tmpfs             887988      2428    885560   1% /mnt/live
devtmpfs          886496         0    886496   0% /dev
/dev/sda1       13631484  10424964   3206520  77% /mnt/sda1
/dev/sda2         102396     32348     70048  32% /mnt/sda2
/dev/sda3       59834364  38155376  21678988  64% /mnt/sda3
/dev/sda5       87000060  67489056  19511004  78% /mnt/sda5
/dev/sda6      151995384 105834288  46161096  70% /mnt/sda6
/dev/loop0        272526    272526         0 100% /mnt/live/mnt/isoloop
tmpfs            1065588     96284    969304  10% /mnt/live/memory/changes
aufs             1065588     96284    969304  10% /
/dev/loop1         45312     45312         0 100% /mnt/live/memory/images/000-kernel.xzm
/dev/loop2         68864     68864         0 100% /mnt/live/memory/images/001-core.xzm
/dev/loop3         78592     78592         0 100% /mnt/live/memory/images/002-xorg.xzm
/dev/loop4         75008     75008         0 100% /mnt/live/memory/images/003-cinnamon.xzm
/dev/loop5         61952     61952         0 100% /mnt/live/memory/images/07-printing-x86_64-18.10.2016.xzm
/dev/loop6         50176     50176         0 100% /mnt/live/memory/images/firefox-50.0b5-x86_64-1.xzm
/dev/loop7          5376      5376         0 100% /mnt/live/memory/images/flashplayer-plugin-23.0.0.205-x86_64-1.xzm
/dev/loop8        324260    153732    170528  48% /mnt/live/memory/images/changes
tmpfs             887988       116    887872   1% /dev/shm
guest@porteus:~$ uname -a
Linux porteus 4.8.7-porteus #1 SMP PREEMPT Fri Nov 11 19:37:24 BRST 2016 x86_64 AMD C-60 APU with Radeon(tm) HD Graphics AuthenticAMD GNU/Linux
guest@porteus:~$ 

[Bogomips]

Tackling nvidia (304.131) 64 bit for current iso on server.

[brokenman]

https://lists.gnu.org/archive/html/bug- ... 00170.html
https://bugzilla.redhat.com/show_bug.cgi?id=1305431

This link complained about the same thing back in 2013. I don't think the reason is squashfs-tools. The SlackBuild for this merely generates the binaries unsquashfs and mksquashfs. More likely it is coreutils or the kernel itself but I need to dig deeper.

EDIT: In the second link it appears to be the change from mtab to a symlink pointing to /proc/mounts. I believe df is looking at /proc/mounts now.

[jssouza]

Thanks for the links brokenman.

I believe df is looking at /proc/mounts now.

Yes, you are right. I downloaded and compiled df from coreutils-8.21 on Porteus 3.2. (Porteus 3.0.1 has coreutils-8.21). Running it, it did not show the loop devices.

Code: Select all

guest@porteus:~/Downloads/coreutils-8.21$ ./src/df 
Filesystem     1K-blocks      Used Available Use% Mounted on
aufs             7343640    144196   7199444   2% /
devtmpfs         6118120         0   6118120   0% /dev
/dev/sda1         409596    309568    100028  76% /mnt/sda1
/dev/sda2         262144    110136    152008  43% /mnt/sda2
/dev/sda4      921603864 162352636 759251228  18% /mnt/sda4
/dev/sda5       17170428  15434072   1736356  90% /mnt/sda5
/dev/sda6       12253360   4692116   6915768  41% /mnt/sda6
/dev/sdb1        8033952   6241552   1792400  78% /mnt/sdb1
tmpfs            6119696       116   6119580   1% /dev/shm
/mnt/live/run    6119696      2528   6117168   1% /run

Regarding this:

For some languages, when the language tool is run and you reboot, folders in /home/guest are not replaced but additional ones are created.

I downloaded and created the language files and booted with these xzms and I immediately found the additional directories. But further investigating it was because I had the 'US' directories in a changes.xzm. Removing the xzm from the load path and rebooting showed only the translated directories. Could it also have been the case? Maybe try in AF mode?
Also, when creating the language translations, if bootmode was with from=/path-to.iso then the script fails at the end when it tries to move the created xzms to the modules folder. The created xzms are also not found so I had to redo it in another boot mode. Maybe check if booted device is writable at the beginning?

[brokenman]

Thanks. I'll recompile coreutils.

I couldn't reproduce the extra folders in home here. Donald, is it possible that you also have them in changes somewhere?

There is an early check in the gtk-language-selection script to see if the modules directory is writable. If not then the target becomes /tmp/language-files
I will boot from ISO and check it out. Thanks.

[donald]

Well, i deleted the US-Folders and they didn't came back.
(nothing to find in the changes Folder now)

Good News
I renamed the changes folder > reboot with the Language-Modules
and only the translated Folders came up -- no US ones!!

So one has to fetch the Language Modules first, before saving changes.

[fulalas]

Well, now I think I have a stable Nvidia driver module for Porteus 3.2 x64: http://www.mediafire.com/file/3ylt1meyu ... x86_64.xzm

[brokenman]

Great. If this can be confirmed by another user then we just need another for 32bit and I can use them.
Please record your steps so you can easily generate another for the next kernel. Thanks.

EDIT:
Tradeoff in coreutils make it not worth the downgrade. Too many outdated binaries to justify the cause (loops showing in df command)
Thanks for sorting it out jssouza.

[brokenman]

Great. If this can be confirmed by another user then we just need another for 32bit and I can use them.
Please record your steps so you can easily generate another for the next kernel. Thanks.

EDIT:
Tradeoff in coreutils make it not worth the downgrade. Too many outdated binaries to justify the cause (loops showing in df command)
Thanks for sorting it out jssouza.

EDIT2:
Thanks jssouza. Bug in gtk-language-selection when booting from ISO confirmed.
Should be fixed on server now. Files land in /tmp/language-files

[Blaze]

2. Printer module (both architectures)

I have done it for both architectures. More info here.

[francois]

Good work. I have updated the first post of the printer thread to provide these new versions of the printing package.

All we need now is as much as printer testers as possible. I will test on my brother and samsung laser printers this weekend.

Thanks blaze.

[brokenman]

Nice work. You guys rock!

So the plan is to wait for the new 4.9 LTS kernel (and perhaps xorg-1.19.0) and then push another version.