Hi, I just got my uConsole and I wanted to install Bookworm. I have Sandisk Extreme Plus card. I put it into my Macbook, do diskutil list to find disk number, then sudo dd if=/path/to/Bookworm-6.12.67.img.xz of=/dev/disk4 status=“progress” conv=“fsync”, When it finished I put microSD card to uConsole and push ON button, green LED flashes but screen is black. Same happens with Trixie, TwisterOS etc. All images I have from Rex. I also tried to use balenaEtcher but after verify stage there is an unexpected error says “check if image is correct”. What am I doing wrong?
I’m not sure bookworm was updated for the new screens so it might not work, Trixie should work though.
Since it also doesn’t work there’s something else going wrong. If you have a microhdmi cable you can plug that in to the uconsole and see the output on an external screen, that might have clues about what’s going wrong.
Which compute module are you using? Are the batteries charged? Have you tried reseating the compute module(module into adapter first, and then install both into mainboard)
you are doing everything right,
but:
- do you have lite version? sdcard doesnt work on emmc version
- do you have a cm5? you need to upgrade a eeprom, stock one doesn’t work with every sdcard
1 Like
@snipeytje @white-round-square I have original CM4 Rev 1.1, the one that comes in package. Original SD card still works fine when I put it into uConsole. Batteries are charged.
What do you mean by light version? Like Trixie Light? I also checked it and the same black screen. Same for ClockworkPi_Images - Google Drive .
Here is error from balenaEtcher
lite compute module, means no emmc, since you have the supplied 4gb lite cm4 that’s not a problem
I think I just realized the issue, with dd you do have to uncompress the image before flashing it afaik
2 Likes
@snipeytje Jesus, you are right 
Thanks a lot!
I think the UNIX dd(1) and pipe(2) interfaces are a bit daunting to beginners, and that linked StackOverflow post does a bad job of explaining what its examples actually do, so I’m going to list a lot of equivalent examples, with the goal being writing the uncompressed file.img.xz (a file representing some sort of useful data) to /dev/mmcblk0 (typically an SD card) as root.
# traditional example
xz -d file.img.xz # decompress file.img in-place
sudo dd if=file.img of=/dev/mmcblk0
# ^^ ^^ ^^ ^^ output file
# | | '- input file
# | '- use dd(1) to move file contents
# '- use sudo to escalate to root
# improvement on tradition
xz -d file.img.xz
sudo dd bs=4M if=file.img of=/dev/mmcblk0
# ^^ adjust the "block size";
# a certain amount of information is moved per program step
# and the default, 512 bytes (or 1K in GNU), is very small and
# was more relevant in the 1970s when dd(1) was written
# -- THIS IS USUALLY A 2x SPEEDUP OR BETTER!
# use stdin/stdout
xz -cd <file.img.xz >file.img
# ^^ '<' is input, '>' is output, but both use stdin/stdout
# rather opening files. technically this can be immeasurably
# faster, but the usual advantage is not having to deal with
# 500 ways to write -i --input --input-file= if=
# (this -c means use std interfaces and is inherited from gzip)
sudo dd bs=4M of=/dev/mmcblk0 <file.img
# ^^ dd is just a middleman, it copies data from one file to another
# (dd means "copy/convert", but cc was already the "C compiler",
# so as a joke it became dd instead. its weird if= of= thing is
# also a joke; dd was a command in IBM's JCL, so the syntax too
# was stolen)
# "shell file redirection" (the technical term for </>) only uses
# those files with your regular user permissions though, whereas
# dd has root permissions (by using it with sudo) and so can write
# to /dev/mmcblk0
# use pipes
xz -cd <file.img.xz \
| sudo dd bs=4M of=/dev/mmcblk0
# <file.img >file.img is redundant. rather than an intermediate file, use
# a UNIX pipe to plug xz's stdout directly into dd's stdin
I could go on about what those “standard interfaces” actually are but my goal is just to explain some slight improvements to people’s workflows. All this is to say xz -cd <file.img.xz | sudo dd bs=4M of=/dev/mmcblk0 is just about the fastest and most efficient way to invoke dd(1) to do this. There are some simpler ways but returns diminish quite a bit past this point.
In your particular case, dd(1) succeeded in writing the compressed data directly to the drive, so it reported no error. BalenaEtcher however verifies that a drive image is actually a drive image (i.e. by verifying the existence of a partition table) and notified you in the vaguest possible terms that your data scared it.
As a bonus, < and > are features of the shell, not part of the program, so you can also arrange it as <file.img.xz xz -cd | dd bs=4M of=/dev/mmcblk0, which I think does a good job of demonstrating the flow of data (file.img.xz → xz(1) → dd(1) → /dev/mmcblk0). Composition of existing programs is one of the defining features of UNIX itself.
1 Like