Home of the Squeezebox™ & Transporter® network music players.
Page 8 of 11 FirstFirst ... 678910 ... LastLast
Results 71 to 80 of 102
  1. #71
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Location
    Nottingham, UK
    Posts
    1,652
    Quote Originally Posted by mrw View Post
    ‘mounting’ or ‘auto-mounting’ ?

    Perhaps auto-mounting is a step too far at this point. I don’t know if pCP handles it, because I don’t use pCP.

    Despite the vitriol that has been poured on systemd by some over the last few years, I have found that auto-mounting/unmounting with systemd is very much more straightforward than the previous setup I had using autofs. That was a pleasant surprise when I got round to upgrading my Debian system a year or so ago.
    Greg did give some advice earlier in this thread (here), on how I might change the behaviour of the mount options (when I was looking to use the UTC option). I didn't ever investigate that further, as the problem went away when I began using ext4 disks. That could be a way to create an auto-mounting entry for my exfat archive disk. But in fact I only need this disk to be mounted in one specific scenario (during my backup script), so doing it manually is no hardship.

    Quote Originally Posted by paul- View Post
    There is nothing automatic in pCP. We just use the mount scripts.
    I found this in pcp_startup.sh:
    Code:
    case "$FSTYPE" in
    	exfat) modprobe fuse; mount.exfat $OPTIONS $DEVICE /mnt/$POINT;;
    	*) mount $OPTIONS --uuid $UUID /mnt/$POINT;;
    esac
    with $OPTIONS set up as:
    Code:
    CHARSET=",iocharset=utf8"
    umount $DEVICE  # Need to unmount incase 1st mount is not utf8.
    OPTIONS="-v -o noauto,users,noatime,exec,umask=000,flush,uid=1001,gid=50${CHARSET}"
    So mount.exfat is indeed the way that pCP does it at boot. I guess I should update my script to use the same options as above.

    Just browsing around the scripts in /home/tc/www/cgi-bin and skimming through pcp_startup.sh gives an idea how much complexity is hidden behind the options available in the pCP interface. I can only imagine how much effort goes into writing and testing those scripts.

  2. #72
    Senior Member Greg Erskine's Avatar
    Join Date
    Sep 2006
    Location
    Sydney, Australia
    Posts
    1,920
    Quote Originally Posted by chill View Post
    Just browsing around the scripts in /home/tc/www/cgi-bin and skimming through pcp_startup.sh gives an idea how much complexity is hidden behind the options available in the pCP interface. I can only imagine how much effort goes into writing and testing those scripts.
    chill, there is over 30,000 lines of code in that directory, probably over 40,000 in total !!

    You have probably noticed the time between releases has lengthened. As pCP gets more complex testing takes longer and longer.

  3. #73
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Location
    Nottingham, UK
    Posts
    1,652
    Quote Originally Posted by Greg Erskine View Post
    chill, there is over 30,000 lines of code in that directory, probably over 40,000 in total !!

    You have probably noticed the time between releases has lengthened. As pCP gets more complex testing takes longer and longer.
    40,000 - wow. Many years ago I did an entire PhD with about half that number (Fortran), and that seemed like a vast project to me at the time.
    As a bit of a novice with shell scripting in general, the techniques that I've seen used in the pCP scripts have been very useful.

    I have another question relating to my backup script. I'd like to automatically copy the pCP SD card (the OS, not the music library) on a remote pCP device (my main Pi 3B+ LMS device) to an image file on another pCP device (my Pi Zero W backing up device). This will allow me to get up and running again quickly in the event of the SD card becoming corrupted. Using dd I can do this from the command line on the Zero W as follows:
    Code:
    ssh tc@192.168.1.4 "dd if=/dev/mmcblk0 bs=512 count=2170880" | dd of=/mnt/MusicBackup/images/pCPLounge.img
    But this won't work from a backup script because the SSH command requires me to type a password. It seems that SSH specifically won't work with a pipe because it insists that passwords are entered from a terminal. There's apparently a linux 'sshpass' command that gets around this, but I can't find that in the repositories. I also found that ttyexec might work to fool SSH into thinking the input came from a terminal, but ttyexec is also missing from pCP.

    So can anyone advise how I might get the SSH login to work from an unattended script under pCP?

    I guess another way to do this would be to get the main 3B+ to backup its own OS to an image file on my music library disk, and then get the Zero W to include that image file in its nightly backup. But I'd still like to know if it's possible to do it from a remote pCP device.

    (apologies - it's getting a bit off topic from the original 'compressed library' thread title, but it's still relevant to a general pCP backup procedure)

  4. #74
    Senior Member
    Join Date
    Aug 2012
    Location
    Austria
    Posts
    1,065
    Quote Originally Posted by chill View Post
    So can anyone advise how I might get the SSH login to work from an unattended script under pCP?
    With key-based authentication (using a private key without a password).

    Generally, you may want to use compression before transfer, e.g. with zstd
    Code:
    ssh tc@192.168.1.4 "zstd -10 < /dev/mmcblk0" > /mnt/MusicBackup/images/pCPLounge.img.zst
    btw, using FSArchiver is much more efficient than dd
    Various SW: Web Interface | Playlist Editor / Generator | Music Classification | Similar Music | Announce | EventTrigger | LMSlib2go | ...
    Various HowTos: build a self-contained LMS | Bluetooth/ALSA | Control LMS with any device | ...

  5. #75
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    548
    Quote Originally Posted by Roland0 View Post
    With key-based authentication (using a private key without a password).
    And when you've figured that out, you could consider restricting the usage of the particular key to a particular command, as you won't be password protecting the key. Just a thought.

    When I set this up on my system (about eight years ago) I felt that needed the -T option to ssh, (disable pseudo-terminal allocation), to ensure that the binary file(s) transferred correctly. But perhaps it isn't necessary, it's too long ago to remember. I am using tar rather than dd, but otherwise the same principle.

  6. #76
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Location
    Nottingham, UK
    Posts
    1,652
    Quote Originally Posted by Roland0 View Post
    With key-based authentication (using a private key without a password).

    Generally, you may want to use compression before transfer, e.g. with zstd
    Code:
    ssh tc@192.168.1.4 "zstd -10 < /dev/mmcblk0" > /mnt/MusicBackup/images/pCPLounge.img.zst
    btw, using FSArchiver is much more efficient than dd
    Thanks - there had to be a way. I'll look into it. For the moment I've simply shifted that task over to the P3B+. It seems quicker to do the 'dd' on the faster processor and onto a local disk, and then rsync it onto the Zero W.

    Compressing it seems like a sensible extra step, but zstd doesn't seem to be available in the piCore or piCorePlayer repositories. From the command you've quoted, it seems to replace dd - is that right? For now I've minimised the wasted image space by shrinking the partitions to the minimum required. The image is 1GB.

    FSArchiver does look like a better way of doing it - but wouldn't you know it, no sign of it in the piCore or piCorePlayer repositories. There are apparently static binaries available, but I can't immediately see one suitable for the Zero W.
    Last edited by chill; 2019-06-08 at 12:04.

  7. #77
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Location
    Nottingham, UK
    Posts
    1,652
    Quote Originally Posted by mrw View Post
    And when you've figured that out, you could consider restricting the usage of the particular key to a particular command, as you won't be password protecting the key. Just a thought.

    When I set this up on my system (about eight years ago) I felt that needed the -T option to ssh, (disable pseudo-terminal allocation), to ensure that the binary file(s) transferred correctly. But perhaps it isn't necessary, it's too long ago to remember. I am using tar rather than dd, but otherwise the same principle.
    Thanks - I'll look into that. I think the risk is minimal in my case - it's just me on my network, unless my router has vulnerabilities I'm not aware of.

  8. #78
    Senior Member
    Join Date
    Aug 2012
    Location
    Austria
    Posts
    1,065
    Quote Originally Posted by chill View Post
    It seems quicker to do the 'dd' on the faster processor and onto a local disk, and then rsync it onto the Zero W.
    reading the card will take the same time in both scenarios, as will the network transfer. Writing to local disk and reading again will add time.
    rsync may reduce the size of the transfer, but only if you update the old image, not if it's a completely new one.
    I'd guess ssh + compressing with something that doesn't make the CPU the bottleneck (e.g. don't use xz -9) will be have the best performance
    (bonus points for using the ssh encryption algorithm with the lowest CPU usage)

    Compressing it seems like a sensible extra step, but zstd doesn't seem to be available in the piCore or piCorePlayer repositories.
    You can use gzip, bzip2, xz, ...
    From the command you've quoted, it seems to replace dd - is that right?
    You don't need dd at all, cmd < /dev/... is enough (you could even use cat < ... for that)
    Various SW: Web Interface | Playlist Editor / Generator | Music Classification | Similar Music | Announce | EventTrigger | LMSlib2go | ...
    Various HowTos: build a self-contained LMS | Bluetooth/ALSA | Control LMS with any device | ...

  9. #79
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Location
    Nottingham, UK
    Posts
    1,652
    Quote Originally Posted by Roland0 View Post
    You don't need dd at all, cmd < /dev/... is enough (you could even use cat < ... for that)
    OK, but recreating the SD card from a dd image is easy - it creates the file system and the contents of the partitions. Would the same apply if I use, e.g. gzip?

  10. #80
    Senior Member
    Join Date
    Aug 2012
    Location
    Austria
    Posts
    1,065
    Quote Originally Posted by chill View Post
    OK, but recreating the SD card from a dd image is easy - it creates the file system and the contents of the partitions. Would the same apply if I use, e.g. gzip?
    Code:
    gzip -dc /mnt/MusicBackup/images/pCPLounge.img.gz > /dev/mmcblk0
    should do the trick
    Various SW: Web Interface | Playlist Editor / Generator | Music Classification | Similar Music | Announce | EventTrigger | LMSlib2go | ...
    Various HowTos: build a self-contained LMS | Bluetooth/ALSA | Control LMS with any device | ...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •