WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Core v7.0beta3  (Read 6191 times)

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 9611
Re: Core v7.0beta3
« Reply #15 on: January 23, 2016, 06:59:14 AM »
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?

Quote
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.
The only barriers that can stop you are the ones you create yourself.

Offline gerald_clark

  • TinyCore Moderator
  • Hero Member
  • *****
  • Posts: 4249
Re: Core v7.0beta3
« Reply #16 on: January 23, 2016, 07:05:48 AM »
filetool.sh is a core component and cannot depend on an extension.

Offline andyj

  • Sr. Member
  • ****
  • Posts: 484
Re: Core v7.0beta3
« Reply #17 on: January 23, 2016, 08:08:19 AM »
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?

Offline gerald_clark

  • TinyCore Moderator
  • Hero Member
  • *****
  • Posts: 4249
Re: Core v7.0beta3
« Reply #18 on: January 23, 2016, 10:55:53 AM »
It can't use an extension that may not be installed.

Offline andyj

  • Sr. Member
  • ****
  • Posts: 484
Re: Core v7.0beta3
« Reply #19 on: January 23, 2016, 11:42:22 AM »
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?

Offline gerald_clark

  • TinyCore Moderator
  • Hero Member
  • *****
  • Posts: 4249
Re: Core v7.0beta3
« Reply #20 on: January 23, 2016, 11:53:24 AM »
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.

Offline Lee

  • Hero Member
  • *****
  • Posts: 638
    • My Core wiki user page
Re: Core v7.0beta3
« Reply #21 on: January 24, 2016, 08:54:36 PM »
OSS.tcz is in the 7.x repo but it depends on OSS-modules-KERNEL.tcz which is not present.

Lee
32 bit core4.7.7, Xprogs, Xorg-7.6, wbar, jwm  |  - Testing -
PPR, data persistence through filetool.sh          |  32 bit core 8.0 alpha 1
USB Flash drive, one partition, ext2, grub4dos  | Otherwise similar

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 9606
Re: Core v7.0beta3
« Reply #22 on: January 24, 2016, 09:05:58 PM »
The oss-modules-KERNEL extensions are waiting on a volunteer to compile them and submit an extension.

..so if you're feeling creative...

Offline andyj

  • Sr. Member
  • ****
  • Posts: 484
Re: Core v7.0beta3
« Reply #23 on: January 25, 2016, 07:22:46 PM »
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?

Offline Misalf

  • Hero Member
  • *****
  • Posts: 1587
Re: Core v7.0beta3
« Reply #24 on: January 25, 2016, 08:48:08 PM »
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.
Download a copy and keep it handy: Core book ;)

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 9611
Re: Core v7.0beta3
« Reply #25 on: January 26, 2016, 01:18:46 AM »
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.
The only barriers that can stop you are the ones you create yourself.

Offline andyj

  • Sr. Member
  • ****
  • Posts: 484
Re: Core v7.0beta3
« Reply #26 on: January 26, 2016, 05:37:55 AM »
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?

Offline andyj

  • Sr. Member
  • ****
  • Posts: 484
Re: Core v7.0beta3
« Reply #27 on: January 26, 2016, 08:52:30 AM »
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?

Online Rich

  • TinyCore Moderator
  • Hero Member
  • *****
  • Posts: 5470
Re: Core v7.0beta3
« Reply #28 on: January 26, 2016, 09:08:19 AM »
Hi andyj
Code: [Select]
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

Offline andyj

  • Sr. Member
  • ****
  • Posts: 484
Re: Core v7.0beta3
« Reply #29 on: January 26, 2016, 11:10:30 AM »
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?