Boot hangup while loading ntspec.service

Before performing extended online research, please do not hesitate to ask even questions that you fear might be too simple to ask. Chances are, that I can help you quickly. This is how you would’ve applied the patch, assuming you copy it into a file called “mybmap.patch”:

sudo env --chdir /usr patch -p1 < mybmap.patch

But you do not need to do that because you already have a copy of reform-flash-rescie where you have made the edit manually. The file in /usr/bin/ is “read-only” because it’s only supposed to be changed by the superuser (aka the root user). That’s why you need to run above command with “sudo”: xkcd: Sandwich

So yes, you should be able to run this, assuming that you are in the directory where reform-flash-rescue2 is in:

sudo sh reform-flash-rescue2
1 Like

Here’s what happened:

bmaptool: info: no bmap given, copy entire image to ‘/dev/mmcblk2’

bmaptool: info: synchronizing ‘/dev/mmcblk2’
bmaptool: info copying time 4m 42.0s, copying speed 4.6 MiB/sec
Error: /dev/mmcblk2: unrecognized disk label

I tried booting the device without the SD card, and the screen is simply blank. None of the startup services show up. The keyboard is lit and the OLED screen turns on, but it’s still stalled.

Perhaps I need to just wait for my RK3588 to ship? Sure hope I didn’t brick the module.

Thanks again for your help.

Huh… Okay, I think I will have to run the script myself. I can do this on my imx8mq classic Reform and I hope I run into the the same issue as you did, so that I can fix it.

I don’t think your module is bricked. This can only happen if you should flash a broken u-boot to eMMC. If you put a fresh sd-card with a rescue system in, that system should boot just fine.

I’ll write here again once I have some results. Sorry for the mess. Apparently nobody has run this script for a while and bugs have crept in… :frowning:

I really appreciate your effort with all of this. It really puts into perspective how much work goes into programming things like computers and phones we take for granted!

I appreciate that you stick around to help me find these issues. While I wrote these tools, I’m rarely ever using them and thus I do not encounter these problems. The problem you are facing is a fundamental one and hints that reform-flash-rescue has never been used by anybody. It is fundamentally broken because after bmaptool finishes, the following is on the device:

root@reform:~# head -c 100 /dev/mmcblk0 | xxd
00000000: 1f8b 0808 a208 9767 0003 7265 666f 726d  .......g..reform
00000010: 2d73 7973 7465 6d2d 696d 7838 6d71 2e69  -system-imx8mq.i
00000020: 6d67 00ec bc0b 5453 57da 307c 4e72 1202  mg....TSW.0|Nr..
00000030: 3908 419a aa01 0d91 78b7 8d60 eba5 b626  9.A.....x..`...&
00000040: 4823 17ed 0023 a8ad ed0b d450 b4d3 0e3a  H#...#.....P...:
00000050: 61bc 5425 c416 a332 9d10 7b01 6b67 4ed2  a.T%...2..{.kgN.
00000060: c642 6a66                                .Bjf

That’s… a gzip signature… Lets quickly check the first 100 byte of the system image:

root@reform:~# curl --location --silent https://source.mnt.re/reform/reform-system-image/-/jobs/artifacts/main/raw/reform-system-imx8mq.img.gz?job=build | head -c 100 | xxd
00000000: 1f8b 0808 a208 9767 0003 7265 666f 726d  .......g..reform
00000010: 2d73 7973 7465 6d2d 696d 7838 6d71 2e69  -system-imx8mq.i
00000020: 6d67 00ec bc0b 5453 57da 307c 4e72 1202  mg....TSW.0|Nr..
00000030: 3908 419a aa01 0d91 78b7 8d60 eba5 b626  9.A.....x..`...&
00000040: 4823 17ed 0023 a8ad ed0b d450 b4d3 0e3a  H#...#.....P...:
00000050: 61bc 5425 c416 a332 9d10 7b01 6b67 4ed2  a.T%...2..{.kgN.
00000060: c642 6a66                                .Bjf

So bmaptool wrote the compressed image to the device. It didn’t uncompress it. This is why parted later fails. It can naturally not see any partition table on the device.

To fix this, we have to fix bmaptool. The fundamental problem is, that gitlab CI appends the query part ?job=build to the end of the URL. This means, that bmaptool does not find an extension like .gz at the end and thus does not decompress the image. We have to teach bmaptool to strip off the query part when checking for the filename extension. I prepared this pull request to do exactly that:

It will take some time until this pull request was accepted by upstream and it will take even longer for a release to be made and that then getting added to Debian. To avoid having to wait that long, we can patch the bmapt-tools package in the mntre.com repository. So I backported my patch for upstream here:

I set this to auto-merge, so if everything goes right, this will be in the repos in ~1.5 hours.

This will btw also conveniently fix the problem which made you add --nobmap. With those changes above, you do not need to add this anymore because bmaptool will try to find a bmap file behind the URL ending in .gz.bmap?job=build instead of trying to access a url ending in .gz?job=build.bmap which is what happened before…

Thanks!

2 Likes

Seems like a really great catch on your part. Again, I really appreciate all your effort with this.

Is the patch you made something I need to download, or is this part of the process that the rescue script sets up over the internet connection?

Thanks again!

The one who found this is really you. So thank you for that. :slight_smile:

The patched bmap-tools package is no in the mntre.com repos. You have two options:

  1. download a new system image, flash it to sd-card, connect to the internet and run reform-flash-rescue again

  2. boot into your existing sd-card, connect to the internet and run:

    sudo apt update
    sudo apt install bmap-tools
    

In any case, you don’t need to patch anything and you do not need to run your custom reform-flash-rescue2 script.

If you find more issue, I’m here to fix them. Thank you! :heart:

3 Likes

Good news! It worked!

Thanks again for your help. I may have identified the problem, but you solved it.

It’s great to know there’s a straightforward way to reset these now.

2 Likes