Core v7.0beta3

[Juanito]

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.

[andyj]

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.

[curaga]

We could add the rule to base too, but changing fuse.tcz is easier.

[andyj]

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.

[curaga]

Do you operate on fuse in the startup script, or is it only done when the user asks for it?

[andyj]

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.

[curaga]

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.

[andyj]

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?

[Rich]

Hi andyj
See:
http://forum.tinycorelinux.net/index.php/topic,19505.msg120528.html#msg120528

[andyj]

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.

[Rich]

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.

[Juanito]

@curaga/andyj - if you could confirm the rules change required to the fuse extension, I'll make the changes.

[curaga]

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.

[curaga]

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.

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.

[andyj]

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.