So continuing from this thread since i dont wanna threadjack im facing a simular issue using this image used rufus instead of suse imagewriter since its defunkt on windows 10, have tested the sdcard with 0 errors took about 3 hours to do so since im using a 32gb card for my server.

Warning: Only 30418 of 30419 MByte tested.
Test finished without errors.
You can now delete the test files *.h2w or verify them again.
Writing speed: 5.57 MByte/s
Reading speed: 8.19 MByte/s
H2testw v1.4

So same scenario as the ubuntu distro

Found U-Boot script /boot/boot.scr
[ bytes read info ]
## Executing script at 43100000
** File not found /boot/.next **
** Unrecognized filesystem type **
[ bytes read info ]
** ext4fs_devread read error - block
** Can't read partition table on 0:0 **
** Invalid partition 1 **
Kernel image @ 0x48000000 [ 0x000000 - 0x558a0 ]

Staring kernel ... 

as the first boot always takes some time while swap etc is being built and i left it alone came back an hour later still stuck on starting kernel.

 

any advice at this point ?

@Toast

 

@Igor would know better

 

** File not found /boot/.next ** .next is used for mainline kernel

 

The only piece of advise as "newbie", can you try to write the image from a linux machine with dd or better dc3dd tool ? so we can make sure there is no "options" making the sdcard badly written

 

dcfldd has also a nice "on the fly" hashing mechanism (so to avoid complex md5 or sha*)

 

=> dc3dd & dcfldd are improved forks of dd

 

Also, after writing the sdcard, "sudo fsck /dev/sdX1" would be nice as "** Unrecognized filesystem type **"

my guess is that that it just check if there is a mainline kernel if not it boots the legacy kernel.

 

as for writing the image sure i got a linux machine i could write the image to sd on but rufus should be able to handle it since it knows that the raw file is a dd image hasnt failed me on other distros 

This looks like a fault SD but since you tested the media ... Try latest Cubietruck image which I am 100% sure that it works. I don't test images on CB2 since I don't own it.

Would it even boot since Cubietruck and Cubieboard are two different boards?

 

in anycase tried and it fails same as before

What type of card do you have? microSD, microSDHC, microSDXC?  Do you have another microSD card (preferrably smaller than 32GB) to test?

Also try writing image to card using win32diskimager, it works on Win8.1

@zador.blood.stained

MicroSD tried with both Rufus and Win32diskimager..

 

Did you get your Cubieboard2 to boot ?

It can't be "normal" microSD since their size is limited to 4GB

 

Maximum capacity

• SD - 4GB
• SDHC - 32GB
• SDXC - 2TB

 

Look at markings on the card itself, it should be either HC or XC. And as far as I remember some XC cards have problems when they are formatted not in exFAT FS.

I have cubietruck (which essentially has same SoC, same u-boot and kernel configs, and these images should work. I suggest trying different card before blaming Armbian image.

It can't be "normal" microSD since their size is limited to 4GB

 

Look at markings on the card itself, it should be either HC or XC. And as far as I remember some XC cards have problems when they are formatted not in exFAT FS.

I have cubietruck (which essentially has same SoC, same u-boot and kernel configs, and these images should work. I suggest trying different card before blaming Armbian image.

Err not blaming trying to find the root cause of it all 

 

and yeah its a HC, i can boot older version of debian ie cubeez on that card

i can boot older version of debian ie cubeez on that card

OK, then I'll double check this image for any obvious problems.

 

Did you try booting one with kernel 4.2.3? Does it show same filesystem/partition error in u-boot?

 

Edit: image boots on cubietruck up to network startup, can't check any further due to network driver incompatibility.

No gonna try that and see if it gives up the same message ill come back once ive done that

As before flashed the sd card with the image using win32diskimager still gives me the same message

 

 

Then I still suggest trying another card, unless you have USB-UART adapter and some free time.

k another sd card this time a microsd 4gb

Test finished without errors.
You can now delete the test files *.h2w or verify them again.
Writing speed: 3.50 MByte/s
Reading speed: 13.9 MByte/s
H2testw v1.

Same as before trying the 4.2.3 vanilla kernel and it booted but still dont see why a HC card could make or break the boot process since i can use the old debian images from cubieboard page

 

still a big thx for the support and a big tnx to @igor for bringing a modern kernel to the crappy cubieboard

There is a possibility that this card uses large block size which interferes with u-boot SD driver or ext4 filesystem layout.

"Official" images have fat boot partition and older u-boot, and then kernel uses its own SD and ext4 drivers.

Worth investigating @Igor does your cubietruck freakout if you try and boot from a HC card ? 

I have no HC SD card around, so this can take days to get test results.

 

Poslano z mojega MI 2S z uporabo Tapatalk

Cubietruck definitely boots from Toshiba 16GB microSDHC class 4, Toshiba microSDHC class 10 UHS-I 8GB, Kingston microSDHC class 4 4GB and Transcend microSDHC class 10 UHS-I 16GB, so I think it depends on card itself.