Tiny Core Linux
Tiny Core Base => TCB News => Release Candidate Testing => Topic started 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.
-
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.
-
We could add the rule to base too, but changing fuse.tcz is easier.
-
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.
-
Do you operate on fuse in the startup script, or is it only done when the user asks for it?
-
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.
-
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.
-
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?
-
Hi andyj
See:
http://forum.tinycorelinux.net/index.php/topic,19505.msg120528.html#msg120528
-
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
-
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.
-
@curaga/andyj - if you could confirm the rules change required to the fuse extension, I'll make the changes.
-
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.
-
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.
-
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.
-
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?
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.
-
filetool.sh is a core component and cannot depend on an extension.
-
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?
-
It can't use an extension that may not be installed.
-
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?
-
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.
-
OSS.tcz is in the 7.x repo but it depends on OSS-modules-KERNEL.tcz which is not present.
Lee
-
The oss-modules-KERNEL extensions are waiting on a volunteer to compile them and submit an extension.
..so if you're feeling creative...
-
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?
-
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.
-
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.
-
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?
-
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?
-
Hi andyj
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
-
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?
-
It is used when loading the entries in onboot.lst.
-
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.
-
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.
-
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
-
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.
-
Please go ahead and submit them for tc-7.x with a note in the info file that they are for testing.
-
In submitqc line 240 the test for version 6 needs to be updated for version 6+.
-
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/
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
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?
-
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
-
Which version of gcc?
Did you gzip/advdef the kernel modules?
-
How about:
if [ "$(version | sed 's/\..*//')" -gt "5" ]; then?
Edit: updated extension posted.
-
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.
-
@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.
-
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?
-
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.
-
I don't think we need to store 4000 copies of the GPL.
-
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