read/write permissions on PTVnet drives

[rrauenza]

The PTVnet cd seems to leave the root drive in RW mode on boot (/init/ 002_62start.init). I was thinking of commenting the remount out or putting it back in RO mode in the rc.sysinit.author file.

Any known repercussions? Is this just an oversight? Obviously it needed to be RW on the first boot to setup all the flags, images, etc. Oh.. maybe it does that on every boot?

[Lou Jacob]

The PTVnet cd seems to leave the root drive in RW mode on boot (/init/ 002_62start.init). I was thinking of commenting the remount out or putting it back in RO mode in the rc.sysinit.author file.

Any known repercussions? Is this just an oversight? Obviously it needed to be RW on the first boot to setup all the flags, images, etc. Oh.. maybe it does that on every boot?

Its not an oversight... the only repercussion of editing that file is that if you make a mistake, you could end up with an unbootable TiVo.

If you want to make the root file system read-only, just telnet into the unit and type "rootread" and it will be read-only.

But realistically, it just doesn't matter...

[rrauenza]

Thanks. I just wasn't sure if TIVO (or any of the software in /ptvupgrade) expected it RW these days.

I'd prefer it to be RO in my case. That way while my mucking in /var with other tools I don't accidentally touch anything in /. I've also had to repair at least one linux box that failed an fsck on / during boot... on the other hand, / included var and mail and logs on that box... but that's for another forum.

Rich

[Lou Jacob]

That makes sense... there is nothing that we install that requires it to be writable and it is probably a good idea to keep it read-only just in the case you make a mistake.

You've probably discovered this already but /var can be a dangerous place to keep things as /var can be destroyed and recreated by the OS if there is corruption, so do be careful not to put anything particularly important in /var if you can avoid it...

[rrauenza]

Yes, thanks for that warning -- I hadn't known that /var could disappear until I started hacking this Tivo for the 2nd time. I wanted to go to a single 500GB from the dual 120's that were whining in order to reduce heat and power since my power supply died. I then needed ptvnet to get the shows back on since I couldn't use mfsrestore (too many partitions on hda)

I wrote a backup script to grab everything in /var (and a different one to grab /ptvupgrade and /init). If you have a Linux box (maybe you can do this in cygwin in XP), you can use autoexpect to create an expect script to telnet in and tar up /var and /etc/rc.sysinit.author. Then use something like ncftpget (or maybe lwp-download) to grab the tar file.

Or if you install dropbear, use recursive scp... or maybe just

$ ssh root@tivo /ptvupgrade/busybox/tar cf - /var > var.tar
Rich

[rrauenza]

So I suddenly realized, "If I could just get rsyncd running on the tivo, I could add it to my BackupPC cluster..." and it works.

rsyncd binaries: http://tivoutils.sourceforge.net/

bash-2.02# grep rsync /etc/rc.d/rc.sysinit.author
/var/hack/bin/rsync --daemon --config=/var/hack/etc/rsyncd.conf &

bash-2.02# cat /var/hack/etc/rsyncd.conf
use chroot=yes
secrets file = /var/hack/etc/rsyncd.secrets

[sharename]
uid = root
gid = root
auth users = user
read only=yes
path = /

bash-2.02# cat /var/hack/etc/rsyncd.secrets
user:password

On the BackupPC server I had to disable --checksum-seed.

[root@tendo pc]# more tivo.pl
$Conf{RsyncShareName} = [
'sharename'
];
$Conf{BackupFilesExclude} = {
'*' => [
'/proc/'
]
};

$Conf{RsyncArgs} = [
'--numeric-ids',
'--perms',
'--owner',
'--group',
'-D',
'--links',
'--hard-links',
'--times',
'--block-size=2048',
'--recursive'
];

You could also enable rsync writing in lieu of ftp for dropping new files...