dCore not usable on non linux filesystem when using the import command

[jls]

 

[Jason W]

Since the file system is used to create the sce package from unpacked files from the .debs, it has to be a linux compatible file system to preserve file attributes.

[theYinYeti]

Since the file system is used to create the sce package from unpacked files from the .debs, it has to be a linux compatible file system to preserve file attributes.

This is precisely the information that I was missing when I was having problems in testing dCore! It should be recorded somewhere; that's important information.

[vinnie]

but the usb-stick that hosts the files of the distribution can be fat32?

[Jason W]

tce directory should be the only one requiring linux compatible filesystem.  Boot files, dCore.gz and vmlinuz should be able to be on the same kinds of partitions as standard core.

[tinypoodle]

In fact, all that matters wrt boot files is that the bootloader can access them, e.g. with pxelinux it would depend on server being capable to access boot files, or in case of lilo which is file system agnostic, filesystem may be irrelevant.

[vinnie]

tce directory should be the only one requiring linux compatible filesystem.  Boot files, dCore.gz and vmlinuz should be able to be on the same kinds of partitions as standard core.

Damn! Today I created a dcore on a fat32 partitioned sd, I'll have to recreate it in ext2.
Effectively While I import wireless and wifi packages I noticed some permission errors, but I have to admit that it is strange because the distribution work and also connection.

What kind of problems I should have with the tce dir in a fat32 filesystem?

[Jason W]

Given the permission needs of various apps and files, I would expect a lot of problems.

If the space needed for unpacking was not so great, then the unpacking could take place in RAM.  But with 2GB or more being standard RAM size, it may be feasible to have an option to unpack in RAM to allow non-linux filesystems to be used with dCore.  That would help folks with a Windows HD install and a fat32 usb stick as their only storage. 

This approach would make an unexpected system lockup due to lack of RAM possible, and would have to be used with caution.  I will ponder it.

[vinnie]

Thanks Jason, I will make a small hypothesis, I do not know how the mergin script you created works, but if combine packets is less costly in terms of space, why not create small packets and then merge them?

[Jason W]

Robert created the searching|fetching|merging, and everything is unpacked to one directory and then made to a squashfs sce.  At present with squashfs there is no way to do it in pieces.

[tinypoodle]

This approach would make an unexpected system lockup due to lack of RAM possible, and would have to be used with caution.  I will ponder it.

That risk could be reduced by creating a swapfile on top of existing vfat.

[Jason W]

True, it would be at a "use at your own risk" option assuming one knows the potential danger.  But it would allow the use of fat filesystems exclusively for dCore if one wanted.

[Jason W]

I plan to at least make a check for the filesystem type of /etc/sysconfig/tcedir, and exit it if is non linux compatible.  Maybe then allow an option to use /tmp as the unpacking directory.

Since many users are using usb thumb drives, even with a linux file system flash drives will take a pounding if the unpacking directory resides on them.  An option to use RAM would be good for anyone not using  a standard hard drive.   I will ponder it some more.

[vinnie]

I also think it's the right way,  but (imho) you should not make the control, because someone might be interested to use the ram while having an ext filesystem (e.g. for speed reason).
You could create a something like a flag.

[Jason W]

Boot code for unpacking in RAM being tested.  Also, in conjunction, a boot code for echoing the download size, unpacking size, and the final sce size before the final "y" answer to proceed with import.  No performance loss for all, in fact the DEBINX file has been trimmed further of unneeded stuff to at least offset the re-inclusion of the needed Size and Installed-Size fields.   Custom .tar.gz packages and -data.tar.gz files are included in this download/unpack calculation.  Will test and add to git, look for it in the next release.

I personally think a boot code for this situation is more appropriate as folks will desire one particular behavior during a session without having to remember to add a flag to importsce.