Tiny Core Linux
dCore Import Debian Packages to Mountable SCE extensions => dCore X86 => Topic started by: nitram on February 26, 2016, 06:18:32 AM
-
The exittc and backup commands don't work in latest dCore-jessie:2016.02.25. Restored from a different mydata.tgz, same issue. Reverted to dCore-jessie:2016.02.24.12.16 and exittc works again.
-
Maybe incorrect, also have an issue on dCore-jessie:2016.02.24.12.16 :
tc@box:~/HELP$ backup
Backup device is set to: sdb4/tce
Perform backup now? (y/N) y
/usr/bin/filetool.sh: line 160: can't create /etc/sysconfig/backup_device: Permission denied
Backing up files to /mnt/sdb4/tce/mydata.tgz
Done.
/usr/bin/filetool.sh: line 200: can't create /etc/sysconfig/backup_device: Permission denied
The sdb4/tce path is correct and /tce permissions are tc:staff 775. Data seems to be saving despite the error message. At least with this dCore version exittc runs. Not sure what exactly the problem is. No issues importing an SCE into /tce/sce. Will re-import Xprogs and reboot.
-
Re-imported Xprogs, same backup errors. Re-installed latest dCore-jessie:2016.02.25.21.43 and exittc once again fails to open.
-
Ok, probably due to the path change in /etc/profile. Will revert tonight and deal another way with fltk editor, will likely rename it to fltk-editor, yeah, best to change the offending filename than move a mountain for it.
-
Should be fixed in latest RC.
-
Thanks Jason, functionality of exittc and backup is restored in latest RC. Still get the error messages above during CLI backup, but it works. Maybe those errors have always been there, not sure.
-
hi guys,
I use piCore and have noticed similar errors more than a year ago.
Although I haven't looked at it for a while I assumed the issues was caused by mixing "$ sudo filetool.sh -b" and "$ backup". I thought the issue was related to the permissions of backup_done or backup_status.
regards
Greg
-
Changed the ownership of /etc/sysconfig from root:root to root:staff. Should work now. Please test.
-
Updated dCore-jessie:2016.02.27.00.41, no difference. Noted the root:staff syconfig plus the backup_device file is already root:staff. Running backup via sudo backup works, so definitely some funky permission stuff. After chmod of backup_device from 644 to 664 both errors disappeared during backup.
-
Seems due to not having group writable for the file /etc/sysconfig/backup_device. Probably always been there, but will change the files in that dir to group writable.
-
Booted TC6, no backup errors and boot_path is already 664 permission. So likely a TC permission change that never made it to dCore.
This is from TC6:
tc@box:/etc/sysconfig$ version
6.4.1rc1
tc@box:/etc/sysconfig$ ll
total 44
-rw-r--r-- 1 root root 5 Feb 27 04:05 Xserver
-rw-r--r-- 1 root root 2 Feb 27 04:05 backup
-rw-rw-r-- 1 root staff 9 Feb 27 04:05 backup_device
-rw-r--r-- 1 root root 9 Feb 27 04:04 cdroms
-rw-r--r-- 1 root root 8 Feb 27 04:05 desktop
-rw-r--r-- 1 root root 5 Feb 27 04:05 icons
-rw-r--r-- 1 root root 10 Feb 27 04:05 keymap
-rw-r--r-- 1 root root 7 Feb 27 04:04 language
-rw-r--r-- 1 root root 7 Feb 27 04:05 mydata
-rw-r--r-- 1 root root 0 Feb 27 04:05 newmodules
-rw-r--r-- 1 root root 13 Oct 5 15:11 ntpserver
lrwxrwxrwx 1 root root 13 Feb 27 04:04 tcedir -> /mnt/sdb3/tce/
-rw-r--r-- 1 root root 3 Feb 27 04:04 tcuser
Based on TC6 comparison above and the fact that everthing else appears to function fine, probably just the backup_device file that needs to change to 664.
-
Tested latest RC, fixed, thanks.
Although the errors were harmless, unnerving to see them during a backup.