kernel panic when cloning a BBB using


Been trying to clone a debian 8.4 running kernel 4.1.x using the RC Nelson script

I have ensured that I have the latest script (git pull when in /opt/scripts/tools)
I have ensured the BBB I am cloning has a network connection during the process.

When I insert he new uSD card into a new BBB to flash it it ends quickly with a kernel panic.

Here is the serial debug output:

Starting eMMC Flasher from microSD media
Version: [1.20160718: mkfs.ext4 1.43…]

The line I’ve highlighed in yellow seams to be the problem.
Why is the cloning script getting a bootloader in here?

Any help much appreciated!

What do you mean “why?” ? Short answer is that a bootloader( actually two - first and second stage ) is required to boot from eMMC.

dd if= of=/dev/mmcblk1 count=1 seek=1 bs=128k is in reference to MLO I believe. uboot.img is roughly 348k as I recall.

I mean why isn’t the boot loader getting on the uSD I’ve created using the script? I know why it needs to be there…

How do I solve this such that I can slam the created uSD into a new BBB and have flash eMMC?

dd: failed to open ‘’: No such file or directory[ 35.897114] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100

That’s why. It can’t find a file or directory. And here is why:

dd if= of=/dev/mmcblk1 count=1 seek=1 bs=128k

See the problem ? Where’s the input file ? " " ?

But isn’t the script – – supposed do do that?

Do I need to manually add this in? Sorry noob here I don’t understand. I see the problem. But I don’t know how to solve it, hence asking for help :slight_smile:

I know nothing of Robert’s eMMC flasher script. I would probably never use it. But thus far have not used it. However, the reason why dd error’d out is as I said in my last post. It needs an input file in order to work.

Here: is the basic rundown of what has to happen in order to create a working sdcard. The concept should be nearly if not exactly the same for the eMMC with the exception of targeting a different block device. The eMMC, instead of sdcard.

OK could could you reccomend another way to accomplish my objective that does work?

Thanks for your input!

Same method you’re using, but if= needs to point to a suitable MLO file. That is: I’m guessing based on the count and bs of that particular dd line. I only say I would probably never use Robert’s script to do this as I do not know what he script does, and I am very particular in how my beaglebones are setup. SO instead of reading through his script, I would write my own script. Since I know what needs being done.

As to other methods I’d use. Well technically I’ve never written to an eMMC yet. Others here probably have more hands on than I in regards to the eMMC. However, as I mention above. I know what needs doing, and how to do it. Which is something really too complex to just tell someone without experience how to do. Unless I’ve tested it first. Which won’t happen any time soon.

So we’re back to square 1.

One thing that does come to mind that you can try. Would be to get one of the latest Jessie flasher images. Then flash that to eMMC. Afterwords, wipe the rootfs, create a tar backup of the rootfs you want on the eMMC, then tar that over to the eMMC. But as a Linux newb that might be easier said than done.

Perhaps I’ll experiment with that sometime this evening if I find the time.

I am noob+ so I’ll give’r it a whirl :slight_smile:

Ok, so once you have a working eMMC. You’ll probably want to make the partition as small as possible, while still being big enough for the rootfs. Then dd backyp the entire eMMC block device. That way, when you dd back to replicate, it’ll take less time. Then, if you need, or want to resize the rootfs partition. You do that afterwards. It should make the whole process much quicker. Instead of copying over needed data, and then filling the rest of the eMMC with zero’s through dd . . .

I think I will experiment with this in a bit. What I’ll do is grab one of the latest Jessie flasher images. Flash it to eMMC, and then replace the rootfs with an older Wheezy rootfs. I do not have any of this ready, so setup will take me a while. Which will include backing up the eMMC as it sits( factory image ).

Got some other things to do first though. . .

Still toying around. Ran into a couple things I did not expect, but nothing show stopping yet. The biggest thing on my mind immediately was knowing that Robert was using an UUID for the root mount of the eMMC. Which turned out to be a non issue so far.

I had considered backing up the eMMC as it is now - WIth Debian Jessie on it and one single partition. But I do not like what all is running on this image, and I’m not 100% how to deal with the things I’m not liking. So . . . I think I’ll skip that.

Now, time to boot back into the development image, and see what hackery I can engage . . .

Rough exact steps . . .

On X86 development machine:
william@eee-pc:~$ cd backup/
william@eee-pc:~/backup$ wget

william@eee-pc:~/backup$ lsblk
sda 8:0 0 149.1G 0 disk
├─sda1 8:1 0 9.3G 0 part /
├─sda2 8:2 0 1K 0 part
├─sda5 8:5 0 2G 0 part [SWAP]
└─sda6 8:6 0 137.8G 0 part /home
sdb 8:16 1 29.8G 0 disk
└─sdb1 8:17 1 29.8G 0 part

william@eee-pc:~/backup$ xzcat BBB-blank-debian-8.5-console-armhf-2016-06-19-2gb.img.xz | sudo dd of=/dev/sdb
3481600+0 records in
3481600+0 records out
1782579200 bytes (1.8 GB) copied, 500.677 s, 3.6 MB/s

On Beaglebone:

Backup eMMC:
william@beaglebone:~$ lsblk
mmcblk1boot0 179:16 0 2M 1 disk
mmcblk1boot1 179:24 0 2M 1 disk
mmcblk0 179:0 0 14.7G 0 disk
`-mmcblk0p1 179:1 0 1.7G 0 part /
mmcblk1 179:8 0 3.6G 0 disk

-mmcblk1p1 179:9 0 96M 0 part
`-mmcblk1p2 179:10 0 3.5G 0 part

william@beaglebone:~$ ls
am33xx-pruss-uio.dts dev temp

william@beaglebone:~$ cd dev/
william@beaglebone:~/dev$ ls
C beaglebone_cleanup bonejs dtb-4.4-ti dtb-single javascript misc test-dts

william@beaglebone:~/dev$ mkdir backup-emmc
william@beaglebone:~/dev$ cd backup-emmc/

This is an NFS share, so will take a while.
william@beaglebone:~/dev/backup-emmc$ time sudo dd if=/dev/mmcblk1 of=./2016-07-27-emmc_backup.img bs=1M
[sudo] password for william:
3688+0 records in
3688+0 records out
3867148288 bytes (3.9 GB) copied, 451.522 s, 8.6 MB/s

real 7m36.950s
user 0m0.252s
sys 1m5.144s

william@beaglebone:~/dev/backup-emmc$ sudo halt

At this point remove the sdcard from the x86 dev machine, and place into the Beaglebone. Then toggle the power button.
If you have a serial debug cable connected to the beaglebone, you can watch the progress of the flasher. This should
finish very quickly. Once the LEDs all go solid, the board is in the process of shutting down. Let all LEDs go off, and
stay off before removing the sdcard and attempting to boot from eMMC.

Once booted from eMMC on the Beaglebone you can login via the serial debug terminal. Or you can login via ssh.

debian@beaglebone:~$ lsblk
mmcblk0boot0 179:8 0 2M 1 disk
mmcblk0boot1 179:16 0 2M 1 disk
mmcblk0 179:0 0 3.6G 0 disk
`-mmcblk0p1 179:1 0 3.6G 0 part /

debian@beaglebone:~$ uname -r

debian@beaglebone:~$ cat /etc/dogtag Debian Image 2016-06-19

Knowing the contents pf /etc/fstab will be helpful at this point. Although I plan on mounting the eMMC as device name
not by UUID. So I may as well double check that this will work by changing it now.

debian@beaglebone:~$ cat /etc/fstab

/etc/fstab: static file system information.

By the way . . .

debian@beaglebone:~$ cat /uEnv.txt| grep optargs
mmcargs=setenv bootargs console=tty0 console=${console} ${optargs} ${cape_disable} ${cape_enable} rootfstype=${mmcrootfstype} ${cmdline}

This line in the first stage uEnv.txt file contained root=/dev/mmcblk0p1 and was causing problems. So I removed this, and added root=/dev/mmcblk0p1 to the second stage uEnv.txt file

  • First stage uEnv.txt == /uEnv.txt
  • Second stage uRnv.txt file == /boot/uEnv.txt

Anyway, this is really not a procedure for any newb, unless that newb is very meticulous and persistent.

Hi there,

This has been solved by RC Nelson. If you encounter this bug simply git the latest version of by executing a git pull command while in /opt/scripts/tools

Thanks again RC!