search

offensive-security / kali-arm-build-scripts

Kali Linux ARM build scripts
873 stars 373 forks source link

C2 Doesn't Boot After Resize Partition? #76

Closed jsl303 closed 6 years ago

jsl303 commented 8 years ago

Thank you for creating the Kali image for c2. I deleted the primary partition and recreated with the maximum size using fdisk. However, after that, c2 doesn't boot. That's the first thing I did after restoring the Kali image onto mmc. Thanks for help.

steev commented 8 years ago

I've seen that happen before as well, and unfortunately, I don't know the root cause.

If you have serial, and connect it, it seems to complain that the Image (which is the kernel file) or the uInitrd are corrupt; One way around that is to simply change to using the bottom booti line in the boot.ini file which just runs booti kerneladdr - dtbaddr (which means don't use the uInitrd);

Then once it's booted, you can mount /boot and then run /boot/mkuinitrd and it will recreate the uInitrd file and then change the boot.ini line back again. I've asked in #odroid on irc, but no one else has seemed to run into the issue, so not sure. I intend to look at the "odroid-utility" that mdrjr wrote https://github.com/mdrjr/odroid-utility but right now I'm trying to track down the issue with firefox crashing, which is a bit more important to me.

jsl303 commented 8 years ago

Thanks. I'll try the suggestion. Btw, Firefox crashes even with the official Odroid image, especially Youtube. ubuntu64-16.04lts-mate-odroid-c2-20160226.img

On 3/27/2016 3:01 AM, Steev Klimaszewski wrote:

I've seen that happen before as well, and unfortunately, I don't know the root cause.

If you have serial, and connect it, it seems to complain that the Image (which is the kernel file) or the uInitrd are corrupt; One way around that is to simply change to using the bottom booti line in the boot.ini file which just runs booti kerneladdr - dtbaddr (which means don't use the uInitrd);

Then once it's booted, you can mount /boot and then run /boot/mkuinitrd and it will recreate the uInitrd file and then change the boot.ini line back again. I've asked in #odroid on irc, but no one else has seemed to run into the issue, so not sure. I intend to look at the "odroid-utility" that mdrjr wrote https://github.com/mdrjr/odroid-utility but right now I'm trying to track down the issue with firefox crashing, which is a bit more important to me.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/offensive-security/kali-arm-build-scripts/issues/76#issuecomment-202002719

steev commented 8 years ago

That's why they install the 32bit Chromium on it to use in the official ubuntu image. Unfortunately, Debian's chromium package has issues on anything that isn't i386 or am64 currently, and I'm working on those as well. Hopefully this will be fixed soon, but for now, I use "links2 -g"

jsl303 commented 8 years ago

Any news on boot issue after partition resize?

steev commented 8 years ago

None at all. Upstream says they've never seen it, but there are others on their forums who say they've run into the issue, and I'm not sure how to begin tracking it down.

The easiest way, if you don't need the initramfs is to simply use the bottom line in the boot.ini file that doesn't enable the initramfs.

jsl303 commented 8 years ago

I'm not sure if this helps tracking it down. Anyways, .I have c1+ and c2., and both kali-2.1.2-odroidc.img kali-2.1.2-odroidc2.img have this problem. However, kali-2.1-odroidc.img doesn't have this problem. Any thought?

On 4/17/2016 9:35 PM, Steev Klimaszewski wrote:

None at all. Upstream says they've never seen it, but there are others on their forums who say they've run into the issue, and I'm not sure how to begin tracking it down.

The easiest way, if you don't need the initramfs is to simply use the bottom line in the boot.ini file that doesn't enable the initramfs.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/offensive-security/kali-arm-build-scripts/issues/76#issuecomment-211150049

jsl303 commented 8 years ago

Also, the bottom few lines of my boot.ini looks like:

If you're going to use an initrd, uncomment this line and comment out

the bottom line.

bootm 0x21000000 0x22000000 0x21800000"

bootm 0x21000000 - 0x21800000" How should I change?

Thanks for your help.

On 4/17/2016 10:02 PM, James Lee wrote:

I'm not sure if this helps tracking it down. Anyways, .I have c1+ and c2., and both kali-2.1.2-odroidc.img kali-2.1.2-odroidc2.img have this problem. However, kali-2.1-odroidc.img doesn't have this problem. Any thought?

On 4/17/2016 9:35 PM, Steev Klimaszewski wrote:

None at all. Upstream says they've never seen it, but there are others on their forums who say they've run into the issue, and I'm not sure how to begin tracking it down.

The easiest way, if you don't need the initramfs is to simply use the bottom line in the boot.ini file that doesn't enable the initramfs.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/offensive-security/kali-arm-build-scripts/issues/76#issuecomment-211150049

steev commented 8 years ago

As said, I don't. The difference between the 2.1 and 2.1.2 image is that the 2.1 image doesn't use the initrd.

Unless something in the initrd stores the partition "sizes" (which I don't see happening but I could be wrong!) I don't know what would cause it to claim the initrd is corrupt.

As a test, would you mind attempting to rebuild it after you resize the partition? There is a script in the boot partition to give you a bit of guidance for it; but it expects to be run from inside the native system, so you may need to qemu chroot in to do it.

jsl303 commented 8 years ago

I'm a newbie, so rebuilding would be probably way over my head. :)

Could you give me more direction on what I need to change in order to disable initrd? The few lines at the bottom of boot.ini looks like:

If you're going to use an initrd, uncomment this line and comment out

the bottom line.

bootm 0x21000000 0x22000000 0x21800000"

bootm 0x21000000 - 0x21800000"

What should I change them to? Thanks for your help.

On 4/17/2016 10:12 PM, Steev Klimaszewski wrote:

As said, I don't. The difference between the 2.1 and 2.1.2 image is that the 2.1 image doesn't use the initrd.

Unless something in the initrd stores the partition "sizes" (which I don't see happening but I could be wrong!) I don't know what would cause it to claim the initrd is corrupt.

As a test, would you mind attempting to rebuild it after you resize the partition? There is a script in the boot partition to give you a bit of guidance for it; but it expects to be run from inside the native system, so you may need to qemu chroot in to do it.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/offensive-security/kali-arm-build-scripts/issues/76#issuecomment-211154187

steev commented 8 years ago

The bottom line is already uncommented, so it's not using the initrd. Can you get serial output to see what exactly is happening? The comment in the section you pasted explains it already.

The issues tracker isn't really the place to go to get real time assistance, that would be the forums or the IRC channels, especially if you don't know what you're doing yet.

jsl303 commented 8 years ago

Unfortunately no serial output. Just posted a new topic on the Kali forum.

https://forums.kali.org/showthread.php?30731

Thanks again!

On 4/17/2016 10:20 PM, Steev Klimaszewski wrote:

The bottom line is already uncommented, so it's not using the initrd. Can you get serial output to see what exactly is happening? The comment in the section you pasted explains it already.

The issues tracker isn't really the place to go to get real time assistance, that would be the forums or the IRC channels, especially if you don't know what you're doing yet.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/offensive-security/kali-arm-build-scripts/issues/76#issuecomment-211156470

jsl303 commented 8 years ago

Actually, I got the serial output working! It gets stuck at the last line.

This is with c1+. Hope this helps.

On 4/17/2016 10:27 PM, James Lee wrote:

Unfortunately no serial output. Just posted a new topic on the Kali forum.

https://forums.kali.org/showthread.php?30731

Thanks again!

On 4/17/2016 10:20 PM, Steev Klimaszewski wrote:

The bottom line is already uncommented, so it's not using the initrd. Can you get serial output to see what exactly is happening? The comment in the section you pasted explains it already.

The issues tracker isn't really the place to go to get real time assistance, that would be the forums or the IRC channels, especially if you don't know what you're doing yet.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/offensive-security/kali-arm-build-scripts/issues/76#issuecomment-211156470

QA5:A;SVN:B72;POC:17F;STS:0;BOOT:0;INIT:0;READ:41;READ:41;READ:0;CHECK:0;PASS:0;

* Welcome to Hardkernel's ODROID-C... (Built at 19:33:00 Dec 8 2014) *

CPU : AMLogic S805 MEM : 1024MB (DDR3@792MHz) BID : HKC1310001 S/N : HKC11122F37DFE85 0x0000009f Loading U-boot...success.

U-boot-00000-ge6d5633-dirty(odroidc@odroidc-v2011.03) (Mar 17 2016 - 09:35:26)

I2C: clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=fffcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[25]=0 clear pinmux reg8[12]=0 clear pinmux reg1[3]=0 clear pinmux reg1[2]=0 set output en 0xc1108054[20]=1 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=fffcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[25]=0 clear pinmux reg8[12]=0 clear pinmux reg1[3]=0 clear pinmux reg1[2]=0 out reg=c1108058,value=fffcfa00 set output en 0xc1108054[20]=0 set output val 0xc1108058[20]=0 clear pinmux reg1[25]=0 clear pinmux reg8[12]=0 clear pinmux reg1[3]=0 clear pinmux reg1[2]=0 set output en 0xc1108054[20]=1 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=ffdcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=fffcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=ffdcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=fffcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=ffdcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=fffcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=ffdcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=fffcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=ffdcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=fffcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=ffdcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=fffcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=ffdcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=fffcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=ffdcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=fffcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=ffdcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=fffcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=ffdcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[25]=0 clear pinmux reg8[12]=0 clear pinmux reg1[3]=0 clear pinmux reg1[2]=0 out reg=c1108058,value=ffccfa00 set output en 0xc1108054[20]=0 set output val 0xc1108058[20]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=ffecfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[25]=0 clear pinmux reg8[12]=0 clear pinmux reg1[3]=0 clear pinmux reg1[2]=0 set output en 0xc1108054[20]=1 clear pinmux reg1[25]=0 clear pinmux reg8[12]=0 clear pinmux reg1[3]=0 clear pinmux reg1[2]=0 set output en 0xc1108054[20]=1 clear pinmux reg1[25]=0 clear pinmux reg8[12]=0 clear pinmux reg1[3]=0 clear pinmux reg1[2]=0 set output en 0xc1108054[20]=1 ready DRAM: 1 GiB relocation Offset is: 2ff1c000 MMC: eMMC: 0, SDCARD: 1 IR init is done! vpu clk_level = 3 set vpu clk: 182150000Hz, readback: 182150000Hz(0x701) mode = 6 vic = 4 set HDMI vic: 4 mode is: 6 viu chan = 1 config HPLL config HPLL done reconfig packet setting done MMC read: dev # 0, block # 33984, count 12288 ... 12288 blocks read: OK

There is no valid bmp file at the given address

Vendor: Man 450100 Snr 01108e30 Rev: 4.7 Prod: SDW32 Type: Removable Hard Disk

Capacity: 29820.0 MB = 29.1 GB (61071360 x 512)

Partition Start Sector Num Sectors Type 1 3072 261120 c

2 2048 1024 83

Net: Meson_Ethernet init suspend firmware done. (ret:0) Hit Enter key to stop autoboot -- : 0 exit abortboot: 0 reading boot.ini

3230 bytes read Loading boot.ini from mmc0:1 (vfat) Executing the script... setenv m "1080p" # 1080P@60Hz setenv vout_mode "hdmi" setenv m_bpp "32" setenv hpd "0" setenv cec "0" setenv disableuhs "disableuhs" setenv vpu "1" setenv hdmioutput "1" setenv condev "console=tty0 console=ttyS0,115200n8" # on both if test "${hpd}" = "0"; then setenv hdmi_hpd "disablehpd=true"; fi if test "${cec}" = "1"; then setenv hdmi_cec "hdmitx=cecf"; fi setenv bootargs "root=/dev/mmcblk0p2 rootfstype=ext4 quiet rootwait rw ${condev} no_console_suspend vdaccfg=0xa000 logo=osd1,loaded,0x7900000,720p,full dmfc=3 cvbsmode=576cvbs hdmimode=${m} m_bpp=${m_bpp} vout=${vout_mode} ${disableuhs} ${hdmi_hpd} ${hdmi_cec} ${enabledac} net.ifnames=0" fatload mmc 0:1 0x21000000 uImage reading uImage

5579768 bytes read fatload mmc 0:1 0x22000000 uInitrd reading uInitrd

\ Unable to read "uInitrd" from mmc 0:1 ** fatload mmc 0:1 0x21800000 meson8b_odroidc.dtb reading meson8b_odroidc.dtb

18594 bytes read fdt addr 21800000 if test "${vpu}" = "0"; then fdt rm /mesonstream; fdt rm /vdec; fdt rm /ppmgr; fi if test "${hdmioutput}" = "0"; then fdt rm /mesonfb; fi bootm 0x21000000 - 0x21800000"

Booting kernel from Legacy Image at 21000000 ...

Image Name: Linux-3.10.80 Image Type: ARM Linux Kernel Image (lzo compressed) Data Size: 5579704 Bytes = 5.3 MiB Load Address: 00208000 Entry Point: 00208000 Verifying Checksum ... OK

Flattened Device Tree blob at 21800000

Booting using the fdt blob at 0x21800000 Uncompressing Kernel Image ... OK uboot time: 5643956 us. Using machid 0xf81 from environment From device tree /memory/ node aml_reserved_end property, for relocate ramdisk and fdt, relocate_addr: 0x5008001 Loading Device Tree to 05000000, end 050078a1 ... OK

Starting kernel ...

[ 0.000000@0] Global timer: MESON TIMER-F (c097b100) initialized [ 6.455178@0] hdmi: Fixing to HDMI Mode [ 6.455248@0] hdmi: Sink is HDMI device [ 6.457229@0] hdmi: No sink attached [ 7.103071@2] ###check hw reset function is already enabled here [ 7.216546@0] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2) [ 7.219598@0] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.80 #2 [ 7.225750@0] from [ 7.234444@0] from [ 7.242342@0] from [ 7.250941@0] from [ 7.260675@0] from [ 7.270752@0] from [ 7.280039@0] from [ 7.288538@2] CPU2: stopping [ 7.291362@2] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 3.10.80 #2 [ 7.297556@2] from [ 7.306256@2] from [ 7.314589@2] from [ 7.323276@2] from [ 7.331779@2] Exception stack(0xef2a1fa0 to 0xef2a1fe8) [ 7.336967@2] 1fa0: 00000002 00000000 00000ab6 00000000 ef2a0000 c0974550 c067ad38 c09d76a0 [ 7.345328@2] 1fc0: c09d76a0 410fc051 00000001 00000000 00000000 ef2a1fe8 c000f4f4 c000f4f8 [ 7.353661@2] 1fe0: 60000113 ffffffff [ 7.357279@2] from [ 7.365740@2] from [ 7.374949@2] from <00866724> [ 7.382837@1] CPU1: stopping [ 7.385668@1] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.10.80 #2 [ 7.391862@1] from [ 7.400563@1] from [ 7.408896@1] from [ 7.417583@1] from [ 7.426086@1] Exception stack(0xef29ffa0 to 0xef29ffe8) [ 7.431275@1] ffa0: 00000001 00000000 0000149a 00000000 ef29e000 c0974550 c067ad38 c09d76a0 [ 7.439635@1] ffc0: c09d76a0 410fc051 00000001 00000000 00000000 ef29ffe8 c000f4f4 c000f4f8 [ 7.447969@1] ffe0: 60000113 ffffffff [ 7.451586@1] from [ 7.460046@1] from [ 7.469255@1] from <00866724> [ 7.477144@3] CPU3: stopping [ 7.479975@3] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 3.10.80 #2 [ 7.486169@3] from [ 7.494870@3] from [ 7.503204@3] from [ 7.511891@3] from [ 7.520394@3] Exception stack(0xef2a3fa0 to 0xef2a3fe8) [ 7.525582@3] 3fa0: 00000003 00000000 0000084e 00000000 ef2a2000 c0974550 c067ad38 c09d76a0 [ 7.533943@3] 3fc0: c09d76a0 410fc051 00000001 00000000 00000000 ef2a3fe8 c000f4f4 c000f4f8 [ 7.542276@3] 3fe0: 60000113 ffffffff [ 7.545893@3] from [ 7.554354@3] from [ 7.563562@3] from <00866724>

steev commented 8 years ago

Okay, that output seems to suggest that it can't mount the root filesystem. How did you resize the partition?

jsl303 commented 8 years ago

I used

fdisk /dev/mmcblk0 p d, 2 n, p, 2, #### (old position), ### (Maximum) w reboot Thanks for help. On 4/18/2016 1:19 AM, Steev Klimaszewski wrote:

Okay, that output seems to suggest that it can't mount the root filesystem. How did you resize the partition?

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/offensive-security/kali-arm-build-scripts/issues/76#issuecomment-211206468

jsl303 commented 8 years ago

For some reason, c1+ is now boots, but I still have a problem with C2.

I'm attaching 3 serial outputs.

1:

booti ${loadaddr} ${initrd_loadaddr} ${dtb_loadaddr}

booti ${loadaddr} - ${dtb_loadaddr}

2:

booti ${loadaddr} ${initrd_loadaddr} ${dtb_loadaddr}

booti ${loadaddr} - ${dtb_loadaddr}

3:

booti ${loadaddr} ${initrd_loadaddr} ${dtb_loadaddr}

booti ${loadaddr} - ${dtb_loadaddr}

booti kerneladdr - dtbaddr Thanks!

On 4/18/2016 9:24 AM, James Lee wrote:

I used

fdisk /dev/mmcblk0 p d, 2 n, p, 2, #### (old position), ### (Maximum) w reboot Thanks for help. On 4/18/2016 1:19 AM, Steev Klimaszewski wrote:

Okay, that output seems to suggest that it can't mount the root filesystem. How did you resize the partition?

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/offensive-security/kali-arm-build-scripts/issues/76#issuecomment-211206468

booti ${loadaddr} ${initrd_loadaddr} ${dtb_loadaddr}

booti ${loadaddr} - ${dtb_loadaddr}

GXBB:BL1:08dafd:0a8993;FEAT:EDFC318C;POC:3;RCY:0;EMMC:0;READ:0;CHK:0; TE: 151168 no sdio debug board detected

BL2 Built : 11:44:26, Nov 25 2015. gxb gfb13a3b-c2 - jcao@wonton

Board ID = 8 set vcck to 1100 mv set vddee to 1050 mv CPU clk: 1536MHz DDR channel setting: DDR0 Rank0+1 same DDR0: 2048MB(auto) @ 912MHz(2T)-13 DataBus test pass! AddrBus test pass! Load fip header from eMMC, src: 0x0000c200, des: 0x01400000, size: 0x000000b0 Load bl30 from eMMC, src: 0x00010200, des: 0x01000000, size: 0x00009ef0 Sending bl30........................................OK. Run bl30... Load bl301 from eMMC, src: 0x0001c200, des: 0x01000000, size: 0x00001690 Wait bl30...Done Sending bl301......OK. Run bl301... bl31 from eMMC, src: 0x00020200, des: 0x10100000, size: 0x00011130

--- UART initialized after reboot --- [Reset cause: unknown] [Image: unknown, amlogic_v1.1.3046-00db630 2015-10-28 15:24:31 xiaobo.gu@droid05] bl30: check_permit, count is 1 bl30: check_permit: ok! chipid: ef Load bl33 from eMMC, src: 0x00034200, des: 0x01000000, size: 0x000651a0 be ad de d f0 ad ba ef be ad de not ES chip [0.265698 Inits done] secure task start! high task start! low task start! NOTICE: BL3-1: v1.0(debug):4d2e34d NOTICE: BL3-1: Built : 17:08:35, Oct 29 2015 INFO: BL3-1: Initializing runtime services INFO: BL3-1: Preparing for EL3 exit to normal world INFO: BL3-1: Next image address = 0x1000000 INFO: BL3-1: Next image spsr = 0x3c9

U-Boot 2015.01-00070-g5785ef8 (Feb 03 2016 - 04:11:00), Build: jenkins-s905_android-ACCESS=Gerrit,BRANCH=s905_5.1.1_master,DEVICE=odroidc2-167

DRAM: 2 GiB

Relocation Offset is: 76f41000

* Welcome to Hardkernel's ODROID-C2

CPU : AMLogic S905 S/N : HKC213254DFCD06F MAC : 00:1e:06:33:1c:ef

BID : HKC2211602

register usb cfg[1][0] = 0000000077f989c8 register usb cfg[0][1] = 0000000077f989e8 vpu detect type: 5 vpu clk_level = 7 set vpu clk: 666667000Hz, readback: 666660000Hz(0x300) MMC: aml_priv->desc_buf = 0x0000000073f39d30 aml_priv->desc_buf = 0x0000000073f3bec0 SDIO Port C: 0, SDIO Port B: 1 [mmc_init] mmc init success In: serial Out: serial Err: serial reading boot-logo.bmp.gz \ Unable to read file boot-logo.bmp.gz reading boot-logo.bmp \ Unable to read file boot-logo.bmp movi: the partiton 'logo' is reading...

MMC read: dev # 0, block # 58976, count 4096 ... 4096 blocks read: OK hpd_state=0 [CANVAS]addr=0x3f800000 width=3840, height=1440

Not find '576cvbs' mapped VIC Not find '576cvbs' mapped VIC Error: Bad gzipped data There is no valid bmp file at the given address Saving Environment to MMC... Writing to MMC(0)... done Net: Meson_Ethernet Hit any key to stop autoboot: 0 reading boot.ini 2932 bytes read in 3 ms (954.1 KiB/s) cfgload: MAGIC NAME, ODROIDC2-UBOOT-CONFIG, is not found!! reading boot-logo.bmp.gz \ Unable to read file boot-logo.bmp.gz reading boot-logo.bmp \ Unable to read file boot-logo.bmp movi: the partiton 'logo' is reading...

MMC read: dev # 0, block # 58976, count 4096 ... 4096 blocks read: OK hpd_state=0 Not find '576cvbs' mapped VIC Not find '576cvbs' mapped VIC Error: Bad gzipped data There is no valid bmp file at the given address movi: the partiton 'dtb' is reading...

MMC read: dev # 0, block # 1504, count 128 ... 128 blocks read: OK movi: the partiton 'boot' is reading...

MMC read: dev # 0, block # 1632, count 32768 ... 32768 blocks read: OK Bad Linux ARM64 Image magic! odroidc2#

booti ${loadaddr} ${initrd_loadaddr} ${dtb_loadaddr}

booti ${loadaddr} - ${dtb_loadaddr}

GXBB:BL1:08dafd:0a8993;FEAT:EDFC318C;POC:3;RCY:0;EMMC:0;READ:0;CHK:0; TE: 141242 no sdio debug board detected

BL2 Built : 11:44:26, Nov 25 2015. gxb gfb13a3b-c2 - jcao@wonton

Board ID = 8 set vcck to 1100 mv set vddee to 1050 mv CPU clk: 1536MHz DDR channel setting: DDR0 Rank0+1 same DDR0: 2048MB(auto) @ 912MHz(2T)-13 DataBus test pass! AddrBus test pass! Load fip header from eMMC, src: 0x0000c200, des: 0x01400000, size: 0x000000b0 Load bl30 from eMMC, src: 0x00010200, des: 0x01000000, size: 0x00009ef0 Sending bl30........................................OK. Run bl30... Load bl301 from eMMC, src: 0x0001c200, des: 0x01000000, size: 0x00001690 Wait bl30...Done Sending bl301......OK. Run bl301... bl31 from eMMC, src: 0x00020200, des: 0x10100000, size: 0x00011130

--- UART initialized after reboot --- [Reset cause: unknown] [Image: unknown, amlogic_v1.1.3046-00db630 2015-10-28 15:24:31 xiaobo.gu@droid05] bl30: check_permit, count is 1 bl30: check_permit: ok! chipid: ef Load bl33 from eMMC, src: 0x00034200, des: 0x01000000, size: 0x000651a0 be ad de d f0 ad ba ef be ad de not ES chip [0.255784 Inits done] secure task start! high task start! low task start! NOTICE: BL3-1: v1.0(debug):4d2e34d NOTICE: BL3-1: Built : 17:08:35, Oct 29 2015 INFO: BL3-1: Initializing runtime services INFO: BL3-1: Preparing for EL3 exit to normal world INFO: BL3-1: Next image address = 0x1000000 INFO: BL3-1: Next image spsr = 0x3c9

U-Boot 2015.01-00070-g5785ef8 (Feb 03 2016 - 04:11:00), Build: jenkins-s905_android-ACCESS=Gerrit,BRANCH=s905_5.1.1_master,DEVICE=odroidc2-167

DRAM: 2 GiB

Relocation Offset is: 76f41000

* Welcome to Hardkernel's ODROID-C2

CPU : AMLogic S905 S/N : HKC213254DFCD06F MAC : 00:1e:06:33:1c:ef

BID : HKC2211602

register usb cfg[1][0] = 0000000077f989c8 register usb cfg[0][1] = 0000000077f989e8 vpu detect type: 5 vpu clk_level = 7 set vpu clk: 666667000Hz, readback: 666660000Hz(0x300) MMC: aml_priv->desc_buf = 0x0000000073f39d30 aml_priv->desc_buf = 0x0000000073f3bec0 SDIO Port C: 0, SDIO Port B: 1 [mmc_init] mmc init success In: serial Out: serial Err: serial reading boot-logo.bmp.gz \ Unable to read file boot-logo.bmp.gz reading boot-logo.bmp \ Unable to read file boot-logo.bmp movi: the partiton 'logo' is reading...

MMC read: dev # 0, block # 58976, count 4096 ... 4096 blocks read: OK hpd_state=0 [CANVAS]addr=0x3f800000 width=3840, height=1440

Not find '576cvbs' mapped VIC Not find '576cvbs' mapped VIC Error: Bad gzipped data There is no valid bmp file at the given address Saving Environment to MMC... Writing to MMC(0)... done Net: Meson_Ethernet Hit any key to stop autoboot: 0 reading boot.ini 2932 bytes read in 3 ms (954.1 KiB/s) cfgload: MAGIC NAME, ODROIDC2-UBOOT-CONFIG, is not found!! reading boot-logo.bmp.gz \ Unable to read file boot-logo.bmp.gz reading boot-logo.bmp \ Unable to read file boot-logo.bmp movi: the partiton 'logo' is reading...

MMC read: dev # 0, block # 58976, count 4096 ... 4096 blocks read: OK hpd_state=0 Not find '576cvbs' mapped VIC Not find '576cvbs' mapped VIC Error: Bad gzipped data There is no valid bmp file at the given address movi: the partiton 'dtb' is reading...

MMC read: dev # 0, block # 1504, count 128 ... 128 blocks read: OK movi: the partiton 'boot' is reading...

MMC read: dev # 0, block # 1632, count 32768 ... 32768 blocks read: OK Bad Linux ARM64 Image magic! odroidc2#

booti ${loadaddr} ${initrd_loadaddr} ${dtb_loadaddr}

booti ${loadaddr} - ${dtb_loadaddr}

booti kerneladdr - dtbaddr

GXBB:BL1:08dafd:0a8993;FEAT:EDFC318C;POC:3;RCY:0;EMMC:0;READ:0;CHK:0; TE: 141218 no sdio debug board detected

BL2 Built : 11:44:26, Nov 25 2015. gxb gfb13a3b-c2 - jcao@wonton

Board ID = 8 set vcck to 1100 mv set vddee to 1050 mv CPU clk: 1536MHz DDR channel setting: DDR0 Rank0+1 same DDR0: 2048MB(auto) @ 912MHz(2T)-13 DataBus test pass! AddrBus test pass! Load fip header from eMMC, src: 0x0000c200, des: 0x01400000, size: 0x000000b0 Load bl30 from eMMC, src: 0x00010200, des: 0x01000000, size: 0x00009ef0 Sending bl30........................................OK. Run bl30... Load bl301 from eMMC, src: 0x0001c200, des: 0x01000000, size: 0x00001690 Wait bl30...Done Sending bl301......OK. Run bl301... bl31 from eMMC, src: 0x00020200, des: 0x10100000, size: 0x00011130

--- UART initialized after reboot --- [Reset cause: unknown] [Image: unknown, amlogic_v1.1.3046-00db630 2015-10-28 15:24:31 xiaobo.gu@droid05] bl30: check_permit, count is 1 bl30: check_permit: ok! chipid: ef Load bl33 from eMMC, src: 0x00034200, des: 0x01000000, size: 0x000651a0 be ad de d f0 ad ba ef be ad de not ES chip [0.255749 Inits done] secure task start! high task start! low task start! NOTICE: BL3-1: v1.0(debug):4d2e34d NOTICE: BL3-1: Built : 17:08:35, Oct 29 2015 INFO: BL3-1: Initializing runtime services INFO: BL3-1: Preparing for EL3 exit to normal world INFO: BL3-1: Next image address = 0x1000000 INFO: BL3-1: Next image spsr = 0x3c9

U-Boot 2015.01-00070-g5785ef8 (Feb 03 2016 - 04:11:00), Build: jenkins-s905_android-ACCESS=Gerrit,BRANCH=s905_5.1.1_master,DEVICE=odroidc2-167

DRAM: 2 GiB

Relocation Offset is: 76f41000

* Welcome to Hardkernel's ODROID-C2

CPU : AMLogic S905 S/N : HKC213254DFCD06F MAC : 00:1e:06:33:1c:ef

BID : HKC2211602

register usb cfg[1][0] = 0000000077f989c8 register usb cfg[0][1] = 0000000077f989e8 vpu detect type: 5 vpu clk_level = 7 set vpu clk: 666667000Hz, readback: 666660000Hz(0x300) MMC: aml_priv->desc_buf = 0x0000000073f39d30 aml_priv->desc_buf = 0x0000000073f3bec0 SDIO Port C: 0, SDIO Port B: 1 [mmc_init] mmc init success In: serial Out: serial Err: serial reading boot-logo.bmp.gz \ Unable to read file boot-logo.bmp.gz reading boot-logo.bmp \ Unable to read file boot-logo.bmp movi: the partiton 'logo' is reading...

MMC read: dev # 0, block # 58976, count 4096 ... 4096 blocks read: OK hpd_state=0 [CANVAS]addr=0x3f800000 width=3840, height=1440

Not find '576cvbs' mapped VIC Not find '576cvbs' mapped VIC Error: Bad gzipped data There is no valid bmp file at the given address Saving Environment to MMC... Writing to MMC(0)... done Net: Meson_Ethernet Hit any key to stop autoboot: 0 reading boot.ini 2961 bytes read in 2 ms (1.4 MiB/s) cfgload: MAGIC NAME, ODROIDC2-UBOOT-CONFIG, is not found!! reading boot-logo.bmp.gz \ Unable to read file boot-logo.bmp.gz reading boot-logo.bmp \ Unable to read file boot-logo.bmp movi: the partiton 'logo' is reading...

MMC read: dev # 0, block # 58976, count 4096 ... 4096 blocks read: OK hpd_state=0 Not find '576cvbs' mapped VIC Not find '576cvbs' mapped VIC Error: Bad gzipped data There is no valid bmp file at the given address movi: the partiton 'dtb' is reading...

MMC read: dev # 0, block # 1504, count 128 ... 128 blocks read: OK movi: the partiton 'boot' is reading...

MMC read: dev # 0, block # 1632, count 32768 ... 32768 blocks read: OK Bad Linux ARM64 Image magic! odroidc2#

jsl303 commented 8 years ago

Oops, I just realized that sending the serial outputs with email attachments didn't work. Here are the full serial outputs with 3 different boot.ini. http://pastebin.com/raw/9LMBUBAY Again, thank you so much!

jsl303 commented 8 years ago

Still can't fix this problem. Is there way to download 2.1 or 2.1.1 images for c2? Thanks,

steev commented 8 years ago

No, because 2.1.2 was the first image to support the C2.

I'm still looking in to what might cause it, and one possible thing to try is after resizing to rewrite the boot loader bits to the sdcard.

As mentioned previously, there are other things on my plate so this issue is a lower priority for now but once those items are done I intend to get to the bottom of this.

On May 5, 2016, at 3:41 PM, jsl303 notifications@github.com wrote:

Still can't fix this problem. Is there way to download 2.1 or 2.1.1 images for c2? Thanks,

— You are receiving this because you commented. Reply to this email directly or view it on GitHub

jsl303 commented 8 years ago

This time I backed up Boot, expanded the partition, and reboot. Of course it doesn't boot. I restored the boot to emmc, and it boots fine. However, the partition size is back to small. :(

steev commented 8 years ago

What do you mean by backed up and restored? Like you did a dd of the first partition to an img file and then dd'd it back to /dev/mmcblk0p1 ?

jsl303 commented 8 years ago

If I plug emmc into Windows pc, I can see a 128mb partition with the following files.

boot.ini Image initrd.img-3.14.29 meson64_odroidc2.dtb mkuinitrd uInitrd I just copied those files before expanding the partition. After expanding, I just put them back. Another thing I just realized that "df -h" indicates that it's 6gb. However, "fdisk" indicates /dev/mmcblk0p2 is 29gb. Very confusing. Thanks for your help.

On 5/19/2016 2:36 AM, Steev Klimaszewski wrote:

What do you mean by backed up and restored? Like you did a dd of the first partition to an img file and then dd'd it back to /dev/mmcblk0p1 ?

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/offensive-security/kali-arm-build-scripts/issues/76#issuecomment-220239662

steev commented 8 years ago

df doesn't show the full size of the disk, only the partitions themselves. fdisk shows the entire disk.

How are you expanding the partition there? I thought you were using gparted and a linux machine.

jsl303 commented 8 years ago

Thank you so much for helping with this. I really appreciate you taking time to respond. fdisk shows 128m for p1 and 29g for p2 partitions where as df -h shows 6.5gb for /. I expanded the partition using the following command. fdisk /dev/mmcblk0

to delete /dev/mmcblk0p2

d, 2

create new

n, p, 2

set the start as how it was

set the end to the maximum

w

I get warning about how it won't be effective until I reboot.

I reboot and it doesn't reboot. Thanks again!

jsl303 commented 8 years ago

Got it to work! I think! Thank you so much for helping with this. Thinking about the discrepancy between fdisk and df, I just realized that I missed the final step! resize2fs /dev/mmcblk0p2 For people who might have the same problem, here are the steps.

  1. Flash the image
  2. Backup the boot partition (128m)
  3. Delete the primary partition and create a new partition using fdisk
  4. Restore the backup into the boot
  5. resize2fs /dev/mmcblk0p2 Yea! I'm not sure why expanding the primary partition messes the boot partition, but it works for now! Thanks!
steev commented 8 years ago

Right, I'm not sure what is causing it either, it's very odd, and that was the original workaround as previously mentioned. Vendor can't seem to reproduce the issue at all and at the moment, I don't have a spare C2 in order to do testing on (one of mine died).

jsl303 commented 8 years ago

I thought I got to the end, but the problem persists... After restoring the boot, If I reboot, the partition doesn't boot again. If I restore the boot partition, it boots again. Basically, whenever I want to start odroid, I have to restore the boot. Any thought on what might be causing this? I hope the connector doesn't break from disconnecting/connecting emmc so many times... :( Thanks,

On 5/19/2016 7:40 PM, Steev Klimaszewski wrote:

Right, I'm not sure what is causing it either, it's very odd, and that was the original workaround as previously mentioned. Vendor can't seem to reproduce the issue at all and at the moment, I don't have a spare C2 in order to do testing on (one of mine died).

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/offensive-security/kali-arm-build-scripts/issues/76#issuecomment-220478629

ndur0 commented 8 years ago

jsl303...this is a temporary workaround i used for my Odroid C2 with 32gig eMMC when u-boot thinks uIinitrd is corrupted on shutdown/reboot (Bad Data - CRC Ramdisk image is corrupt or invalid) until a proper solution is available.

this should boot your device without having to flash every time.

to automate b/c that got old really quick (skip above steps if you dont want to manually load :)

I was able to shutdown/reboot without any issues. not pretty but it worked.

btw - i used gparted on my host (kali rolling) to expand the emmc 6.5gig rootfs1 partition (/dev/mmcblk0p2) to 29gig...no issues with above workaround.

jsl303 commented 8 years ago

Thanks for the solution.

I'm a newbie, so would you mind elaborating on couple of steps? I'd really appreciate it.

usb-uart cable - minicom - u-boot -fatload uInitrd, Image, meson64_odroidc2.dtb (clean copy of those 3 files) then booti this should boot your device without having to flash every time.

Also, you said I can skip the first set of instructions if I don't have usb-uart cable.

What's the advantage of doing it if you can skip the first set of instructions?

Thanks!!!

jsl303 commented 8 years ago

Thank you both for helping with this.

I was able to boot multiple times without a problem. Yea!

I guess it has nothing to do with expanding the main partition then.

Does it corrupt the boot partition when shutting down? I wonder if the partition remains working if you just unplug the power without shutdown (or reboot.)

Anyways, for other newbie like myself, here are the steps! • Flash the image • Boot • Mount the boot partition and also make it auto mount on start up using /etc/fstab. mount /dev/mmcblk0p1 /boot echo '/dev/mmcblk0p1 /boot auto defaults 0 0' /etc/fstab • Create backup folder and create the restore script. mkdir /boot/backup nano /boot/backup/restore.sh

!/bin/bash

cp /boot/backup/Image /boot/ cp /boot/backup/meson64_odroidc2.dtb /boot/ cp /boot/backup/uInitrd /boot/ • Make the script executable and make sure it runs without error. chmod 755 /boot/backup/restore.sh /boot/backup/restore.sh • Add the script to the rc.local. nano /etc/rc.local Add the following line Before exit 0. /boot/backup/restore.sh

ndur0 commented 8 years ago

very cool, glad it worked for you too.

Regarding skipping the first set of instructions...when i commented on the issue/workaround i was just documenting my work flow.

An advantage(s) for doing the first set of instructions would be to understand what is happening during the boot process so the problem can be specifically identified. Another would be not having to flash the image for the 'nth time especially if you already started adding packages, configuring, partition, etc.

usb-uart is just the type of cable i used to get a direct connection to my odroid minicom is the linux program i used to connect my host with odroid u-boot prompt is where commands can be issued to odroid (mine automatically took me to u-boot when it failed to boot which showed odroidc2#)

u-boot has a number of commands including fatload and booti which were helpful for this issue. fatload file load booti load in memory

these commands may vary depending on if using emmc or microsd also partitioning (mine was emmc card with boot and root partition). The 'backup' folder is created on the emmc card boot partition (/dev/mmcblk0p1). fatload mmc 0:1 ${initrd_loadaddr} backup/uInitrd fatload mmc 0:1 ${loadaddr} backup/Image fatload mmc 0:1 ${dtb_loadaddr} backup/meson64_odroidc2.dtb booti ${loadaddr} ${initrd_loadaddr} ${dtb_loadaddr} last command will boot odroid and should get you to kali login prompt

Regarding expanding the partition, that doesnt have anything to do with problem from what im seeing.

Not exactly sure why u-boot thinks the uInitrd is corrupted. When comparing a "corrupted" uInitrd to a "clean" copy they appear identical. Beyond my expertise.

It seems like when shutting down odroid OS (kali in this instance) via shutdown or reboot commands causes the problem. For me, unplugging the power from odroid (not doing a proper shutdown) did not corrupt the uInitrd and I was able to plug power back in and boot again but that will probably cause other problems like losing your emmc card eventually.

fyi: for the 2nd option/instructions regarding automating the workaround. You only need to copy/replace uInitrd not the other 2 files. The only reason the other 2 files are needed in the first set of instructions is b/c your entering the boot process and it needs those files to get past that stage.

jsl303 commented 8 years ago

Thank you very much for the detail explanation! Finally enjoying Kalidroid!

steev commented 8 years ago

I think I may have figured it out...

There's some wierdness with Amlogic and sdcard/emmc card sizes. Try something like this...

Instead of filling your full sdcard, try something like

rootfs_begin=`fdisk -l /dev/mmcblk0 | grep mmcblk0p2 | awk '{print $2}'`
rootfs_end=$((`fdisk -l /dev/mmcblk0 | grep Disk | grep sectors | awk '{printf $7}'` - 1024))

fdisk /dev/mmcblk0 <<EOF
p
d
2
n
p
2
$rootfs_begin
$rootfs_end
p
w
EOF

And then the resize2fs /dev/mmcblk0p2 (of course)

ndur0 commented 8 years ago

Hi steev, just wanted to get back to you regarding your recent post (sorry for the delay).

At least for my situation, my odroid c2 with kali arm image was able to be partitioned without a problem (i used my Kali Rolling host to mount emmc and gparted to expand partition).

However, I also tried your method above and that also worked just fine...

...until a reboot which leads to the problem jsl303 had toward the latter half of your dialogue, after you got him through the initial partitioning issue.

Once kali is rebooted (shutdown -r now, reboot, etc) the uInitrd appears to be corrupted (according to u-boot).

This other issue happens regardless of partitioning or not as there are other posts (on Odroid's forum) about this u-boot/uInitrd problem.

When jsl303 (i think he confirmed this earlier) posted this issue regarding partitioning, it was complicated with the other issue of u-boot seeing uInitrd as corrupted.

For what it is worth, i thought it would help anyone else who is having similar issue to note that there were 2 separate issues not related to each other in this conversation.

Mike-Resheph commented 8 years ago

I have the Odroid C2 with a 16GB eMMC. My issue is that it boots the first time after a flash of the eMMC, but then it doesnt boot any more.

It started out with me flashing the official Odroid C2 Kali image on the eMMC. (https://images.offensive-security.com/arm-images/kali-2.1.2-odroidc2.img.xz) I booted it and resized the partition to fit the 16GB eMMC. I did a load of "sync" to ensure writing was complete, and tried to reboot. It didnt boot. The blue LED does not continue blink after the reboot, meaning the kernel didnt load properly, so I tried resizing in a lot of different ways, including the Odroid way: http://forum.odroid.com/viewtopic.php?f=52&t=2948 I also tried Gparted as I would normally do. I tried both rebooting from the GUI and "shutdown -r now".

I learned that it had nothing to do with the resize. I redownloaded the Kali image to make sure it was not faulty, flashed the eMMC and booted the C2. It worked, so I logged in and did nothing else. Then rebooted and it didnt boot up. I even tried a full dist-upgrade before rebooting, at one point. I tried flashing using the Kali way. (xzcat kali-$version-odroidc.img.xz | dd of=/dev/sdb bs=512k) And I tried using the normal Win32DiskImager, and the Odroid Win32DiskImager (http://dn.odroid.com/DiskImager_ODROID/Win32DiskImager-odroid-v1.3.zip) I think I tried 5 different card readers also with different SD to MicroSD converters. Both USB2 and USB3 ones, including "USB 3.0 : Transcend Information USB 3.0 Card Reader (TS-RDF5K)" to avoid the SD to MicroSD conversion. This reader is on the Odroid compability list. http://forum.odroid.com/viewtopic.php?f=53&t=2725 Using the Odroid Win32DiskImager I tried verifying the data but I get "Read back data is different from original data." every time. The odd thing is, even though both the Kali image and the official Ubuntu image gives a "Read back data is different from original data." error after flashing, the Ubuntu image works fine. It boots and reboots with no issues. So it is not a faulty eMMC card. (http://odroid.com/dokuwiki/doku.php?id=en:c2_release_linux_ubuntu)

Another odd thing is, I have no issues with booting and rebooting the official Kali image, if I use my Samsung MicroSDXC 64GB card. That is the only SD card I have tested. I do not get the "Read back data is different from original data." if I use the SD card.

I have no UART cable so I have no info on what is going on. I do guess that it is related to below issues: https://forums.kali.org/showthread.php?30731-Odroid-C1-and-C2-Don-t-Boot-After-Partition-Resize (Even though the resizing has nothing to do with the issue) https://github.com/offensive-security/kali-arm-build-scripts/issues/76 (This issue)

The Odroid C2 Ubuntu image is recommended to be written with a bs of 1m (http://odroid.com/dokuwiki/doku.php?id=en:odroid_flashing_tools): $ sudo dd if=<my/odroid/image.img> of=</dev/path/of/card> bs=1M conv=fsync $ sync Does that matter on the eMMC that we only write up to 512 bytes at the time when doing it the Kali way? Compared to a SD card. I dont know what effect the "conv=fsync" actually has.

Is there any news on this issue?

steev commented 8 years ago

Hi Mike, as stated in comment 75, there needs to be some space at the end of the emmc. Roughly 1MB.

This is due to An logic's handling and there is no other workaround.

Mike-Resheph commented 8 years ago

I an just flashing the device, booting. When I am logged on, i reboot, and it stops working. So I guess I have ~8GB available on the eMMC at the end. I will just change to a SD card.

vladcalina95 commented 8 years ago

Can someone please take me through all the steps of installing kali linux on and odroid-c2 (32GB emmc) once i flash the image to the emmc, i boot once and if i sudo reboot it wont work anymore. I think it has something to do with the volume size and the resizing of partitions and doing the right things with the dd and fdisk tools. Can anyone please be so kind as to take me through all the exact steps of how i should prepare the emmc and how to fully install kali linux. Thank you!

TommyWhite commented 7 years ago

Hello guys, I have faced with the same issue. I tried all, wrote script for restore boot and nothing. Who knows, did vendor localize the root cause?

Mike-Resheph commented 7 years ago

I changed to a SD card. I cant find it now but somewhere on the hardkernel website they say that, as far as I remember, 1-2% of the eMMCs are faulty. That might be it.

steev commented 6 years ago

I've added the rpi-wiggle script to the odroid-c2 script to run at first boot, this will be in the 2018.3 release. I've tested it here with both emmc and sdcards between 8-64gb and it seems to resize them all and boot after the resizing (occasionally that second boot slows down a bit as the resize happens) and it all does seem to work fine.