Lloyd Leung

Category: Linux

  • How I Resolved the “mmc1: Controller Never Released Inhibit Bit(s)” Error on My Raspberry Pi 4 with an Argon One M.2 NVMe SSD

    If you’ve been experimenting with running your operating system from an M.2 NVMe drive on your Raspberry Pi 4, you may have encountered the infamous mmc1: Controller never released inhibit bit(s) error. It can be both frustrating and confusing—particularly if your Pi was happily running from the SSD one day and suddenly decided to fail the next.

    I recently ran into this error after installing an Argon One M.2 case with an NVMe SSD in my Raspberry Pi 4. Below is a walkthrough of my journey, the error symptoms, and the steps I took to get my Pi back up and running.

    What Happened?

    • I was successfully booting my Raspberry Pi 4 from the SSD for some time.
    • One day, it refused to boot, displaying an error message:
      mmc1: Controller never released inhibit bit(s)
    • This left me scratching my head. I wasn’t sure what had triggered the error, and nothing I did seemed to fix it. I was not able to get into recovery mode.

    Potential Causes

    While I’m not entirely certain why my Pi decided to stop booting, here are a few possible culprits:

    1. Firmware or Bootloader Updates: If the firmware or the Pi’s bootloader has changed or updated, it might introduce compatibility issues with SSD booting.
    2. Power Issues: An insufficient power supply or poor connection can sometimes cause read/write errors.
    3. Corrupted Boot Files: Unexpected power loss or filesystem corruption could stop the Pi from properly recognizing the SSD.

    My Recovery Journey

    Because the Pi refused to boot from the SSD no matter what I tried, I ended up taking a more complicated route to recover. Here are the steps that worked for me:

    1. Power off the Raspberry Pi.
      • Important for preventing further data corruption.
    2. Unplug the SSD from the Argon One M.2 interface.
      • With the SSD physically disconnected, the Raspberry Pi is forced to look for other boot options (namely, the SD card).
    3. Boot with a Recovery Image (On SD Card).
      • I inserted a microSD card with a known-good Raspberry Pi OS image or the official Raspberry Pi recovery image.
      • This allowed me to bypass the failing SSD and access the Pi’s firmware/bootloader settings.
    4. Update & Change Firmware to Boot to SD card first
      • Using the Raspberry Pi OS on my SD card, I ran
      • $> sudo raspi-config
      • Changed the Pi’s boot order was set to look for USB devices first. This step confirms that once the SSD is plugged in again, the Pi will attempt to boot from it.
    5. Power off the Raspberry Pi again and reinstall the SSD.
    6. Power on and Image the OS Directly onto the SSD.
      • Using the SD card OS environment, I used the Raspberry Pi Imager (or the dd command / balenaEtcher method) to flash the operating system directly onto the SSD from within the Pi itself.
    7. Power off, Remove the SD Card, and Power on.
      • After a successful OS flash, I shut the Pi down, pulled out the SD card, and let it boot solely from the SSD.
      • The Pi should now correctly recognize and boot from the NVMe SSD.
    8. Change back to boot SSD first, reversing step 4 above.

    Why These Steps?

    1. Forcing a Fresh Boot: By removing the SSD, you sidestep whatever is causing the bootloader confusion or corruption.
    2. Correcting the Boot Sequence: Ensuring the firmware is set to SD card first is critical when you want the Pi to avoid the SSD as the primary boot device.
    3. Fresh OS Installation: If your SSD’s boot partition or filesystem is corrupted, re-imaging provides the most foolproof fix.
    4. Ensuring Power Stability: Although not explicitly mentioned in every step, always ensure that you have a stable power supply (at least 3A for a Raspberry Pi 4). Any power hiccups can cause data corruption.

    Lessons Learned

    1. Backup Regularly
      • Whenever you’re tinkering with new hardware on your Pi, keep your important files backed up or use version control for your critical data.
    2. Keep a Spare SD Card
      • Having a rescue SD card with a clean OS image is invaluable when you need to troubleshoot issues like this quickly.
    3. Check Your Bootloader
      • Periodically ensure your bootloader firmware is up to date. Sometimes old firmware versions can have bugs that are patched in later releases.
    4. Power and Connections Matter
      • A quality USB-C power adapter and solid USB connections help reduce weird errors.

    Conclusion

    Dealing with the “mmc1: Controller never released inhibit bit(s)” error on a Raspberry Pi 4 can feel daunting, especially when your device was previously booting off an SSD without issues. In my case, going through a rather roundabout process of unplugging the SSD, booting from an SD card, fixing the firmware, and then re-imaging the drive finally solved the problem.

    If you’re wrestling with a similar issue, I hope these steps and insights help you recover your system as quickly (and as painlessly) as possible. While it may feel frustrating at first, a little troubleshooting and a clean OS flash often make all the difference.

    Happy hacking—and here’s to a stable and speedy SSD-powered Raspberry Pi experience!

  • Automation…

    Controllers:
    Raspberry PI for the logic. it’ll have it’s own 802.11n USB adapter
     
    Project Ideas:
    The promise, is to use an ESP8266, to control a bunch of relays.  Using the Raspberry PI for logic control.

    1. DIY 1 plug relay – HRV control.
      1. Check to see (via the NEST) if the humidity is high or low, run the HRV
      2. Intermittent running of HRV when
        1. Run HRV if not during peak/high energy rates…
    2. DIY 8 plug power bar, timer on/off control.
      1. Build your own power bar, that is WIFI controlled.
      2. ESP8266 has several GPIO pins.  Wire them up to relays, to get some relay action going.
        1. Printer on demand.
        2. Scanner on demand.
        3. VPN hardware on during weekdays work hours.
        4. Monitors (5watts on standby).
        5. USB power on standby.
        6. Thunderbolt belkin on standby when not in use.
        7. USB External HDs???
    3. DIY 8 plug power bar, timer on/off control.
      1. TV
      2. Set top box
      3. blue-ray player
      4. PS4/XBOX etc…
      5. …

     

  • rsync target permissions and ownership

    Add these flags, to set the target permissions, and ownership
    –chmod=a+rwx,g+rwx,o-wx
    –chown=OWNER:GROUP
    the chmod is 774.
     
     

  • Excel date to unix time integer or unix time to excel date.

    FROM unix to excel date.
    [plain]=CELL/(60*60*24)+"1/1/1970"[/plain]
    From excel date to unix time.
    [text]=(CELL-"1970-01-01")*60*60*24[/text]
     
    where “CELL” is your excel cell you’re trying to handle.
    CELL can also be replaced with the NOW() function.
     

  • [fixed] raspbian / debian apt-get connect (101: Network is unreachable)

    Are you having issues
    When I ran:
    $> sudo apt-get install mosh
    Reading package lists… Done
    Building dependency tree
    Reading state information… Done
    The following extra packages will be installed:
    libio-pty-perl libprotobuf7 libutempter0
    The following NEW packages will be installed:
    libio-pty-perl libprotobuf7 libutempter0 mosh
    0 upgraded, 4 newly installed, 0 to remove and 1 not upgraded.
    Need to get 767 kB of archives.
    After this operation, 2,190 kB of additional disk space will be used.
    Do you want to continue [Y/n]?
    Err http://mirrordirector.raspbian.org/raspbian/ wheezy/main libio-pty-perl armhf 1:1.08-1
    Cannot initiate the connection to mirrordirector.raspbian.org:80 (5.153.225.207). – connect (101: Network is unreachable)
    ….
     
    To fix this error:
    $> sudo route add default gw 192.168.1.1
    This will add the default gateway to route… as the RPi can’t find it’s way out of the network.
     

  • xdebug.ini with phpstorm

    [Server xdebug.ini file]

    zend_extension=xdebug.so
xdebug.remote_enable=true
xdebug.remote_connect_back = On
xdebug.profiler_enable=1
xdebug.profiler_output_dir="/tmp"

    Zero config phpstorm xdebug mode will now work.
     
     
    [Ensure your router isn’t blocking xdebug]
    Port Trogger is turned on

    • Trigger port: 80/tcp
    • Incoming port 9000/tcp

    OR
    Set your local machine as the DMZ
    OR
    Port forwarding

  • Personal domain cname alias to ddns

    I know this will be giberish to most of my friends…
    if you have your own personal domain name; and decent router that supports ddns services, or a computer remains on most of the time, you could get something like:
    DOMAIN: privatelan.lloydleung.com to point to your home LAN, and no longer a need to remember your IP while away from your network.
    Say you wanted to connect to a device at home, and control it. You could now.
    How would you like to be able to connect to your home network like: http://home.yourpersonaldomain.com and log into your personal webserver. Want another protocol instead of http, sure no problem.

    1. Sign up with a ddns service your router supports. Or if your technically savvy run a deamon/cronjob yourself.
    2. Set a cname on your dns that points to a ddns.
      • if you don’t have access to your dns, contact your administrator, and they should be able to help you out on this.
    3. Setup on your computer or router update the ddns on the regular basis.
      • I have a raspberry pi, which runs a cron job every 5 minutes, to connect and update my ddns provider.
    4. Create the port forwarding to the devices you want to go use.
      • Such as HTTP, that would be port 80. The incoming port would be port 80, and you would forward it to an internal IP, say 10.0.0.101, on port 80. Save and apply these changes.
      • When you connect to http://home.yourpersonaldomain.com it will now try and connect to your internal network machine that has the ip 10.0.0.101 on port 80.
    5. Magic.

    So as an example, If I had a cname alias was “personalnetwork.lloydleung.com”, the ddns client will update the ddns server. On my router, I’d need to port forward whatever the application I was trying to go use. Some popular applications to use for this purpose would be RDP (port 3389), VNC (port 5900), ssh (port 22). How to setup these applications is outside the scope of this entry, and google is your friend.

  • pidgin.im msn protocol alternative: msn-pecan [update #2]

    Okay,
    Been working with pidgin w/msn-pecan on ubuntu 10.04.  New problem, pecan doesn’t crash pidgin anymore, however I am logged out after I’ve been away from my computer a little bit.  As in, when the screen saver kicks in, pecan logs me out or can’t maintain a connection.
    Doesn’t seem to happen in windows 7.
    If I can live with this issue,  and so far I have… it’s kind of a nice flaw, as this allows me to be not distracted, while at work.

  • little project ideas

    Just found a need to access my home server… however, it’s powered down… how can I overcome this problem in the future.  To answer my own question…  I should go lookup how to send a wake-on-lan command to the box. As well as know what my IP is…
    project ideas:
    1.) Current IP notifier – send to my webserver, what my home server IP is. (Dynamic). I could use a dynamic dns service… this maybe interesting to learn how to do this, if I have my own VPS… have the home-server, notify the web-server to update the DNS setting. So I would have something like: homelan.lloydleung.com or whatever.
    2.) wake on lan commands.
    3.) vpn to the network instead… with a combo on 1. This way, everything is encrypted…