Tiny Core Base > Release Candidate Testing
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?
Navigation
[0] Message Index
[#] Next page
Go to full version