I have done some tests in the past days on my Akita, these are my results so far.
I have successfully booted the latest Alarmz rootfs on an ext3 partition by installing the 2.6 based kexecboot, and I have also managed to boot the rootfs from an ext4 partition. Since the 2.6 based kexec doesn't support neither ext4 nor f2fs partitions, I created a small ext3 partition on my SD and installed the latest 3.10 kexec on it. So, I was basically booting kexec 2.6, manually selecting kexec 3.10, and using this kexec I booted Alarmz. Now I'd like to avoid having to run two kexecs in succession, so I have followed greguu's advice and used the latest 4.12 kernel in the first partition instead of kexec, and I also changed the rootfs partition from ext4 to the new f2fs. So basically I have repartitioned my 64GB SD to 3 primary partitions:
- a 10MB ext3 one, with a boot/ directory containing the latest 4.12 kernel and a modified boot.cfg, see below
- a 48GB f2fs one with the rootfs
- a swap partition
I have left some free space at the end of the SD card, so that if the swap partition becomes corrupted due to wearing, I'll move it to the next free space on the card.
BTW, I have found that the kernel is found and booted by kexec also if it is copied in the root directory and renamed to zImage. Unfortunately, this way the boot.cfg file isn't recognised (neither by placing it in the root directory, on inside boot/), so the boot stops at one point since the root partition can't be found.
In order to point the kernel to the root partition on sda2, I have set the "root=" parameter inside boot.cfg to my root partition, i.e. /dev/mmcblk0p2. Greguu has also suggested that adding a real_root parameter and setting it to the root partition should work, too. Apparently, real_root isn't a valid kernel parameter, it is actually a script which changes the root partition once it is already booted, and this requires initrd to be used:
https://unix.stackexchange.com/questions/16...root-and-cdrootAlarmz uses noinitrd as a parameter, so I believe this solution won't work, although I haven't tried it.
I have also seen that the rootfs won't boot if /dev/sda2 is set in boot.cfg instead of /dev/mmcblk0p2, an "Unable to mount root fs on unknown-block(0,2)" error is shown. The reason might be that, at that point, sda2 isn't mounted yet.
Using this configuration I have managed to boot the rootfs on the f2fs partition. Unfortunately, I have managed to do this only once. Every other attempt to boot it again fails: the Arch Linux ARM logo is shown, but no log text is displayed at all, even after 10 minutes. The system is not freezed, since it is possible to type any text in this state, but there are no errors displayed when return is pressed, only the typed text is shown. The reason might be that I have used "halt" in order to switch off my Akita, but this command has failed, since the shell was still displayed although no more commands could be entered, so I had to unplug the power supply and remove the battery. This command might have left the filesystem to a corrupted state, so next time I'll try to run a fsck on the partition, and/or to delete and create again the filesystem, I'll report back. From what I have read in the other threads, "poweroff" seems to be the only reliable way to switch off the device.
In the meanwhile I have also tested two new beta kexec binaries for Akita provided by ant, based on the 3.10 and 3.2 kernels, but they both refuse to boot, it seems that they have to be compiled using specific gcc versions.
One last question, is the 2.6 kexec in the attachment the same as the one here?
https://github.com/greguu/linux-3.10.y-c3x0...xec-r0/releasesI guess it is, I just wanted to confirm this.
More news will follow.
Varti