Uploading an image from partition layout: /dev/mmcblk0
-
First off, sorry for my delayed response. I didn’t receive an email notification of a response to my thread.
The kernel panics, but, it then spits out two lines before locking up:
[B]VFS: Mounted root (ext2 filesystem) on device 1:0.[/B]
[B]devtmpfs: mounted[/B] -
Getting closer! I’m gonna try various arguments and see if I can coax this any further.
-
What kernel did you try?
The bzImage32 should be the one you need and if you replaced your original bzImage32 with that, things should work.
-
I used the bzImage32. I was able to launch a debug task by setting argument /dev/mmcblk. Still can’t see anything with fdisk, gdisk, etc.
Gonna continue trying…
-
Good news: I was able to hit the PartClone screen while trying to upload! I just had to set the primary disk to /dev/mmcblk0.
It then threw an error about not being able to open /dev/mmcblk0 and reboots, but that’s ok because I’m so close now! It seems I just need to find the right disk/argument and these will be FOG compatible
-
Tom, if you or anyone knows where I should go from here I’d appreciate it!
[url=“/_imported_xf_attachments/1/1427_Partclone Error.jpg?:”]Partclone Error.jpg[/url]
-
Can you remove the 0?
mmcblk should find mmcblk1 or mmcblk2 as needed.
-
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?
-
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?
-
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.
-
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.
-
Update: making a custom init_32.xz with Buildroot, I’ll report back if I get these uploading!
-
And if anyone has any knowledge to shed, please, feel free to chime in
-
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}?
-
We’ll get it eventually. I wanna thank you again for all of your help, Tom.
-
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]
-
Bump!
-
[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.
-
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] -
Thanks so much, Tom! I’ll get back to you once I test the new kernel.
