I am having a problem permanently copying the openWRT image from USB drive to mmcblk0 (the last step in the tutorial), it says no space left on device. I factory reset the device but no help.
#root@OpenWrt:~# dd if=/dev/zero bs=512 seek=7634911 of=/dev/mmcblk0* count=33
33+0 records in
33+0 records out
#root@OpenWrt:~# dd if=/dev/sda of=/dev/mmcblk0 bs=1M*
dd: error writing '/dev/mmcblk0': No space left on device
3729+0 records in
3728+0 records out
The only thing I can think off is that I flashed the openwrt image on the thumbdrive using the onHub recovery utility. Is there another way to flash the openwrt image?
@bnorris, have you encountered anything like this?
I think the dd: error writing '/dev/mmcblk0': No space left on device message is to be expected if your USB drive is larger than mmcblk0 since the dd command is copying from device to device and not sourcing from an image file or limiting the block count etc. Maybe the copy to mmcblk0 is good and you can reboot into OpenWrt now. Try it if you haven't yet.
I suspect the OpenWrt image on your flash drive is likely good since the Google WIFI device booted from it.
An answer to your question: The only thing I can think off is that I flashed the openwrt image on the thumbdrive using the onHub recovery utility. Is there another way to flash the openwrt image? is to use the dd command to write an .img file to your thumbdrive if you are using macOS/linux/unix. There are graphical apps like balena etcher https://www.balena.io/etcher/ available for mac/windows/linux.
I'm not a seasoned user of OpenWrt and have zero experience with the the Google WIFI device so if my info doesn't help, I hope others offer better info.
I think you are right, since the dd command is copying from device to device and not sourcing from an image file or limiting the block count etc. It also indicates that records were transferred. I tried the image burn using the balena etcher and similar result.
The problem is that when I power cycle, it goes into flash mode (purple blinking). However, when I flash the stock firmware, it doesnt do that. Just power cycles normally.
I dont the exact size of mmcblk0, but I think this device has an mmc of 4GB. The image file on the USB comes into two partitions, one is 16MB and the other is 104MB, the rest is unallocated.
I'll add a couple more thoughts for clarity and items useful to those of us new to OpenWrt installation. Sorry if this info is well known to you already.
Checking that you are working with the Google WIFI model with OpenWrt software available. Manufacturers sometimes make multiple models and the hardware, firmware, filesystem layout can differ so a specific OpenWrt image is needed for each variant. It looks like the OpenWrt images (.bin files) are only for the original Google WIFI device from 2016 and does not include any newer models or Google Nest WIFI models.
Checking that you are using the correct image file.
There are three images on the download page https://downloads.openwrt.org/snapshots/targets/ipq40xx/chromium/
The openwrt...factory.bin file is specified on the device page and common for flash based devices. https://downloads.openwrt.org/snapshots/targets/ipq40xx/chromium/openwrt-ipq40xx-chromium-google_wifi-squashfs-factory.bin
When copying the .bin file to the USB drive on your PC be sure to copy the bin file as the source and don't open the .bin file and copy the contents to the USB drive.
If the above looks like what you did/used then try going through the steps again including the reset to Google factory software/defaults part and verify that the device is actually running the Google factory default software before continuing with the installation of the OpenWrt factory.bin software.
Watching the boot process via a serial console can be very helpful so you could look at doing that. Some instructions are further down on the device page. https://openwrt.org/toh/google/wifi#serial
Perhaps you know that the device is in flash mode with the purple blinking LED but I thought it good to mention that the LED behavior sometimes changes when switching from the vendor software to OpenWrt. For other devices I researched, the OpenWrt image includes some modification to firmware files and boot parameter files etc and the LEDs work differently once the bootloader process begins. This may be true for this device but the purple blinking may also be indicating a failure to find a bootable image or something else.
The first boot can take longer than subsequent boots so waiting several minutes and then trying to connect via ssh on the correct ethernet port might show it running. I didn't see any info on this for this device but I think it is typically a port that winds up being the lan or br-lan with IP 192.168.1.1
Luci is not included on snapshot images so ssh or serial console are your only options until you install luci via cli.
I hope you figure this out and get it working. Good Luck!
@spence has it right. The "No space left" message is expected in this case.
Honestly, this part of the instructions was a tough part to get quite right and could probably use some love for making it easier. There are too many things to get wrong. (Wondering out loud: is there any recommended way to make an "installer"? Like, a hook or tool that will do the dd commands for you, to flash to the eMMC? It would be nice to not rely on just copying the entire USB stick, and instead do a faster, more-targeted copy that's based on the filesystem and partition size. But that's hard to make into a short "How To Install" copy/paste script.)
But anyway, given you are running the right commands, I wonder why reboot doesn't get you into a working image.
A few notes/questions:
How long did you wait after reboot? The purple flashing is for "developer mode", and it usually has some built-in delay in the bootloader, to wait for some kind of confirmation or to let you boot alternate modes (like boot-from-USB). So you may have to wait around 30 seconds for it to continue. (There are ways to skip that delay, but that would complicate things right now.)
Did you leave the USB stick plugged in when you reboot? It's probably best if you remove it.
One semi-bug related to #2: because the GPT partition UUIDs will be the same for the eMMC and your USB stick, it's probably best to remove the USB stick. The boot process uses UUIDs for locating partitions, so it's not ideal if those "unique" IDs are no longer unique... This goes to my earlier wondering too -- it would be nice if I could write an installer that would generate new IDs, so they have a better chance of actually being unique.
I don't have any more obvious ideas yet. I hope we don't have to resort to serial debugging to figure out what's wrong; since you managed to boot OpenWrt via USB, things should be working well enough for boot-from-eMMC.
Thanks Bnorris! The instructions were a bit difficult at first but I got the hang of it somewhat quickly. I was most confused on how to flash openWRT to the thumbdrive, honestly.
I rebooted about a minute after the last SSH command completed. I removed the USB before powering back on. When rebooted, the light turns sold light blue for 2 seconds, flashes purple for 30 seconds, solid blue , the finally turns flashing amber (not orange or yellow) which goes on forever. And sadly, no IP address or SSH from OpenWRT
Weirdly, if I plug in the USB while its flashing amber, it goes flashing yellow/amber alternating. Not sure what that means. Unfortunately, I don't have means to do serial port diagnosis.
The description of your color sequence sounds like the device didn't like something about what got flashed to disk (e.g., kernel corruption, or bad GPT) and is in "recovery" mode. Maybe it's worthwhile linking or documenting the bootloader LED patterns, to assist in troubleshooting.
Anyway, that note plus the "difficulty flashing the thumdrive" reminds me that I totally omitted documenting how to get to step 7 ("USB stick containing OpenWrt"). That actually might be pretty important, because some tools will adjust the GPT table during this step, and that new table won't actually work when installed to the eMMC. In particular, if your USB disk is larger than the eMMC, you'll end up writing a GPT table to the eMMC that is larger than the eMMC itself, and the bootloader doesn't like that. I really intended the instructions to mean that you write the image verbatim to USB, with no intermediate adjustments. (Again, maybe I need some better automated installer to get these things right...)
Can you try one or more of these?
write the image using dd to write the USB stick, like @spence suggested back in their first comment? I can't spell you out a specific command, because that depends on the particular naming of your USB stick. But it would look something like, dd if=openwrt-ipq40xx-chromium-google_wifi-squashfs-factory.bin of=/dev/sdb bs=1M (be extra careful about whether /dev/sdb points at your USB stick!!!).
give me the fdisk dump of what your partitions end up looking like, either after using balena or onhub recovery or whatever? That would look something like: fdisk -l /dev/sdb (same caveats about /dev/sdb)
I might also give balena etcher a try sometime, to see whether it does what I'm guessing it does.
Hmm, I just retried the Onhub Recovery Utility, and it looks like it does a faithful copy without modifying the GPT table. So that's probably not the problem exactly. You could still try option 2, just in case somehow your disk doesn't end up looking right.
One other random guess: I think I got the order of the commands backward in step 10; the "Clobber secondary GPT" part should probably come second. Otherwise, you might copy some arbitrary garbage from your existing USB stick onto the eMMC, and if that looks like a GPT table, it again might confuse the bootloader.
So that would be:
## Copy USB image directly to eMMC
dd if=/dev/sda of=/dev/mmcblk0 bs=1M
## Clobber secondary GPT at end of eMMC
dd if=/dev/zero bs=512 seek=7634911 of=/dev/mmcblk0 count=33
Sorry for so much trial-and-error here; it's easier if I have serial access to debug with less guessing
Thank you bnorris, unfortunately it didn't work when the order of commands was reversed. I am doing this from windows so I am not sure whether that would have an effect on partitions. In all cases, I will try different flash drives, hopefully, that helps. Sorry for not doing serial diagnosis which has lead to all the guess work.
I'm having the same issue. I don't know if it makes a difference but I used Rufus to make my USB stick and it was located at /dev/sdc. I think the /dev/sdc is because of the hub I'm using. If it helps diagnose this I also had a /dev/sdc1 and a /dev/sdc2. I don't have a debug cable but I can run any commands you need me to when booted into OpenWRT from the USB drive.
Any help is greatly appreciated. I'd like to breath some new life into these pucks.
There is probably a better way of doing this but I finally got it to work. Once I was booted into OpenWRT on the USB drive I used SCP to copy the factory.bin file from my workstation to the USB drive then I used dd to write the .bin file to the flash. I'm on a windows box so I used pscp.exe to get the file to the USB drive. .\pscp.exe -scp .\openwrt-ipq40xx-chromium-google_wifi-squashfs-factory.bin root@192.168.1.1:/
then when connected over SSH I ran dd if=/openwrt-ipq40xx-chromium-google_wifi-squashfs-factory.bin of=/dev/mmcblk0
followed by dd if=/dev/zero bs=512 seek=7634911 of=/dev/mmcblk0 count=33
then I rebooted.
Hey, thanks for the work there. That's very interesting, that dd-ing the original image works, but dd-ing your USB stick doesn't. Your process is exactly what I would recommend actually, but I was trying to keep things simple. Maybe I do need to work on getting the USB image to embed an installer/payload to do this automagically, so we're not dependent on the exact properties of your USB stick, or of the tool used to write to it. Or I guess in the meantime, maybe I'll just update the Wiki instructions to suggest scp-ing the unmodified binary over.
Also, I may be a bit out of touch here, but I'm surprised how many Windows users we've got here
How long should the second DD command take to write the image? I enter it and it sits there like it's doing something in the background but I've let it sit for 8-9 minutes with nothing else happening. I didn't think the image was that large. It boots from the USB no problem but just seems like it doesn't want to write. Or at least it seems like it isn't.
