tinycore_v3.8rc2

[roberts]

Would need more specific information that could be reproduced. If not a local extension permission problem then possibly a low(er) memory system resulting in running out of inodes.

[bmarkus]

/tce directory is stored on HDD's /sda1 partition ext4 formatted. System is booting from USB stick. There is 2GB RAM, an Intel Core2 dual core CPU. No tricks, it's an ordinary rc2, no extension loaded to RAM. From one boot to another same happenes, it is not random. First loaded extensions work as expected, failing ones are at the end of onboot list. There are not too many extensions, thes setup is used to compile simple extensions. If you need I can provide the onboot list. It happened with intltool.tcz first but it's not significant I'm sure. Changing onboot to ondemand it works fine.

[gerald_clark]

Sounds to me like a depfile error.
Programs may run or not run depending on the order they are loaded.


I would identify the first that fails, remove it and all that follow from onboot.lst.
Then reboot and tce-load -i each in turn and look for errors.

[roberts]

A depfile error should be found by using appsaudit. Order should not be a factor as dependencies are loaded prior to any parent extension.

There was a known issue with coreutils "overlaying" via path some busybox commands that are used to load the system. That issue was addressed in rc2

* Updated tce-setup & tce-load to ensure busybox calls thus avoiding conflicts with gnu utilities.

Sharing your onboot.lst would be helpful.

[gerald_clark]

AppsAudit will only find a missing dependency listed in a dep file, not one that is missing from a  dep file.

I have found several dep files that were in error this way.

[roberts]

True, but that should be caught by the extension maker. The very basis of initial testing and would indicate a rouge extension and not a bug in the base.

[bmarkus]

A depfile error should be found by using appsaudit. Order should not be a factor as dependencies are loaded prior to any parent extension.

There was a known issue with coreutils "overlaying" via path some busybox commands that are used to load the system. That issue was addressed in rc2

* Updated tce-setup & tce-load to ensure busybox calls thus avoiding conflicts with gnu utilities.

Sharing your onboot.lst would be helpful.

The problem is coreutils. Extensions loaded after coreutils are not symlinked. Removing coreutils from onboot list everything is OK.

It is rc2

[roberts]

Thanks for reporting. Will look into it further.

[roberts]

Found, Fixed, and Verified.

[quanpin]

v3.8rc1 and rc2 not support the max .tcz loop > /dev/loop87 ,  like gnome-desktop-base.tcz, it will echo" mount: could not find any free loop device.  "
but it can  run  in tc3.6 and 3.7.1 

[curaga]

@quanpin

Hm, util-linux breakage as well? Would your loop86 be util-linux-ng by any chance?

[quanpin]

it will run as like base, and up to mount /dev/loop87 ,can't mount  loop any more.

[curaga]

Yes, but what is your loop86 (/87)?

[quanpin]

/dev/loop82 on /tmp/tcloop/krb5 type squashfs (ro,relatime)
/dev/loop83 on /tmp/tcloop/cracklib type squashfs (ro,relatime)
/dev/loop84 on /tmp/tcloop/Linux-PAM type squashfs (ro,relatime)
/dev/loop85 on /tmp/tcloop/polkit type squashfs (ro,relatime)
/dev/loop86 on /tmp/tcloop/polkit-gnome type squashfs (ro,relatime)
/dev/loop87 on /tmp/tcloop/util-linux-ng type squashfs (ro,relatime)


/dev/loop82               1.1M      1.1M         0 100% /tmp/tcloop/krb5
/dev/loop83             160.0K    160.0K         0 100% /tmp/tcloop/cracklib
/dev/loop84             288.0K    288.0K         0 100% /tmp/tcloop/Linux-PAM
/dev/loop85             128.0K    128.0K         0 100% /tmp/tcloop/polkit
/dev/loop86              28.0K     28.0K         0 100% /tmp/tcloop/polkit-gnome
/dev/loop87             532.0K    532.0K         0 100% /tmp/tcloop/util-linux-ng

[roberts]

Similar to bmarkus coreutils issue. It should be resolved with next rc, 3.8rc3.  I wlll post it soon.