WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Core v7.0beta2  (Read 4371 times)

Offline dentonlt

  • Sr. Member
  • ****
  • Posts: 307
    • the trombone analog
Re: Core v7.0beta2
« Reply #15 on: January 20, 2016, 05:43:02 PM »
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.

Online Rich

  • TinyCore Moderator
  • Hero Member
  • *****
  • Posts: 5391
Re: Core v7.0beta2
« Reply #16 on: January 20, 2016, 05:50:10 PM »
Hi dentonlt
If you are looking for patched sources they are here:
http://repo.tinycorelinux.net/7.x/x86/release/src/kernel/

Offline dentonlt

  • Sr. Member
  • ****
  • Posts: 307
    • the trombone analog
Re: Core v7.0beta2
« Reply #17 on: January 20, 2016, 06:13:09 PM »
Hi dentonlt
If you are looking for patched sources they are here:
http://repo.tinycorelinux.net/7.x/x86/release/src/kernel/
Thanks, Rich.

Offline vt1431

  • WikiUser
  • *
  • Posts: 5
Re: Core v7.0beta2
« Reply #18 on: January 21, 2016, 12:42:18 AM »
...
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:
Code: [Select]
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
Code: [Select]
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?

Offline vt1431

  • WikiUser
  • *
  • Posts: 5
Re: Core v7.0beta2
« Reply #19 on: January 21, 2016, 12:49:28 AM »
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.
Code: [Select]
*** /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
  }
 

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 9564
Re: Core v7.0beta2
« Reply #20 on: January 21, 2016, 01:40:03 AM »
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.

Quote
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.
« Last Edit: January 21, 2016, 01:42:39 AM by curaga »
The only barriers that can stop you are the ones you create yourself.

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 9465
Re: Core v7.0beta2
« Reply #21 on: January 21, 2016, 02:46:49 AM »
Search does not find them.  It seems to be an indexing problem.

'seems to be OK now?

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 9465
Re: Core v7.0beta2
« Reply #22 on: January 21, 2016, 03:54:58 AM »
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.

Offline gerald_clark

  • TinyCore Moderator
  • Hero Member
  • *****
  • Posts: 4243
Re: Core v7.0beta2
« Reply #23 on: January 21, 2016, 06:06:21 AM »
Search does not find them.  It seems to be an indexing problem.

'seems to be OK now?
Yes. Thanks.

Offline andyj

  • Sr. Member
  • ****
  • Posts: 462
Re: Core v7.0beta2
« Reply #24 on: January 21, 2016, 08:17:32 AM »
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.

Offline gerald_clark

  • TinyCore Moderator
  • Hero Member
  • *****
  • Posts: 4243
Re: Core v7.0beta2
« Reply #25 on: January 21, 2016, 08:28:32 AM »
Why not set them in bootsync.sh until the issue is resolved.

Offline andyj

  • Sr. Member
  • ****
  • Posts: 462
Re: Core v7.0beta2
« Reply #26 on: January 21, 2016, 09:02:02 AM »
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.

Offline andyj

  • Sr. Member
  • ****
  • Posts: 462
Re: Core v7.0beta2
« Reply #27 on: January 21, 2016, 09:31:29 AM »
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.

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 9465
Re: Core v7.0beta2
« Reply #28 on: January 21, 2016, 08:59:10 PM »
tc-install updated - thanks  :)

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 9465
Re: Core v7.0beta2
« Reply #29 on: January 21, 2016, 09:01:29 PM »
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:
Code: [Select]
$ 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:
Code: [Select]
$ 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)
« Last Edit: January 21, 2016, 09:15:27 PM by Juanito »