Tiny Core Linux

Tiny Core Base => TCB News => Release Candidate Testing => Topic started by: Juanito on January 22, 2016, 05:47:03 AM

Title: Core v7.0beta3
Post by: Juanito on January 22, 2016, 05:47:03 AM
Team Tiny Core is pleased to announce that Tiny Core 7.0 Beta3 is available for public testing:

http://repo.tinycorelinux.net/7.x/x86/release_candidates/
http://repo.tinycorelinux.net/7.x/x86_64/release_candidates/

This is an beta level cut. If you decide to help test, then please test carefully. We don't want anyone to lose data.

Most extensions have been copied over from the 6.x repo - note that the alsa extensions have been refactored and updated and the Xorg-7.7 extensions have been updated.

We appreciate testing and feedback.

If you use distribution files note that you need a new vmlinuz and core.gz (or rootfs.gz + modules.gz)

Changelog for 7.0 beta3:
* busybox: remove obsolete /usr/bin/length
* tce-setup: quiet cd -, by vt1431
* i2c-algo-bit kernel module moved from the i2c extension to the base

Changelog for 7.0 beta2:
* busybox patched to fix "crontab -e" error
* kernel updated to 4.2.9 with the latest stable patch, with these config changes:
  - minstrel enabled for some wireless cards
  - vmmouse disabled for VMWare + Xvesa
  - the cpu limit on the 64-bit kernel raised to 64

Changelog for 7.0 beta1:
* busybox updated to 1.24.1
* kernel updated to 4.2.7
* glibc updated to 2.22
* gcc updated to 5.2.0
* e2fsprogs base libs/apps updated to 1.42.13
* util-linux base libs/apps updated to 2.27

Note that the drm/i915 kernel driver error is still not fixed.
Title: Re: Core v7.0beta3
Post by: andyj on January 22, 2016, 06:47:31 AM
This issue was originally part of the -beta2 thread, but since that's now closed I'm resuming it here. Picking up where we left off:

I found that libffi and gamin don't change the permissions by themselves if you load them manually before glib2. I tried reloading the rules but that by itself didn't correct the permissions. In /etc/udev/rules.d/50-udev-default.rules I added

KERNEL=='"fuse", ACTION="change", MODE="0666"

after the fuse add rule, then when I run

udevadm trigger --action=change --sysname-match=fuse

the permissions are reset. Is there a reason not to add this rule to core.gz? There's a 99-fuse.rules in the fuse extension but it apparently doesn't have the desired effect, and if there is already a fuse rule in core.gz then isn't the extension rule redundant? Then in open-vm-tools I could run udevadm instead of just setting the permissions directly. This seems like a much cleaner solution.
Title: Re: Core v7.0beta3
Post by: curaga on January 22, 2016, 09:00:26 AM
We could add the rule to base too, but changing fuse.tcz is easier.
Title: Re: Core v7.0beta3
Post by: andyj on January 22, 2016, 09:25:37 AM
I like simple and clean. Having one place where the fuse rules are maintained seems like it would be easier than two. Since /dev/fuse is in core.gz and there's already a rule in core.gz for fuse, I say add the new rule to core.gz and keep it all in one place. The flip side is to have the fuse extension create the fuse device on load and have the rules get added and processed by the extension, or do part in core.gz and part in the extension. The problem with having just the change rule in the extension is that the extension would have to be loaded and loaded early for the permissions to stay correct. All that sounds harder, but I'm not the maintainer of either core.gz or fuse.tcz. I am however the open-vm-tools.tcz maintainer (at least for now) so all I need to know is that somewhere there will be a rule such that if I run udevadm the permissions for /dev/fuse will be correct.  Better yet the permissions will already be correct because all the other extensions that try to change fuse when they load will be changing it correctly and I wouldn't have to worry about it at all.
Title: Re: Core v7.0beta3
Post by: curaga on January 22, 2016, 09:51:26 AM
Do you operate on fuse in the startup script, or is it only done when the user asks for it?
Title: Re: Core v7.0beta3
Post by: andyj on January 22, 2016, 10:13:03 AM
The user runs vmhgfs-fuse to mount the shared host filesystem folder into the guest filesystem on a mount point presumably in the user's home directory. I recommend that the user add the following to their .profile before startx:

[ $(which vmware-checkvm) ] && [ $(which vmhgfs-fuse) ] && mkdir -p $HOME/hgfs && vmhgfs-fuse $HOME/hgfs

Because it's a userspace application, the permissions need to already be set before it's run. I (or somebody) would have to write a wrapper script otherwise.
Title: Re: Core v7.0beta3
Post by: curaga on January 22, 2016, 10:15:00 AM
OK, then changing fuse.tcz is enough. Once it's fixed, there will be no problems with the ordering, after boot /dev/fuse will have correct permissions, and they will stay correct.
Title: Re: Core v7.0beta3
Post by: andyj on January 22, 2016, 02:58:56 PM
While looking around kernel.org I couldn't help but notice that the 4.2 series isn't listed as stable or longterm, and 4.2.9 isn't even an available version for download or to look at the changelog. What am I missing?
Title: Re: Core v7.0beta3
Post by: Rich on January 22, 2016, 05:37:33 PM
Hi andyj
See:
http://forum.tinycorelinux.net/index.php/topic,19505.msg120528.html#msg120528
Title: Re: Core v7.0beta3
Post by: andyj on January 22, 2016, 05:47:51 PM
I guess I didn't catch that the first time. Still, TC as an Ubuntu fork, I didn't see that coming... Being a slacker for over two decades I must just be a purist at heart. It just feels wrong. ;D
Title: Re: Core v7.0beta3
Post by: Rich on January 22, 2016, 06:45:46 PM
Hi andyj
I didn't realize the kernel source was from Ubuntu either. I always though it came from kernel.org. Regardless, you got
your answer.
Title: Re: Core v7.0beta3
Post by: Juanito on January 22, 2016, 08:32:13 PM
@curaga/andyj - if you could confirm the rules change required to the fuse extension, I'll make the changes.
Title: Re: Core v7.0beta3
Post by: curaga on January 23, 2016, 01:42:42 AM
I've updated fuse.tcz in x86 and x86_64.

When adding udev rules, udev has to be told to reload them. Then a trigger should be done, in case another extension did a trigger before fuse, and no extension would do one after it.
Title: Re: Core v7.0beta3
Post by: curaga on January 23, 2016, 01:45:07 AM
I guess I didn't catch that the first time. Still, TC as an Ubuntu fork, I didn't see that coming... Being a slacker for over two decades I must just be a purist at heart. It just feels wrong. ;D

I did go over the patches included just in case ;) They were competent stable patches.

It is not an Ubuntu kernel in the sense of foo-ubuntu7, ie no Ubuntu-specific patches.
Title: Re: Core v7.0beta3
Post by: andyj on January 23, 2016, 06:34:32 AM
The updated fuse.tcz seems to be working, in the sense that I don't have to set any permissions now. I haven't really tried to break it but I'm sure if there's a problem I'll find out at an appropriately bad time.

Regarding the ubuntu kernel, is this a new direction, an old direction that some of us are just now learning about (or maybe just me), or a one off for some reason?

And now for a new problem. Busybox tar is broken. surprise. /opt/.xfiletool.lst is supposed to exclude files and directories, but if the user mounts the shared folder on say /home/tc/hgfs and I add home/tc/hgfs backup fails. If I load tar.tcz and fix the hard coded paths in filetool.sh for /bin/tar to /usr/local/bin/tar, it works as expected. So, one of two solutions exists. Fix busybox tar (unlikely, as this is a known problem), or fix filetool.sh to find the right tar and use it.
Title: Re: Core v7.0beta3
Post by: curaga on January 23, 2016, 06:59:14 AM
Regarding the ubuntu kernel, is this a new direction, an old direction that some of us are just now learning about (or maybe just me), or a one off for some reason?

It's the first time, and probably one-off. 4.3 is (was) too new, and Canonical happened to declare they'd supply further stable patches for 4.2, so why not apply them?

Quote
And now for a new problem. Busybox tar is broken. surprise. /opt/.xfiletool.lst is supposed to exclude files and directories, but if the user mounts the shared folder on say /home/tc/hgfs and I add home/tc/hgfs backup fails. If I load tar.tcz and fix the hard coded paths in filetool.sh for /bin/tar to /usr/local/bin/tar, it works as expected. So, one of two solutions exists. Fix busybox tar (unlikely, as this is a known problem), or fix filetool.sh to find the right tar and use it.

Please report this to busybox.
Title: Re: Core v7.0beta3
Post by: gerald_clark on January 23, 2016, 07:05:48 AM
filetool.sh is a core component and cannot depend on an extension.
Title: Re: Core v7.0beta3
Post by: andyj on January 23, 2016, 08:08:19 AM
So because it's "core" it has to use hard paths and not be able to use a program in an extension even if one is available?
Title: Re: Core v7.0beta3
Post by: gerald_clark on January 23, 2016, 10:55:53 AM
It can't use an extension that may not be installed.
Title: Re: Core v7.0beta3
Post by: andyj on January 23, 2016, 11:42:22 AM
That still doesn't explain why the path to tar has to be hard coded. If it's just "tar" instead of "/bin/tar" and tar.tcz is not loaded, then /bin/tar will be executed. if tar.tcz is loaded, then /usr/local/bin/tar will be executed. If you're worried about a broken search path, then do something like "if [ -x /usr/local/bin/tar ] then /usr/local/bin/tar else /bin/tar fi". Would this be so bad?
Title: Re: Core v7.0beta3
Post by: gerald_clark on January 23, 2016, 11:53:24 AM
Then you have a program that behaves differently depending on what other programs have been installed.
Support and troubleshooting is hard enough without throwing in random unknown conditions.
Title: Re: Core v7.0beta3
Post by: Lee on January 24, 2016, 08:54:36 PM
OSS.tcz is in the 7.x repo but it depends on OSS-modules-KERNEL.tcz which is not present.

Lee
Title: Re: Core v7.0beta3
Post by: Juanito on January 24, 2016, 09:05:58 PM
The oss-modules-KERNEL extensions are waiting on a volunteer to compile them and submit an extension.

..so if you're feeling creative...
Title: Re: Core v7.0beta3
Post by: andyj on January 25, 2016, 07:22:46 PM
I have a dilemma, and thus a question for the maintainers. The open-vm-tools extension will not work if copied to RAM, it MUST be an extension to work. The short explanation is that the copy process breaks the symlinks that are required for it to work. I don't have any desire to rewrite the source, it's just how it is. The question is: If I were to submit a patch for tce-load to support not copying an extension to ram that otherwise would get copied if copy2fs.flg existed, would it be better to have a file such as xcopy2fs.lst for a copy to ram blacklist, or have some flag file in the extension itself that would indicate to tce-load that the extension is not to be copied to ram?
Title: Re: Core v7.0beta3
Post by: Misalf on January 25, 2016, 08:48:08 PM
Do the symlinks point to  /tmp/tcloop ? In that case it would be better to fix the extension as relying on the presence of this dir is bad practice for obvious reasons.
Title: Re: Core v7.0beta3
Post by: curaga on January 26, 2016, 01:18:46 AM
I'd just document this in the info file, if it can't be fixed in the startup script. I think such don't-copy-to-ram-even-though-I-said-so would be an antifeature, making a nasty surprise for someone.
Title: Re: Core v7.0beta3
Post by: andyj on January 26, 2016, 05:37:55 AM
If I move all the linking from the build script to the startup script, how would I know in the startup script whether or not the extension was copied in or loop mounted? Would it be as simple as looking for the loop mount point, or is there a built in way to know?
Title: Re: Core v7.0beta3
Post by: andyj on January 26, 2016, 08:52:30 AM
Another question: If I have the copy2fs.flg set all the onboot.lst extensions get copied in. If I then tce-load an extension in the local directory it gets mounted on a loop and linked in. Is this expected behavior?
Title: Re: Core v7.0beta3
Post by: Rich on January 26, 2016, 09:08:19 AM
Hi andyj
Code: [Select]
tc@box:~$ cat /usr/bin/tce-load
#!/bin/sh
# (c) Robert Shingledecker 2004-2010
# tcz concept and code from Jason Williams
#
# Example usage:
# tce-load -i /mnt/hda1/tce/optional/nano.tcz   Loads local extension
# tce-load -w -i nano.tcz                       Download into tce/optional directory, updates OnBoot and installs
# tce-load -w nano.tcz                          Download only into tce/optional directory
# Adding -c to any of the -i options will force a one time copy to file system.
# Adding -s to any of the options will suppress OK message used by appbrowser.

Have you tried using  -c
Title: Re: Core v7.0beta3
Post by: andyj on January 26, 2016, 11:10:30 AM
No I didn't try -c. I thought the copy2fs.flg was supposed to be "universal". Is it not? If not, then in what situations is it not?
Title: Re: Core v7.0beta3
Post by: gerald_clark on January 26, 2016, 11:42:13 AM
It is used when loading the entries in onboot.lst.
Title: Re: Core v7.0beta3
Post by: andyj on January 26, 2016, 12:57:51 PM
Even after the system is booted some still get copied in and some don't. Looking at tce-load it depends on $FROMWHERE. If the extension is in optional and copy2fs.flg is set in the tce dir OR the extension does not have a path and is in the pwd and copy2fs.flg is set in the pwd then it will be copied, otherwise it gets linked in (assuming no -c or copy2fs.lst). This is consistent with what I'm observing in tests. I'm assuming this is the design.
Title: Re: Core v7.0beta3
Post by: Misalf on January 26, 2016, 01:41:51 PM
If I move all the linking from the build script to the startup script, how would I know in the startup script whether or not the extension was copied in or loop mounted? Would it be as simple as looking for the loop mount point, or is there a built in way to know?
I'd claim you don't need to know. Just link or copy from  "/"  regardless of if it was copied to RAM or mounted, it's at the same location.

I always boot my USB stick using  /etc/sysconfig/tcedir/copy2fs.flg . All extensions are loaded to RAM, also afer boot and in between unmounts. Haven't seen this feature to stop working.
Title: Re: Core v7.0beta3
Post by: Misalf on January 31, 2016, 11:18:32 AM
I have just seen this feature to stop working, too.
If running  tce-load -i  from  /etc/sysconfig/tcedir/optional ,  $FROMWHERE  gets a value of "." (a dot for current directory), while the  install()  function checks for the existence of  ./copy2fs.flg  (which would translate to  /etc/sysconfig/tcedir/optional/copy2fs.flg ).

However, I don't know why but this seems to be intended.
http://forum.tinycorelinux.net/index.php/topic,13166.msg72669.html#msg72669
Title: Re: Core v7.0beta3
Post by: andyj on February 03, 2016, 08:56:18 AM
I've developed a number of extensions under this beta that I think are ready for beta testing as well. Is there extension beta testing or do I just submit them for TC 7? Specifically, I'm referring to open-vm-tools, PHP 7, Postgresql 9.5, and supporting libraries.
Title: Re: Core v7.0beta3
Post by: Juanito on February 03, 2016, 09:49:55 AM
Please go ahead and submit them for tc-7.x with a note in the info file that they are for testing.
Title: Re: Core v7.0beta3
Post by: andyj on February 03, 2016, 10:34:11 AM
In submitqc line 240 the test for version 6 needs to be updated for version 6+.
Title: Re: Core v7.0beta3
Post by: coreplayer2 on February 03, 2016, 02:19:58 PM
lately while on the road I've been investigating why wifi drivers disconnect from AP's

I'm currently using tc-7b3

I'm not 100% sure where this error originates, be it the device driver or the kernel.   May not be related to the original disconnects but I've noticed driver's have difficulty in loading it's desired firmware file is not located at /lib/firmware yet to resolve the issue an alternative method is used.

notice the direct loading error and resolution if loaded from /usr/local/lib/firmware/
Code: [Select]
tc@box:~$ dmesg | grep iwl
[   10.558184] iwlwifi 0000:06:00.0: can't disable ASPM; OS doesn't have ASPM control
[   10.562345] iwlwifi 0000:06:00.0: Direct firmware load for iwlwifi-5000-5.ucode failed with error -2
[   10.562346] iwlwifi 0000:06:00.0: Falling back to user helper
[   10.880948] iwlwifi 0000:06:00.0: loaded firmware version 8.83.5.1 build 33692 op_mode iwldvm
[   10.895468] iwlwifi 0000:06:00.0: CONFIG_IWLWIFI_DEBUG disabled
[   10.895471] iwlwifi 0000:06:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
[   10.895472] iwlwifi 0000:06:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled
[   10.895474] iwlwifi 0000:06:00.0: Detected Intel(R) Ultimate N WiFi Link 5300 AGN, REV=0x24
[   10.895645] iwlwifi 0000:06:00.0: L1 Disabled - LTR Disabled
[   10.917819] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
[   29.587946] iwlwifi 0000:06:00.0: L1 Disabled - LTR Disabled
[   29.591677] iwlwifi 0000:06:00.0: Radio type=0x0-0x2-0x0
[   29.727804] iwlwifi 0000:06:00.0: L1 Disabled - LTR Disabled
[   29.730796] iwlwifi 0000:06:00.0: Radio type=0x0-0x2-0x0
tc@box:~$

however if I re-create the extension where firmware is installed to /usr/lib/firmware, then firmware is directly loaded successfully
Code: [Select]
tc@box:~$ dmesg | grep iwl
[   10.465335] iwlwifi 0000:06:00.0: can't disable ASPM; OS doesn't have ASPM control
[   10.480928] iwlwifi 0000:06:00.0: loaded firmware version 8.83.5.1 build 33692 op_mode iwldvm
[   10.492672] iwlwifi 0000:06:00.0: CONFIG_IWLWIFI_DEBUG disabled
[   10.492674] iwlwifi 0000:06:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
[   10.492675] iwlwifi 0000:06:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled
[   10.492677] iwlwifi 0000:06:00.0: Detected Intel(R) Ultimate N WiFi Link 5300 AGN, REV=0x24
[   10.492723] iwlwifi 0000:06:00.0: L1 Disabled - LTR Disabled
[   10.515657] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
[   35.947811] iwlwifi 0000:06:00.0: L1 Disabled - LTR Disabled
[   35.951477] iwlwifi 0000:06:00.0: Radio type=0x0-0x2-0x0
[   36.084178] iwlwifi 0000:06:00.0: L1 Disabled - LTR Disabled
[   36.087153] iwlwifi 0000:06:00.0: Radio type=0x0-0x2-0x0
tc@box:~$

Is this of any concern to us? or has the effectiveness of the driver changed because of this?
Title: Re: Core v7.0beta3
Post by: dentonlt on February 03, 2016, 11:35:44 PM
Maybe this is off-topic, but it seems relevant enough.

I do a kernel rebuild to drop modules I don't need and put the ones I need into the kernel. That's not a problem.

If I build the 4.2.9 kernel on TC 6.4/x86_64, I get a 5mb bzImage.

The same build/config/scripts on TC 7.0beta3/x86_64 gives me an 8.5mb bzImage.

I wouldn't normally care ... but that's 60% change. Same build config, same scripts. Should a different gcc make that big a difference?



Sent from my HTC_0P6B6 using Tapatalk
Title: Re: Core v7.0beta3
Post by: Juanito on February 03, 2016, 11:52:52 PM
Which version of gcc?

Did you gzip/advdef the kernel modules?
Title: Re: Core v7.0beta3
Post by: Juanito on February 04, 2016, 12:16:34 AM
How about:
Code: [Select]
if [ "$(version | sed 's/\..*//')" -gt "5" ]; then?

Edit: updated extension posted.
Title: Re: Core v7.0beta3
Post by: Juanito on February 04, 2016, 12:47:34 AM
notice the direct loading error and resolution if loaded from /usr/local/lib/firmware/

I'd assumed that message occurred when the kernel driver did not contain the firmware (a la broadcom wl), but no, I don't think it's a problem.
Title: Re: Core v7.0beta3
Post by: curaga on February 04, 2016, 02:26:54 AM
@coreplayer2

Usually if the firmware is not available the first time, the driver will print a message and exit. Then if the firmware is loaded later, the driver will try to load again, and this time succeed, like in your dmesg. So in practice, the message is the only difference.

@dentonlt

Clearly a bug/suboptimal behavior somewhere, most likely in gcc. Though the official build didn't grow at all, the added 100kb or so came from new options.

If you want to, you could go trying different gcc versions, and if it still happens in the latest 5 series or 6 git, report to them and isolate what caused it.
Title: Re: Core v7.0beta3
Post by: andyj on February 04, 2016, 06:58:24 AM
I used -ge "6", but -gt "5" works too.  :D

While we're on the subject of beta testing, I would like to make a proposal: In theory the extensions are supposed to have a copy of the license available. Technically this doesn't mean that it needs to be _IN_ the "some-xyx-extension.tcz" file, but that it be available _WITH_ the file. In my cursory scan of many of the extensions available I noticed that the license files are lacking. Rather than repackage them to be in compliance, I propose that we create a new file with a name such as "some-xyz-extension.tcz.lic" to compliment the existing files which would have the text of the license in it. Because the license file names can vary based on the type of license itself, this would standardize that. I say beta test because this suggests that a new "License" tab be added to the app browser and that the license be downloaded with the extension, so there would need to be a few strategic code updates. Thoughts?
Title: Re: Core v7.0beta3
Post by: Juanito on February 04, 2016, 08:18:08 AM
Note that the license for all of the extensions will be in the source tarball in the repo src folders - apart from licenses which expressly state that they should be in the extension itself, they are already available.
Title: Re: Core v7.0beta3
Post by: curaga on February 04, 2016, 01:24:20 PM
I don't think we need to store 4000 copies of the GPL.
Title: Re: Core v7.0beta3
Post by: dentonlt on February 05, 2016, 01:14:30 AM


Note that the license for all of the extensions will be in the source tarball in the repo src folders ...

Good point. Another off-topic: I'll adapt submitqc to remind maitainers re this pathway for submitting [reasonably-sized] sources.

Sent from my HTC_0P6B6 using Tapatalk