Uploading an image from partition layout: /dev/mmcblk0

[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…

[Wayne Workman]

@d4rk3 I’m thinking that the correct one will not be any of the “ram” ones.

You’ve tried these?
/dev/mmcblk0
/dev/loop0

[d4rk3]

@Wayne-Workman said:

@d4rk3 I’m thinking that the correct one will not be any of the “ram” ones.

You’ve tried these?
/dev/mmcblk0
/dev/loop0

Unfortunately, yes. I’ve tried everything from my partition table on my OP.

However, fdisk actually being able to see anything is progress. Tomorrow I’ll try some different kernels, maybe I’ll luck out…