exittc and backup doesn't work in latest dCore-jessie RC

[nitram]

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.

[nitram]

Maybe incorrect, also have an issue on dCore-jessie:2016.02.24.12.16 :

Code: [Select]

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.

[nitram]

Re-imported Xprogs, same backup errors. Re-installed latest dCore-jessie:2016.02.25.21.43 and  exittc  once again fails to open.

[Jason W]

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.

[Jason W]

Should be fixed in latest RC.

[nitram]

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.

[Greg Erskine]

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

[Jason W]

Changed the ownership of /etc/sysconfig from root:root to root:staff.  Should work now.  Please test.

[nitram]

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.

[Jason W]

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.

[nitram]

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:

Code: [Select]

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.

[nitram]

Tested latest RC, fixed, thanks.

Although the errors were harmless, unnerving to see them during a backup.