Tiny Core Linux
dCore Import Debian Packages to Mountable SCE extensions => dCore X86 => Topic started by: sbaguz on July 27, 2016, 08:43:12 AM
-
Dear all,
recently I managed to build a beautiful customized dCore system, I have spread it over several USB keys and PCs and finally I've been able to install grub4DOS on my company laptop without even touching the Windows MBR to have dCore always with me even at work...
Now the problem: the PC have a Windows 7 system installed on a NTFS partition.
This partition, where the tce folder reside, is mounted read-only during dCore boot and I can't use ntfs-3g afterwards to be able to save my changes while shutting down.
I have already tried the manual procedure (cat core.gz ntfs-3g.gz > mycore.gz) suggested in http://forum.tinycorelinux.net/index.php?topic=6246.0 (http://forum.tinycorelinux.net/index.php?topic=6246.0) without success (it seems the system doesn't load any extension).
Since I have no more time to try to port the script provided in that thread to dCore and even to well understand it (e.g.: the sed part is quite frightening... :o ) do you have any suggestion/workaround to make me reach my goal?
Thanks in advance.
-
Though dCore supports *.gz initrd files as a part of a remaster in /tmp/builtin, remasters of the main initrd are a last resort to me as that inhibits keeping with updates. If you have an ntfs-3g.gz, then you can place it the chosen /boot directory and specify it as another initrd in the boot loader, below is what I used with grub2 to have ntfs-3g available as if it were in the main dCore-*.gz image, and hopefully similar works with grub4dos:
insmod ext2
set root='(hd0,msdos7)'
linux /boot/vmlinuz-wily quiet max_loop=256 tce=sda7/tceimport-wily showapps user=jason nozswap desktop=startlxde
initrd /boot/dCore-wily.gz /boot/ntfs-3g.gz
In fact, I a have created an sce2gz tool that is available as an extension that can create a *.gz out of an SCE in the SCE directory or one of one's choosing. Works much like sce-load. This is mainly to support ntfs-3g and perhaps wireless, but should work in any case. Startup scripts in the extra *.gz are processed as usual and added to the list of installed packages. It is assumed sce2gz is used to create the extra initrd's, convert raw Debian packages at your own risk.
Please try booting with the extra initrd and let me know how it goes.
-
Hi Jason,
thanks for the quick answer.
Everything went fine... apparently.
I easily created the ntfs-3g.gz, I added it to the menu.lst of grub4dos (by the way: it works exactly like grub-legacy), the boot process gave no problems and the ntfs-3g package was up and running after the boot... but the NTFS disk was loaded read-only as before!
To be honest, I already had this problem even with the ntfs-3g.sce in sceboot.lst: I always had to manually load NTFS partitions when needed with the ntfs-3g command, but it was not so different from using the Mount Tool, so I was not so much worried about it. Now the situation is obviously different.
What do you suggest?
Another (probably stupid) question: since dCore should load everything in RAM, why I can't simply manually umount the partition where tce folder resides (the device is busy) and then mount it again with ntfs-3g command?
-
Extensions are loop mounted to /tmp/tcloop.
if a file /etc/sysconfig/tcedir/copy2fs.flg is present at boot time, everything is copied to RAM and the boot device can be un-mounted.
-
Thanks for the hint Misalf: as said, it was a stupid question... now I understand, nevertheless I would like to avoid the Copy Mode, but I will consider it as the last resort if we weren't able to make ntfs-3g work as expected. ;)
-
When you boot with your ntfs-3g.gz , does /etc/fstab contain something like this?
/dev/sda1 /mnt/sda1 ntfs-3g noauto,users,exec 0 0 # Added by TC
-
/usr/sbin/rebuildfstab needed a bugfix for ntfs-3g. Please try with the latest release candidate and it should be working. Thanks.
-
@Misalf:
my fstab unfortunately shows a plain NTFS filesystem as expected, like this:
/dev/sda2 /mnt/sda2 ntfs noauto,users,exec,ro,umask=000 0 0 # Added by TC
@Jason:
I'm sorry, but using the latest Release Candidate didn't solve the problem (actually the fstab above is taken while using it...).
I don't know if this could help, but I noticed that /usr/sbin/rebuildfstab is looking for ntfs-3g executable (or link) in /usr/sbin/ itself, but I have no ntfs-3g links here and the executable is in/bin/.
-
copy2fs doesn't exist in dCore
-
Ok, thanks, I will fix the ntfs-3g issue in rebuildfstab tonight.
-
If I understood well also mount tool needs the fix
-
I suppose that solving the fstab problem will automatically solve also the problem of read-only mounting by Mount Tool... ???
-
New RC uploaded, hopefully this issue is fixed.
-
:-\ Mmmmh, now there is some problem during boot: I get an error message, extensions are not loaded and I stay to a command line only...
The error message flashes too fast to let me read it: it's "can't stat something"...
It is maybe related to the Xprogs update you suggested? (By the way: how can I update it if I have no persistence? :o )
-
Add the "pause" bootcode.
-
sbaguz - what you see is an output from a startup script in ntfs-3g or it's deps, nothing has been altered there and is harmless or the startup script needs to be adjusted but it would not affect boot. Output is quieted now in the latest RC in tce-setup as it is in sce-load. How is the ntfs-3g recognition during boot now?
If you have no persistence, you would boot to a command line and not X if ntfs-3g is the only .gz loaded at boot. My setup with Xprogs updates, installs, and boots as expected.
-
@Curaga: thanks for the hint.
@Jason: I have been able to update Xprogs (getting the persistence by extracting with cpio the stable release initrd and manually putting /bin/ntfs-3g as path in rebuildfstab), but booting again with the latest RC brought what you can find in the attachment and no extensions...
-
sbaguz - Are you sure you are getting persistence or a mounted filesystem, is it /dev/sda2? It appears ntfs-3g is not working when only /bin/ntfs-3g is simply copied over, it needs to be imported with sce-import and the resulting ntfs-3g.sce converted to ntfs-3g.gz and specified at the boot command line or placed in /tmp/builtin in the main dCore-*.gz initrd.
-
Hi Jason,
yes, I'm sure about getting persistence (I made some changes, e.g. a new wallpaper, I found again rebooting), about having tce in /dev/sda2 and about having ntfs-3g working through the ntfs-3g.gz, all of this when I use the dCore-jessie.gz I built simply replacing the path /usr/sbin/ntfs-3g with /bin/ntfs-3g in rebuildfstab...
-
Ok. The latest dCore-jessie.gz has the rebuildfstab fix in it, please test if you are not running it now, thanks.
EDIT: Oh, I misread, you manually put /bin/ntfs-3g in rebuildfstab and not put the file itself, I see. I will make a TCE directory on ntfs tonight and test booting with dCore-jessie and a created ntfs-3g.gz.
-
Yes, that's what I did. ;)
Anyway, unfortunately also the current version of dCore-jessie Release Candidate doesn't work... (see in the attachments the new error messages compared to what happens with my dCore-jessie.gz).
Hoping this can help here is my dCore-jessie.gz: https://drive.google.com/open?id=0Bzl-sqJAJBBqLUtCb2YtNVk0V1U (https://drive.google.com/open?id=0Bzl-sqJAJBBqLUtCb2YtNVk0V1U) and my ntfs-3g-gz: https://drive.google.com/open?id=0Bzl-sqJAJBBqODk0Rk40M2RnQ2c (https://drive.google.com/open?id=0Bzl-sqJAJBBqODk0Rk40M2RnQ2c).
Bye
-
So from what I understand the dCore-jessie release from 7/16/2016 works with the only change being the rebuildfstab edit, while the current one does not?
-
Ok, I have added ntfs-3g and fuseblk to sce-import as the types that require the -r option with sce-import or needing to specify RAM=TRUE in /etc/sysconfig/sceconfig, or else it exits. That is probably why your SCEs are not working as any Windows filesystem does not properly support Unix permissions and the TCE directory are where the packages are unpacked by default to be repacked into an SCE. I also corrected permissions of files created in /tmp with tce-setup.
Please test the latest RC, starting your SCE directory from scratch and re-import your SCEs. Thanks. I have a dCore-jessie install working well with an ntfs-3g TCE directory now when using an ntfs-3g.gz initrd specified at the boot prompt to install the needed ntfs-3g files.
EDIT: I see an issue that the ntfs-3g startup scripts needs to handle that likely caused the issue you were seeing. Will get to tonight.
-
Yes, I confirm dCore-jessie release from16/07/2016 works fine with the only change being the rebuildfstab edit.
All my packages were already imported with the -r option.
Anyway I will wait for your new update of tonight before doing any further test... :)
-
I did see a "$USER":staff perms of the ntfs-3g files on a previous session which is surely the cause of your issue, but upon a current import of ntfs-3g and a conversion of it to .gz via sce2gz I have only seen the preservation of the root:root perms of the ntfs-3g files across many reboots of 2 dCore ports and with the ntfs-3g.gz in both /tmp/builtin and when speficied by the boot command line. I have updated sce2gz, as well as the dCore images to better support the .gz files. Please re-import ntfs-3g and convert to .gz with an updated sce2gz, and test with the latest dCore RC. Thanks.
-
SUCCESS! :D
The latest versions of dCore-jessie.gz and sce2gz you uploaded solved any issue.
Thanks for your support.