January 21, 2018 at 16:42 #12014
I have a similar problem that doesn’t load up on the 1st gen of cubox4i.
Here is the error that happens on boot after a fresh install:
rtc-pcf8523 2-0068: setting system clock to 2041-07-28 05:37:24 UTC (2258602644) ALSA device list: #0: Integrated SPDIF #1: imx-hdmi-soc List of all partitions: b300 3872256 mmcblk0 driver: mmcblk b301 61440 mmcblk0p1 e7610754-01 b302 3872 mmcblk0p2 e7610754-02 No filesystem could mount root, tried: ext4 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2)
There is the kernel panic. I can provide full logs if necessary.
any idea?January 21, 2018 at 17:23 #12017
The size of the second partition (b302 3872 mmcblk0p2 e7610754-02) is bogus. So I guess the whole partition is invalid. How did you image that card?
P.S.: I’ve split your message into a new topic as “1st gen Cubox” refers to units with an Armada 510 SoC from early 2012, not any form of a Cubox-i which features imx6 SoCs.January 21, 2018 at 17:32 #12018
I imaged it using DD-utility on Macbook. I used this tool several times before for previous geexbox versions (I was using a version from 2016 and decided today to do a fresh install).
I tried the latest image
geexbox-devel-20180107-r3b6708a.cuboxion 2 different sdcards without success. I’m able to boot up other OSs using the ignition.img from SolidRun but it doesn’t have the latest version of geexbox there.
I tried the
make-sdcardscript but some commands used there seems that aren’t available on MacOS and I don’t have a linux around right now.January 21, 2018 at 17:41 #12019
Hmm, I cannot check the image before tomorrow evening… However, did you use the option “conv=fsync” for the dd command to ensure that all data is flushed out before removing the card?January 21, 2018 at 17:52 #12020
using the DD Utility app (is a GUI app) I can’t change the arguments.
do you have command example? basics are
dd if=x.img of=/dev/Xbut not sure about other arguments.January 21, 2018 at 18:02 #12021
do you have command example? basics are dd if=x.img of=/dev/X but not sure about other arguments.
I don’t have a mac here but the comand should be:
dd if=x.img of=/dev/X conv=fsync
I’m able to boot up other OSs using the ignition.img from SolidRun but it doesn’t have the latest version of geexbox there.
I *think* if you select ‘latest’ (or ‘20180106’) in Ignition you will actually get “Krypton 17.6”. Even though the menu says “Jarvis 16.1”.January 21, 2018 at 18:16 #12022
I did the test through Ignition. I installed version 20180106 and got the same error:
regulator-dummy: disabling input: gpio-keys.26 as /devices/soc0/gpio-keys.26/input/input3 rtc-pcf8523 2-0068: setting system clock to 2018-01-21 17:18:32 UTC (1516555112) ALSA device list: #0: Integrated SPDIF #1: imx-hdmi-soc List of all partitions: b300 15687680 mmcblk0 driver: mmcblk b301 61440 mmcblk0p1 e7610754-01 b302 3872 mmcblk0p2 e7610754-02 No filesystem could mount root, tried: ext4 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2) CPU1: stopping CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.14.79 #1January 21, 2018 at 18:17 #12023
FYI: I tested before same steps but selecting OpenELEC and it loaded up.January 21, 2018 at 19:41 #12024
So most likely the *.img.xz is corrupt. We have to check why.January 21, 2018 at 23:47 #12025
ok. let me know when you have a fix and I can test the images.January 22, 2018 at 13:50 #12026
Please re-try Ignition. The scripts have been updated to use the *.tar.xz files whenever possible. This should bypass the currently broken *.img.xz.January 22, 2018 at 19:35 #12027
yo. working fine. something wrong happened on the *.img packaging.
OFFTOPIC: btw, how I can create a new OPKG? for example, couchpotato version that is in the repo is an old one and I would like to update to the new version. if I see that is stable, I can also send you the opkg so you can update it on the repo.January 22, 2018 at 22:03 #12028
Update: The *.img.xz is not broken per se. The problem is, that there is a mechanism (triggered on first boot) that is supposed to automatically expand the second partition to span the whole sd card. For some reason (probably an update of the fdisk tool), this will fail killing the whole partition. Working on a fix…January 24, 2018 at 18:45 #12030
The problem has been identified and will be fixed in the next build.
btw, how I can create a new OPKG?…
I’m afraid it’s not that easy without setting up a full-blown OpenBricks build environment.
You must be logged in to reply to this topic.