Tiny Core Linux
Tiny Core Base => TCB News => Release Candidate Testing => Topic started by: Juanito on January 19, 2016, 10:43:19 PM
-
Team Tiny Core is pleased to announce that Tiny Core 7.0 Beta2 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 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.
-
reposted CorePlus iso with corrected ndiswrapper, wireless and wl modules
-
Not sure if it is right thread to report -- gcc refuses to compile any c programs.
$ gcc -v -save-temps hello.c
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/5.2.0/lto-wrapper
Target: i486-pc-linux-gnu
Configured with: ../gcc-5.2.0/configure --prefix=/usr/local --enable-languages=c,c++ --disable-multilib --disable-bootstrap --with-system-zlib --libexecdir=/usr/local/lib --enable-frame-pointer --enable-gold
Thread model: posix
gcc version 5.2.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=i486' '-march=i486'
/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/5.2.0/cc1 -E -quiet -v -iprefix /tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/5.2.0/ hello.c -mtune=i486 -march=i486 -fpch-preprocess -o hello.i
cc1: internal compiler error: Illegal instruction
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 6
model name : Mobile Pentium II
stepping : 10
microcode : 0xa
cpu MHz : 399.934
cache size : 256 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pse36 mmx fxsr
bugs :
bogomips : 800.19
clflush size : 32
cache_alignment : 32
address sizes : 36 bits physical, 32 bits virtual
power management:
$ free -m
total used free shared buffers cached
Mem: 246 101 145 40 4 71
-/+ buffers/cache: 24 222
Swap: 0 0 0
$ cat /opt/tcemirror
http://repo.tinycorelinux.net/
$ ls
hello.c
$ cat hello.c
main(){}
No preprocessed code is generated, dmesg contains nothing unusual, locale is "C".
Pentium I/256M system w/ Core 7.0beta1 fails too.
P.S. rt61pci support is now ok, thanks.
-
'seems to work for me:
$ gcc -flto -fuse-linker-plugin -mtune=generic -Os -pipe hello.c
hello.c:1:1: warning: return type defaults to 'int' [-Wimplicit-int]
main(){}
^
..and I just compiled busybox with it.
Did you load compiletc or just gcc?
-
Always nasty when gcc uses over-486 instructions when told to use 486 ones. I wonder which it was, just out of curiosity.
Can you try that in gdb? gdb --args gcc hello.c
run
disas
-
i'm unable to reproduce:
$ gcc -v -save-temps hello.c
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/5.2.0/lto-wrapper
Target: i486-pc-linux-gnu
Configured with: ../gcc-5.2.0/configure --prefix=/usr/local --enable-languages=c,c++ --disable-multilib --disable-bootstrap --with-system-zlib --libexecdir=/usr/local/lib --enable-frame-pointer --enable-gold
Thread model: posix
gcc version 5.2.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=i486' '-march=i486'
/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/5.2.0/cc1 -E -quiet -v -iprefix /tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/5.2.0/ hello.c -mtune=i486 -march=i486 -fpch-preprocess -o hello.i
ignoring nonexistent directory "/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/5.2.0/../../../../i486-pc-linux-gnu/include"
ignoring duplicate directory "/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/../../lib/gcc/i486-pc-linux-gnu/5.2.0/include"
ignoring duplicate directory "/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/../../lib/gcc/i486-pc-linux-gnu/5.2.0/include-fixed"
ignoring nonexistent directory "/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/../../lib/gcc/i486-pc-linux-gnu/5.2.0/../../../../i486-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/5.2.0/include
/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/5.2.0/include-fixed
/usr/local/include
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=i486' '-march=i486'
/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/5.2.0/cc1 -fpreprocessed hello.i -quiet -dumpbase hello.c -mtune=i486 -march=i486 -auxbase hello -version -o hello.s
GNU C11 (GCC) version 5.2.0 (i486-pc-linux-gnu)
compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version 3.1.3-p4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (GCC) version 5.2.0 (i486-pc-linux-gnu)
compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version 3.1.3-p4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 393e434426a3ade6d8fe652a70a6aa66
hello.c:1:1: warning: return type defaults to 'int' [-Wimplicit-int]
main(){}
^
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=i486' '-march=i486'
as -v --32 -o hello.o hello.s
GNU assembler version 2.25.1 (i486-pc-linux-gnu) using BFD version (GNU Binutils) 2.25.1
COMPILER_PATH=/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/5.2.0/:/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/
LIBRARY_PATH=/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/5.2.0/:/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/:/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/5.2.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=i486' '-march=i486'
/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/5.2.0/collect2 -plugin /tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/5.2.0/liblto_plugin.so -plugin-opt=/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/5.2.0/lto-wrapper -plugin-opt=-fresolution=hello.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/5.2.0/crtbegin.o -L/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/5.2.0 -L/tmp/tcloop/gcc/usr/local/bin/../lib/gcc -L/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/5.2.0/../../.. hello.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/5.2.0/crtend.o /usr/lib/crtn.o
..though this isn't an actual i486...
-
You're on too new a cpu ;)
-
Good, b43 module working again.
wl-modules-4.2.9-tinycore is missing on repo.
-
The cursor works with Xvesa and VMware now so thanks. Autograb doesn't work but it didn't in TC 6 either and if it's important then open-vm-tools will need to be loaded. I can submit it once the following issue is resolved.
I have determined that the problem with /dev/fuse is that the permissions change when glib2.tcz is loaded. To reproduce, start with TC installed but no extensions loaded. Check /dev/fuse permissions, they should be 1666. Load dependencies libffi.tcz and gamin.tcz and check /dev/fuse. Should be no change. Load glib2.tce and check permissions. They are now 1600. I ran strace, it looks like some devices are being worked on but I can't tell for sure what's happening. I found some suspicious activity where "sudo /sbin/udevadm trigger" is doing this:
open("/sys/devices/virtual/misc/fuse/uevent", O_WRONLY|O_LARGEFILE) = 3
write(3, "change", 6) = 6
close(3) = 0
Maybe something is changing it back later when all the other extensions get loaded for open-vm-tools, but there over 90 more to load. Testing that will take a while.
Two other comments about the installed beta:
1. Both fltk-1.1.10 and fltk-1.3 extentions are loaded. Are they both necessary?
2. If another window manager like openbox is booted, then both it and flwm_topside extensions are loaded. Shouldn't flwm_topside not be in onboot.lst? Or is this a feature?
-
wl-modules-4.2.9* looks to be there to me?
-
Two other comments about the installed beta:
1. Both fltk-1.1.10 and fltk-1.3 extentions are loaded. Are they both necessary?
2. If another window manager like openbox is booted, then both it and flwm_topside extensions are loaded. Shouldn't flwm_topside not be in onboot.lst? Or is this a feature?
I'm guessing that you're using CorePlus?
As I recall, all of the extensions are loaded onboot - booting another window manager is a managed by changing the "desktop=" boot code in the syslinux menu.
If you're going to use tinycore for any length of time, I'd recommend a usb stick or hd install where you can customise things to load exactly what you need and nothing more.
I'd guess (without checking) that one of the window managers uses fltk-1.1.10, but you can easily check.
-
Always nasty when gcc uses over-486 instructions when told to use 486 ones. I wonder which it was, just out of curiosity.
Can you try that in gdb? gdb --args gcc hello.c
run
disas
Pentium I system faults even running gcc, not cc1 ;)
No symbols so disas w/ 2 arg:
Starting program: /usr/local/bin/gcc hello.c
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
Program received signal SIGILL, Illegal instruction.
0x0805fe3a in ?? ()
Dump of assembler code from 0x805fe3a to 0x805fe50:
=> 0x0805fe3a: 0f 44 da cmove %edx,%ebx
0x0805fe3d: 85 c0 test %eax,%eax
0x0805fe3f: 75 0b jne 0x805fe4c
0x0805fe41: 83 ec 0c sub $0xc,%esp
0x0805fe44: 53 push %ebx
0x0805fe45: e8 36 9c fe ff call 0x8049a80 <malloc@plt>
0x0805fe4a: eb 09 jmp 0x805fe55
0x0805fe4c: 52 push %edx
0x0805fe4d: 52 push %edx
0x0805fe4e: 53 push %ebx
0x0805fe4f: 50 push %eax
End of assembler dump.
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 5
model : 2
model name : Pentium 75 - 200
stepping : 12
cpu MHz : 167.059
cache size : 0 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug : no
f00f_bug : yes
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr mce cx8
bugs : f00f
bogomips : 334.03
clflush size : 32
cache_alignment : 32
address sizes : 32 bits physical, 32 bits virtual
power management:
$ uname -a
Linux box 4.2.9-tinycore #1999 SMP Mon Jan 18 19:42:12 UTC 2016 i586 GNU/Linux
...
Did you load compiletc or just gcc?
tce-load -i compiletc
-
My "two other comments" were about a HD installation. There isn't a dependency for fltk-1.1.10 in any of the .dep files in optional, but it is in tc-install.sh so I'm suggesting that script needs to be updated. As you say, if someone wants to use a different window manager shouldn't that be the only one loaded?
-
wl-modules-4.2.9* looks to be there to me?
Search does not find them. It seems to be an indexing problem.
-
@vt1431
Oh ok, lots of cmov. The build steps are all correct, so it might be a bug in upstream gcc. We may not be able to do anything, is it possible for you to build on a newer machine and just copy to the 586?
-
Sorry - I'm confused. 4.2.8 is on kernel.org, but to bump to 4.2.9 I pick up patches from ... ?
I'm on an Acer c720, so I'm missing modules for Chromebook touchpad (Cyapa) - happy to roll those myself and all.
-
Hi dentonlt
If you are looking for patched sources they are here:
http://repo.tinycorelinux.net/7.x/x86/release/src/kernel/
-
Hi dentonlt
If you are looking for patched sources they are here:
http://repo.tinycorelinux.net/7.x/x86/release/src/kernel/
Thanks, Rich.
-
...
We may not be able to do anything, is it possible for you to build on a newer machine and just copy to the 586?
Running 5.2.0 "gcc -v ..." shows no "--with-arch=i486 --with-tune=i686" which was present in 4.9.1:
Target: i486-pc-linux-gnu
Configured with: ../gcc-5.2.0/configure --prefix=/usr/local --enable-languages=c,c++ --disable-multilib
--disable-bootstrap --with-system-zlib --libexecdir=/usr/local/lib --enable-frame-pointer --enable-gold
vs
Target: i486-pc-linux-gnu
Configured with: ../gcc-4.9.1/configure --prefix=/usr/local --enable-shared --libexecdir=/usr/local/lib
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++
--disable-multilib --disable-bootstrap --with-system-zlib --enable-frame-pointer --enable-lto
--with-mpfr=/usr/local --with-gmp=/usr/local --with-cloog=/usr/local --with-isl=/usr/local
--with-arch=i486 --with-tune=i686
What drawbacks would be possible from using gcc4.9.1-compiled kernel modules with 4.x kernel?
-
Placing any .gz in /etc/sysconfig/tcedir/optional prints a "/" on boot. This is caused by function process_gz' "cd -" in /usr/bin/tce-setup.
*** /usr/bin/tce-setup 2015-11-04 16:42:49.000000000 +0300
--- /home/tc/a/tce-setup 2016-01-20 23:41:08.477947898 +0300
***************
*** 74,80 ****
STARTSCRIPT="$TCEINSTALLED"/"${GZ%.gz}"
[ -s "$STARTSCRIPT" ] && sh "$STARTSCRIPT"
done
! cd -
setupHome
}
--- 74,80 ----
STARTSCRIPT="$TCEINSTALLED"/"${GZ%.gz}"
[ -s "$STARTSCRIPT" ] && sh "$STARTSCRIPT"
done
! cd - > /dev/null
setupHome
}
-
Sorry - I'm confused. 4.2.8 is on kernel.org, but to bump to 4.2.9 I pick up patches from ... ?
It was released by Canonical, they have 4.2 as a long-term kernel in an Ubuntu version. Official name is 4.2.8-ckt1. Then we have some of our own patches.
Running 5.2.0 "gcc -v ..." shows no "--with-arch=i486 --with-tune=i686" which was present in 4.9.1:
It should work with just a 486 target though, which is correct on both.
edit: From your earlier "gcc -v" output, we see that gcc applied -march=i486. This is what the --with-arch option would do, it sets the default -march, it doesn't affect the new gcc's build process.
What drawbacks would be possible from using gcc4.9.1-compiled kernel modules with 4.x kernel?
It won't work if you mix compilers. The kernel and modules must be compiled by the same gcc version. If you build it all, the gcc version doesn't matter much, as the kernel supports every gcc version from 3.4 up, IIRC.
Applied your patch, thanks.
-
Search does not find them. It seems to be an indexing problem.
'seems to be OK now?
-
My "two other comments" were about a HD installation. There isn't a dependency for fltk-1.1.10 in any of the .dep files in optional, but it is in tc-install.sh so I'm suggesting that script needs to be updated. As you say, if someone wants to use a different window manager shouldn't that be the only one loaded?
tc-install.sh corrected fltk-1.1.10 -> fltk-1.3 - thanks
ezremaster still depends on fltk-1.1.10, which is why I guess it is still there in the CorePlus iso
I agree, that if you choose a different wm, then it should be the only one loaded - patches to tc-install.sh would be gratefully received :)
Of course you can edit onboot.lst to suit once tc-install exits.
-
Search does not find them. It seems to be an indexing problem.
'seems to be OK now?
Yes. Thanks.
-
Further testing reveals that loading libXdamage or libXxf86vm will also change the permissions on /dev/fuse to 1600, and that loading i2c-KERNEL or libX11-dev will reset them to 1666. At this point I'm going to need a pretty good reason not to just set them to 1666 in the open-vm-tools load script just to be sure, since there doesn't appear to be much control over the fuse situation at this point.
-
Why not set them in bootsync.sh until the issue is resolved.
-
I could. But I think the ideal extension is one that you can load and it will work without a whole lot of having to fix stuff afterwards if you know it needs to be fixed and can take care of it when it loads. The previous version of open-vm-tools used a kernel driver so the permissions on /dev/fuse weren't an issue. Now, since it's in userspace the permissions matter, and because they matter, why not make sure that they are what they need to be and not hope they are. I think doing as part of the extension initialization is preferable to having to document "to use this extension add 'chmod 1666 /dev/fuse' to /opt/bootsync.sh' until further notice". I know it's a kludge and I don't like it either, but I like not taking care of it when I know it needs to be done and leaving it for someone else even less.
-
I think the double window manager extension being loaded fix is simple, if I'm reading tc-install.sh right. On line 38 the current $DESKTOP is added to onboot.lst, so that part should stay. On line 768 flwm_topside.tcz is hard coded in the list of extensions to load and I think that should be deleted. If flwm_topside is the desktop it will get added in 38. This also explains why I was seeing it twice in onboot.lst.
-
tc-install updated - thanks :)
-
Further testing reveals that loading libXdamage or libXxf86vm will also change the permissions on /dev/fuse to 1600, and that loading i2c-KERNEL or libX11-dev will reset them to 1666.
Did you try "udevadm monitor" to try to see why the changes happen?
I tried with libX11-dev (and i2c-KERNEL), but the permissions were not reset to 1666.
terminal 1:$ sudo chmod 1600 /dev/fuse
$ ls -l /dev/fuse
crw------T 1 root root 10, 229 Jan 22 08:50 /dev/fuse
$ tce-load -i libX11-dev
libXdmcp-dev.tcz: OK
libxcb-dev.tcz: OK
libX11-dev.tcz: OK
$ ls -l /dev/fuse
crw------T 1 root root 10, 229 Jan 22 08:50 /dev/fuse
terminal 2:$ udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent
KERNEL[1115.966588] add /devices/virtual/bdi/7:73 (bdi)
KERNEL[1115.966627] add /devices/virtual/block/loop73 (block)
UDEV [1115.966822] add /devices/virtual/bdi/7:73 (bdi)
KERNEL[1115.966868] change /devices/virtual/block/loop73 (block)
UDEV [1115.967011] add /devices/virtual/block/loop73 (block)
UDEV [1115.967329] change /devices/virtual/block/loop73 (block)
KERNEL[1116.017148] add /devices/virtual/bdi/7:74 (bdi)
KERNEL[1116.017185] add /devices/virtual/block/loop74 (block)
UDEV [1116.017326] add /devices/virtual/bdi/7:74 (bdi)
KERNEL[1116.017382] change /devices/virtual/block/loop74 (block)
UDEV [1116.017490] add /devices/virtual/block/loop74 (block)
UDEV [1116.017702] change /devices/virtual/block/loop74 (block)
KERNEL[1116.063067] add /devices/virtual/bdi/7:75 (bdi)
KERNEL[1116.063092] add /devices/virtual/block/loop75 (block)
KERNEL[1116.063166] change /devices/virtual/block/loop75 (block)
UDEV [1116.063247] add /devices/virtual/bdi/7:75 (bdi)
UDEV [1116.063386] add /devices/virtual/block/loop75 (block)
UDEV [1116.063600] change /devices/virtual/block/loop75 (block)
-
Hmm - I tried the test in the opposite sense and do see a change.
terminal 1: $ ls -l /dev/fuse
crw-rw-rwT 1 root root 10, 229 Jan 22 09:16 /dev/fuse
$ tce-load -i glib2
libffi.tcz: OK
gamin.tcz: OK
glib2.tcz: OK
$ ls -l /dev/fuse
crw------T 1 root root 10, 229 Jan 22 09:18 /dev/fuse
terminal 2: $ udevadm monitor
...
KERNEL[99.456371] change /devices/virtual/misc/fuse (misc)
UDEV [99.530269] change /devices/virtual/misc/fuse (misc)
I wonder if loading glib2 adds functionality to udev not present at boot time when the permissions of /dev/fuse are set.
@Curaga?
-
I guess the change action misses the default rule. The rule in fuse.tcz has no action specified, so with fuse.tcz loaded a change shouldn't affect perms.
It currently does, because the startup script in fuse.tcz does not tell udev to reload rules. Adding that, /dev/fuse stays 666.