Running from a usb stick on RaspberryPi B+

Max2Play Home 2016 (en) Forums Max2Play on Raspberry PI Running from a usb stick on RaspberryPi B+

This topic contains 5 replies, has 4 voices, and was last updated by  justinj 1 week ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • 11. Juli 2016 at 15:31 #21414

    Just in case any other newbies like me were wondering if it’s possible to run max2play from a usb stick, I can confirm that it is. Doing so is reckoned to reduce the amount of wear and tear on micro sd cards, which are generally regarded as being less robust than a usb stick. It also means you can use a smaller capacity micro sd. I’m using the original 8gb card that I ordered with my pi, but 4gb or even 2gb (do they exist?) would be ample. I have just the boot files still on the sd card, everything else on a 32gb SanDisk usb stick. I followed this guide to get it up and running: http://www.instructables.com/id/Boot-the-Raspberry-Pi-from-USB/?ALLSTEPS

    It’s working fine, including the additional configuring needed to make use of the CirrusLogic audio card I have installed, so I hope this may be useful to others.

    PS Another reason for setting up this way is that I want to use the audio card to record from my vinyl collection. Still waiting for some response to my separate post on that topic! (Hint, hint!)

    28. August 2019 at 12:29 #46898

    Hi,

    Any news on this. I would love to be able to use a USB for Max2Play rather than SD Card

    Sean

    2. September 2019 at 9:24 #46954

    Hi Sean,

    Currently there is no ideal solution for us to implement yet but we are evaluating options and are open to any new solution you might find.

    10. September 2019 at 15:46 #47067

    Sean,

    I think the devs have given up on this, maybe there’s not enough money in it. I’ve had questions go unanswered that their „head developer“ was going to look into and now they’re asking you to fix it for them lol.
    The only reason I can see thus far for it being incompatible is the devs hard coding devices in /dev
    What they should be doing is something like a cat fstab | grep " / " parsing the UUID and then getting it’s /dev mapping with something like blkid | grep "PARSEDUUID" so that it doesn’t matter how it’s mounted (SD mounts as /dev/mmcblk* whereas USB is seen as a storage device and is thus mapped as /dev/sd* )
    They have hard coded devices instead of using mount points or parsing on a number of scripts. If you update them to the correct path they work fine.
    As much as M2P looks nicer and has a few other ‚premium‘ features, I am considering PiCorePlayer as M2P is requiring more patching than using to get going I’m afraid 🙁

    10. September 2019 at 18:02 #47068

    I use both. I have a headless player attached to my main room Amp & Speaker Set but I use the M2P device with a touchscreen upstairs.

    My preference would always be USB as that way I can swap it out without having to dismantle the Pi to get at the SD card although I am looking at an SD card on an extended cable as a work around

    Sean

    10. September 2019 at 18:50 #47069

    All I did was write the image to USB instead of SD, connect to a Linux machine so I could edit the below files in a text editor (I’m using a Pi3 A+ so I don’t have a spare USB to connect a keyboard to when it’s running). It wasn’t running in AP mode properly (Would start for a moment then disappear) and without being able to connect to it to investigate due to 1 USB port, I disabled AP mode. I’m assuming it’s related to rc.local and/or the hard coded /dev addresses as the same image booted fine from SD.

    Added to the end of /opt/max2play/wpa_supplicant.conf
    network={
    ssid=“SSID Name“
    psk=“1234567890″
    key_mgmt=WPA-PSK
    }

    In /opt/max2play/options.conf
    Changed
    auto_accesspoint_mode=0 (from 1)
    Added
    autoreconnect_wifi=1

    In /etc/network/interfaces
    Uncommented bottom 5 lines

    I stuck the USB in the Pi, it rebooted and gave an error when resizing due to the hardcoded devices. I resized the partition manually via SSH, rebooted and it was good to go.

    • This reply was modified 1 week ago by  justinj.
Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.

Register here