Uploading an image from partition layout: /dev/mmcblk0
-
I hate asking, but can you get to a terminal prompt within clonezilla and get the contents of the information?
[code]lsusb[/code]
I’m under suspicion the FOG issues is likely related to the fact that eMMC is typically what’s kind of found in USB Flash sticks.
As I don’t have any drivers included in the kernel to support USB Disks (hence being able to keep a USB hdd connected without overwriting the wrong drive) I think this is where our problem lies.
-
Yep, give me just a bit and I’ll do that.
In the meantime, here are my disk reports from when I’ve captured an image with Clonezilla.
[url=“/_imported_xf_attachments/1/1422_mmcblk0.zip?:”]mmcblk0.zip[/url]
-
Okay
I am building mmc support into the kernel. I did a lot of research and hopefully the new kernels will, at the least, recognize the disk. -
[FONT=Consolas]lsusb[/FONT]
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 154b:0053 PNY (Flash drive used to load Clonezilla into my RAM)
Bus 001 Device 003: ID 0b05:17e0 ASUSTek Computer, Inc.
Bus 001 Device 002: ID 0b05:17e4 ASUSTek Computer, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub -
Awesome, thank you! I will test it once you’ve made it.
Also, it looks like I forgot to mention that these are 32-bit devices.
-
Kernels are ready:
[url]https://mastacontrola.com/fogboot/kernel/bzImage[/url] (64bit)
[url]https://mastacontorla.com/fogboot/kernel/bzImage32[/url] (32bit)I don’t know if it will work properly, but can you boot the system and see if it at least can recognize the disks now?
-
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}?
