Any luck using Berryboot to install Patchbox-os on p4?

I’ve been having a terrible time. Because of the particular case I’m using, I don’t have easy access to the SD card. Hence, I would really like to run Patchbox on a multi boot card. I dabbled briefly with Noobs, but would prefer to use Berryboot for it’s greater flexibility. Neither boot manager has allowed a successful install of Patchbox to date, however. Im inclined to think the problem is in how the 2nd partition filetype is not being recognized in the image file.

If no one has a eureka reply (I’m hoping I just missed the thread or FAQ explaining this), I’ll go into greater details of what I’ve tried so far.

Thanks!

Hi, I haven’t used Berryboot myself, but the Patchbox OS is based on the same image generator as Rasbpian’s images are, so I’d expect the image to be compatible.

Did you do the steps described here: https://www.berryterminal.com/doku.php/berryboot/adding_custom_distributions to convert the image to the right format for Berryboot? Did it succeed?

Hi Giedrius,
Thanks for getting back to me. Yes, I tried to implement the steps outlined in the link you mentioned. The kpartx command fails, which has lead to other pages addressing THAT issue and other attempts to work around, all of which failed in their own ways. I’ve apt-get install’d kpartx, squashfs, and various filetypes including ext4. In this process, I’ve come to find a few things not mentioned on the link you provided:
Bootberry expects an image file that has been compressed with squashfs, The Patchbox image is not squashed and so far, that is where I’m hung up. It seems I can not identify the filetype of the second partition of the Patchbox image as ext4 and even if I assume ext4, the resulting distribution will not run. Bootberry will recognize the squashed image file and install it to it’s own partition, but then the system crashes when I try to boot that partition via Bootberry. I am assuming a corrupted image, but I’m lost at that point.
I also made an SD that I used the dd command to place the Patchbox image onto it. Again, Berryboot recognized the image and added/copied it to the the Pi, but it failed to boot.
It’s been a long time since I’ve dug into linux, so I’m practically a noob, I’m sure I’ve missed something obvious to everyone else here! My next steps would be to swap the “main” SD card with one that I’ve created a distribution as per the Blokas tutorials. If I get that up and running, swap cards again and see if I can get Berryboot to somehow copy or back it up to the “main” SD. Ultimately, I want a multiboot system so that I don’t have to swap cards.
Again, any thoughts or suggestions would be greatly appreciated.

So I figured out a solution to use Berryboot to load Patchbox. 1) Unzip the patchbox image and install it to an SD card via Etcher. 2) mksquashfs the rootfs folder. Name the resulting file with a .img extension (e.g. ‘Patchbox.img’). 3) Use this squashed file as your new image file when you tell Berryboot to add a new OS via a USB stick.

I successfully added Patchbox and ran through the configurations. I’d love to say everything is working fine, but I’m now having problems with Patchbox loading the desktop. However, I believe this to be configuration errors on my part and beyond the issue of loading PB via Berryboot so at least this problem is solved.

1 Like

What do you mean by loading the desktop? You want it to start into console only? You may change it in patchbox utility (you may have to run update first)

Hi Giedrius (and all) - Sorry for the long delayed reply. Life tends to redirect me for large amounts of time. As to my earlier statement where I mentioned the desktop, I should have said, “run startx”. But I have had several problems and some success at getting my configuration up and running with Berryboot and I’ll come back to the startx issue in a moment with more context.

First off, getting an image of Patchbox loaded via Berryboot: Giedrius was correct with his original suggestion of the steps listed in https://www.berryterminal.com/doku.php/berryboot/adding_custom_distributions . For some reason, as I had mentioned above, I could not get kpartx to work for me to save my life. I won’t go into the massive odyssey that’s taken me on, only to say, I kept looking back at the original solution presented and saying, “that addresses all the problems I’m facing if only I could get it to work!” Then just a few days ago, for grins I tried it again… and it worked flawlessly! I can only assume kpartx or some dependency got an update that fixed my original problem. Regardless, I now have two copies on I can boot from as well as Rasbian on my RPi4. However, the installations have not been flawless and I’m currently trying to trouble shoot the resulting symptoms.

The first error I catch on bootup is something about the EPROM access(?) failing. Looked like some utility and it certainly wasn’t a critical failure. Sorry I can’t be more specific, as it flashes by early and quickly during the boot and I haven’t looked at it in journalctl deeply yet.

Next is dphys-swapfile produces an error on boot. Subsequent install get-update operations all mention an error trying to use dphys-swapfile, though the failure seems non-critical So far, changes to the parameters within dphys-swapfile have not made any change to the problem. Some of my readings suggest this is an inconsequential matter, but it’s one of the few failures I see when Patchbox boots up. Could this be because I’m using Berryboot (or any bootloader like NOOBS)?

Bluetooth. I have been unsuccessful at configuring bluethooth. Using patchbox>Manage Bluetooth>status, I get:

bluetooth_supported=0
bluetooth_service_active_state=active
bluetooth_service_sub_state=running
bluealsa_service_active_state=inactive
bluealsa_service_sub_state=dead
hciuart_service_active_state=inactive
hciuart_service_sub_state=dead

bluetoothctl>list returns empty
bluetoothctl>show and most other commands return, “No default controller available”.

rfkill list all shows
0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no

I have been able to start and connect to the Pisound WiFi, but can not get beyond that.

Before mentioning my problem with startx,I should go into how the RPi4 is configured, as this not only might shed light with my startx problem, but perhaps the other problems I’ve already mentioned.

The RPi4 has 4Gb, has an OFFICIAL RASPBERRY PI 7" touch sensitive monitor attached in via the ribbon port, is housed in an OFFICIAL RASPBERRY PI enclosure that have been upgraded with a dual-fan, full body heat sink (OFFICIAL RASPBERRY PI?) where I have then added header pins to extent the GPIO so as to allow the attachment of the Pisound card. I was running a wireless keyboard off of a usb port, but switched it out for a straight up usb keyboard to see if that effected the bluetooth problem, which it didn’t. There’s many reasons why I’d like to get this configuration to work, but i’m fully aware this is not typical setup or intent of most successful Pisound installations I’ve seen to date. To further add insult to injury, I am trying to come up the learning curve quickly and know a smattering of information randomly gleaned by running into problems such as this. So any specific information I provide that’s of any use to anyone is probably more luck than skill! Please bear with me.

Needless to say, when I try to run startx, my terminal becomes a blank cursor and is unresponsive to any commands. I have tried plugging a monitor into HDMI 1 and 2, but get nothing there. 1 just has the rainbow screen and 2 remains off. My only option at that point is a power cycle. Startx is not my first priority however, as my goal is to get up and running with the Pisound.

I realize I’m throwing a lot of issues out there that might not be directly related to the original Berryboot question. I think that issue is close to being put to bed with a successful resolution and then move the other issues to other threads as needs be, but again, I look to yours and the hivemind’s guidance in this matter.

Thank You!

Hey, could you attach the dmesg log produced after booting up?

I found that Raspberry Pi’s are not good at auto-detecting the display, so it has to be connected before powering on the device.

To recover the unresponsive terminal, you may try clicking Ctrl+C; Ctrl+Z; Ctrl+Alt+F1 (or Ctrl+Alt+F2, etc… up to F7 I think, these commands switch the currently active ‘terminal screen’)