Core v7.0beta3

[curaga]

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?

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.

[gerald_clark]

filetool.sh is a core component and cannot depend on an extension.

[andyj]

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?

[gerald_clark]

It can't use an extension that may not be installed.

[andyj]

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?

[gerald_clark]

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.

[Lee]

OSS.tcz is in the 7.x repo but it depends on OSS-modules-KERNEL.tcz which is not present.

Lee

[Juanito]

The oss-modules-KERNEL extensions are waiting on a volunteer to compile them and submit an extension.

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

[andyj]

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?

[Misalf]

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.

[curaga]

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.

[andyj]

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?

[andyj]

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?

[Rich]

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

[andyj]

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?