Problems Building New Octopi/OctoPrint SD Card

Get Help
1

What is the problem?

I have had multiple distinct problems attempting to build a new SD card for my Raspberry Pi 4B. I am looking for suggestions on both issues.

  1. Cloning my working SD card on a Mac
  2. Building a new SD card using the Raspberry Pi Imager

What did you already try to solve it?

Issue 1 Cloning my working SD card.
Created image files of my working card using both 'dd' and 'gdd'

  • I was able to create a .img file using dd and a .dmg file using gdd
  • I installed extFS for Mac from Paragon Software
  • I am able to mount the boot and rootfs partitions from the .dmg file on the Mac
  • I am able to verify both image partitions without issues
  • I attempted to copy the .dmg image to a new SD card using gdd, sometimes it works, sometimes it gets an i/o error, with one less block written than read. When I verify the 'rootfs' partition on the new SD card using extFS, it indicates a mismatch between the number of physical blocks and the number in the partition table (partition table being larger), and indicates the table is probably corrupted. If I attempt to boot the Raspberry Pi with the card, it fails because it cannot mount the root file system.
  • I attempted to copy the .img image to a new SD card using the Raspberry Pi Imager (v1.8.5). The attempt failed because the new 32 GB card is smaller than the image. Verified that the new 32 GB card is indeed smaller than my working card. This probably accounts for the partition table issue above. None of the SD cards I recently purchased are large enough for the image.

Issue 2 Creating a new SD card using Raspberry Pi Imager (v1.8.5)
I can successfully create a new SD card using the Raspberry Pi Imager, but they don't appear to work.

  • Some of the time when I boot the Pi with the imaged card, it immediately displays a white box on a blue field with the text "Resizing root filesystem..." along with a warning that this could take a while. After a while, underneath the blue field I see "Error: Input/output error on dev mmc:blk0" with an offer to "Retry/Ignore/Cancel?". No keyboard is installed, so I cannot progress further.
  • Some of the time the card appears to boot as expected, with a message that ssh keys are being generated, a restart, and then a bunch of console message before the screen blanks and displays a white box with the words "No signal" (presumably generated by the display). At this point I try to connect using the command ssh pi@octopi.local from Terminal on the Mac, but the Pi never responds. The Pi does not appear to be connected to the WiFi network (according to my router). There is no response if I try opening octopi.local using a web browser.

Have you tried running in safe mode?

Not applicable.

Did running in safe mode solve the problem?

Not applicable

Systeminfo Bundle

Never get far enough to create, much less download a Systeminfo Bundle

Additional information about your setup

OctoPrint version: depends on image used to create SD card, from 1.8.6 to 1.11.0
OctoPi version: 1.0.0
Printer: Ender 3 with BTT SKR Mini E3 V3
Firmware: Klipper
Printer processor: Raspberry Pi 4B with 4 GB memory
Printer operating system: depends on image, Debian Buster or Raspbian Bullseye
HDMI display, 800 x 480

Mac Studio 2023 (Apple M2 Max processor, 64 GB memory)
Operating system: macOS Sequoia 15.4.1
Browser: Safari

2

Check your power supply. If its not supplying enough current to the Pi, it will have issues reading/writing the SD card. What do you have plugged into the pi's USB ports? Some USB devices, including some keyboards, can draw more power than the pi can provide to the USB and that will also cause low power issues.

3

Thanks for the suggestion. The only items on the 24 V power supply are the printer, a DC-DC converter, and some LEDs. On the 24 V to 5V converter is the Pi, and a relay to power the printer. Connected by USB are the printer (with the power leads disabled), a camera, and the display.

In normal operation (with a working SD card) and while printing there have not been any indications of low voltage. The current being drawn from the power supply while the printer is operating should be much higher than with the printer idle (none of the heaters or stepper motors engaged).

4

I have continued to poke around and have made some observations that explain some of what I am seeing with regard to Issue 2.

I had two SanDisk Ultra 32 GB memory cards that I purchased in Jan 2023. OctoPrint and Klipper work on both of these cards, and OctoDash works on one of the cards. I recently purchased two more of what I thought were the same SanDisk cards. Neither of them work reliably with the Pi. I also purchased a PNY card.

With the exception of the card with everything working (OctoPrint, OctoDash, Klipper), the boot partition is 267.4 MB, as reported by macOS. For the other card the boot partition is 264.3 MB.

For the older cards the rootfs partition is 31.65 GB, as reported by macOS. I do not know the initial size since they were created and resized a long time ago.

In the Raspberry Pi imager, all of the SanDisk cards are shown as 31.9 GB capacity. The PNY card is shown as 31.0 GB. When the imager completes writing the cards, but before the first boot attempt, the size of the rootfs partition on the SanDisk cards is 2.63 GB. Apparently, it is normal for the Pi to resize the root filesystem on the first boot. When I attempt to boot using the SanDisk cards, one of the cards consistently fails during the root system resize, with the I/O error noted in my original post. The rootfs partition remains at 2.63 GB. The other card sometimes will display a dialog box indicating that Resizing the root file system failed, and an OK button (I think, it is hard to read). Cycling the power to the Pi will sometimes allow that card to boot, and the rootfs partition is 31.64 GB.

For the PNY card the size of the rootfs partition is 1.84 GB before booting, and 30.72 GB after booting. This card has not had issues during the root file system resize, and the resize takes place quickly.

With regard to WiFi, I looked at the SD cards when mounted as ext4 drives. For the Octopi images, the /etc/wpa-supplicant/wpa-supplicant.conf file is a link to /boot/octopi-wpa-supplicant.txt, so it will not connect to WiFi unless you correctly edit the file on the /boot volume. In the Octopi image the hostname is octopi, as expected. I am still not certain why WiFi does not connect when I create a non-Octopi image, but specify the information in the Raspberry Pi Imager "OS customisation" (sic) settings and select to apply them.

As it currently stands, I can consistently create an image that connects to WiFi and I can open an ssh session using the PNY card, but there is still something wrong. The filesystem appears to be mounted as read-only. After some searching, I used the command sudo mount -o remount -t ext4 / and it resolved the read-only issue, temporarily. I was able to run the sudo apt update command successfully, but when I tried sudo apt upgrade it was read-only again.

5

With as much trouble as you are having with SD cards I suspect that you may have a hardware issue. Since you have a RPi 4B, I suggest a simple experiment, substitute a USB flash drive for the SD card.

Search for "raspberrypi 4 model b boot from usb" for multiple links. This one or this one should detail the steps. The only tricky part is making sure you have the latest bootloader.

There have been reports of counterfeit SD cards so you might want to search for a capacity test for MacOS. Once you have your RPi 4B booted from a USB flash drive, you could probably find a way to test the SD card on the RPi itself.

6

Thanks for the suggestion. I have created a USB drive using the Raspberry Pi Imager. I also used one of my working SD cards to boot the Pi, and then used raspi-config to change the boot order to boot USB first. I was able to boot the image on the USB stick and am in the process of updating the operating system (Raspbian Bookworm) to the current version. It is very slow compared to using an SD card.

My plan is to then use the Pi booted off the USB to run fsck on the SD card to see if I can fix the filesystem on the SD card.

With regard to SD cards, perhaps they don't make them like they used to. :slight_smile: Checking the size of the cards can only be done after I have purchased a card. Perhaps I will try a few more to see if there are any with enough space to clone my working drive.

I did note that the SanDisk cards have a disclaimer that essentially says that a MB is 1,000,000 bits,
not the 1,048,576 bits that any respectable computer scientist would expect. My suspicion is that the array may be designed with the classical MB, but that they use the "new" definition to recover yield loss.

7

Are you using a USB2 or USB3 device?

My experience with a USB3 flash drive is slightly better performance on the USB drive (SanDisk USB 3.2 130MB/sec read) vs. SD (SanDisk Ultra Plus class 10).

8

I am using a USB2 memory stick, as that is what I had on hand. I have ordered some USB3.2 memory sticks thinking that they would be faster than the USB2 stick if I use them in one of the Pi USB3 slots.

It is good to hear that the performance of a USB3 memory stick is comparable to the microSD. I may just switch to USB instead of microSD, depending on my experience with the USB3 drives.

9

I tried to run fsck with the Pi booted off a USB memory stick, but I could not figure out how to specify the drive in a way that fsck wanted. I found that if I booted off the SD card that I could unmount the card and run fsck. The result was I/O errors.

I also discovered badblocks. So I booted off the USB memory stick, with the SD card in the slot. I had to dismount all of the partitions (using sudo umount /dev/mmcblk0p1 and sudo umount /dev/mmcblk0p2). I used lsblk to determine how many partitions were present. [Note: /dev/mmcblk0 is the Pi SD card slot.] I ran badblocks in read-write (destructive) mode on all three of the SD cards that I recently purchased. The results (if my use is correct) explain the issues I have been having. The command I used is:
sudo badblocks -wsv /dev/mmcblk0

  • The PNY card (which boots, but is mounted as read-only) had no read or write errors, but several thousand bit corruption errors on the 0xAA (1010) and 0x55 (0101) patterns, and several hundred errors on the 0xFF (1111) pattern. Interestingly enough, there were no errors for the all zeroes pattern.
  • On the SanDisk Ultra card that consistently failed root filesystem resize, I quit badblocks after it had logged over 30 million bit corruption errors on just the 0xAA pattern. There were no read or write errors.
  • The SanDisk Ultra card that sometimes booted is still in testing (after over 2 hours), but is showing over 69 thousand bit corruption errors for the 0xAA and 0x55 patterns, with no read or write errors.

It is disappointing that three of three recently purchased microSD cards have failed. At this point I am not sure it makes sense to order more microSD cards. If anyone has any recommendations for microSD cards, I would like to know. I am attempting to return all three cards, the PNY card to the manufacturer (since I did not save the packaging) and the SanDisk cards to Amazon because I recovered the packaging from the trash and SanDisk makes it incredibly hard to return cards not purchased directly from them.

10

I have a USB3 to SD (and microSD) card adapter. I attach it to my desktop to write initial images and attach it to my RPi systems to clone the running image.

I'd suggest you test one of your microSD cards on something other than your RPi because I suspect you may have a hardware issue.

11

Thanks for the suggestion. I haven't found any Mac utility to scan for bad blocks by writing multiple patterns. DiskUtility used to have an option to securely erase a disk by writing multiple patterns, but I don't see that anymore. macOS Terminal does not have the badblocks utility.

As for the Pi hardware, my two older microSD cards work without issues. On one of the cards I recently created a new Octopi image and OctoPrint and Klipper work just fine. I am having a problem with OctoDash, but at this point I don't think it is related to the filesystem.

Out of curiosity, I ran badblocks on the microSD with the Octopi 1.0.0 image using the non-destructive read-write mode. While this mode is probably not as perceptive as the destructive write mode, it is more perceptive than the default read-only test. The non-destructive test uses a random bit pattern for each block, and then restores the original content of each block. The command I used was:
sudo badblocks -nsv /dev/mmcblk0

The result was zero errors. This gives me confidence that the results on the newer cards was valid, and that my hardware is working as expected.

1 Like
12

I never resolved Issue 1, trying to clone my current working image of OctoPrint with Klipper and OctoDash. The problem I encountered was that the new microSD cards and USB3 memory sticks are smaller than my old microSD cards. This prevents me from transferring the old image to any of the new cards or memory sticks. At this point, I am going to give up. Yes, I think it can be done if you are willing to mess with the Raspberry Pi drive partitioning. This is just a bit too involved for me.

I was able to resolve Issue 2, not being able to create an image that worked using the Raspberry Pi Imager. It turned out that all three of the microSD cards I purchased were bad. One was spectacularly bad and never worked, the other two were just bad enough to sort of work before completely failing. I changed the boot order on my Pi to boot from USB first, and from microSD if there was no USB boot image. I have had better luck with USB memory sticks, only one of five was bad.