Uploading an image from partition layout: /dev/mmcblk0

[d4rk3]

Same error, only saying “clone: open /dev/mmcblk error” instead.

I tried a bunch of kernel arguments yesterday…to no avail.

Do you think using Partclone v0.2.73 would help at all?

[Tom Elliott]

I don’t think it’s the partclone having the issue, rather it’s the kernel not recognizing the disk.

You stated in debug, when you fdisk -l you show no disks?

[d4rk3]

I figured the kernel was probably the main issue here.

And you are correct with running fdisk -l. Even after using your new kernel as well, unfortunately.

[d4rk3]

I was able to clone partition 1 (mmcblk0p1) successfully, but beyond that it fails to recognize the remaining partitions.

I was only able to clone p1 by running Debug, creating /images, mounting it on my FOG server and running partclone.dd manually.

[d4rk3]

Update: making a custom init_32.xz with Buildroot, I’ll report back if I get these uploading!

[d4rk3]

And if anyone has any knowledge to shed, please, feel free to chime in

[Tom Elliott]

The knowledge I have has been passed. It sounds like we “have” all the stuff you need in place. Now if only I could get it to recognize the mmcblk as /dev/sd{x}?

[d4rk3]

We’ll get it eventually. I wanna thank you again for all of your help, Tom.

[d4rk3]

After more research, the problem lies within the Replay Protected Memory Block (/dev/mmcblk0rpmb). Now I just need to figure out what needs to be added to the kernel to fix this.

Some info/patch here: [url]https://dev-nell.com/rpmb-emmc-errors-under-linux.html[/url]

[d4rk3]

Bump!

[Tom Elliott]

[quote=“d4rk3, post: 38039, member: 23583”]After more research, the problem lies within the Replay Protected Memory Block (/dev/mmcblk0rpmb). Now I just need to figure out what needs to be added to the kernel to fix this.

Some info/patch here: [url]https://dev-nell.com/rpmb-emmc-errors-under-linux.html[/url][/quote]

Are you seeing the same errors as specified in this patch?

I’m going to attempt building a kernel with the supplied patch, but there’s no guarantee this is going to fix your particular issue.

FOG Defaults to search for /dev/sd{a-z} or /dev/hd{a-z}.

It does not search out mmcblk devices.

[Tom Elliott]

I created 3.17.1 kernels with the patch in the link you provided above.

The kernels can be found at:
[code]http://mastacontrola.com/bzImage?64bit=1
http://mastacontrola.com/bzImage32?32bit=1[/code]

[d4rk3]

Thanks so much, Tom! I’ll get back to you once I test the new kernel.

[d4rk3]

No dice

[d4rk3]

Bump because I have nothing to lose

[Tom Elliott]

Have you tried with the latest svn?

I’m attempting to not assume device letters and such and hoping that this may help.

[d4rk3]

Update:

I’m on SVN 3504 and just deployed a debug task to see if fdisk would show anything this time around…and it does!

The problem is, the screen fills up and I can only see the last disks which are all /dev/ram*.

How can I slow down the list or scroll up?

[Tom Elliott]

fdisk -l | more

[d4rk3]

@Tom-Elliott said:

fdisk -l | more

Thanks Tom

Every disk looks like this (/dev/ram0 - /dev/ram15)

Kind of disappointing because the mmcblk0rpmb is still blocking me from seeing the mmc partitions.

If anyone has any ideas I’m all ears

[d4rk3]

Side note…I set the primary disk to /dev/ram0 with a raw DD image and it uploaded lol…