Hi list,
Time permitting, in the last days/weeks, we worked with Pablo (thanks again) to catch up with some things in the CentOS armhfp land. So we'd like to discuss some of the changes we'll probably implement for the next 7.5.18xx release (we still don't know when that will happen though) :
# images : - we'll switch from our current rbf scripts to appliance-creator, and we'll host the used kickstart files so that everybody can also respin various images or variants - as we now have Gnome/KDE working correctly and all built, we'll probably start building such images (like for Fedora) - selinux context is now good so doesn't need the "touch /.autorelabel && systemctl reboot" to then switch to enforcing mode - one "Generic" image to rule them all ! Idea is to not build/test for boards like cubietruck/bananapi/etc, as it's all supported upstream, but only one generic image/variant (like minimal or gnome) and just adapt the uboot bootloader. The only exception though will be for raspberrypi (2 and 3 ) : while the Generic image will work (tested already) with upstream kernel, we'll still offer a variant using the rpi foundation kernel, as we did in the past, as that will ensure that such users will also continue to get kernel updates as they get those right now
# kernel: - we'll rebase to 4.14.x (new upstream LTS version, even if 4.9.x is still maintained upstream) : that will permit to support more boards probably (rpi kernel will also get a bump, already built too in testing)
# uboot-tools : already updated to 2018.03 to also support more boards, but that will become mandatory as we'll *not* build specific images for specific board (as the Generic one can be used everywhere, and will only need the dd if= of=/dev/mmbclk0 for the uboot bootloader
Am 26.03.18 um 15:36 schrieb Fabian Arrotin:
Hi list,
Time permitting, in the last days/weeks, we worked with Pablo (thanks again) to catch up with some things in the CentOS armhfp land. So we'd like to discuss some of the changes we'll probably implement for the next 7.5.18xx release (we still don't know when that will happen though) :
# images :
- we'll switch from our current rbf scripts to appliance-creator, and
we'll host the used kickstart files so that everybody can also respin various images or variants
- as we now have Gnome/KDE working correctly and all built, we'll
probably start building such images (like for Fedora)
- selinux context is now good so doesn't need the "touch /.autorelabel
&& systemctl reboot" to then switch to enforcing mode
- one "Generic" image to rule them all ! Idea is to not build/test for
boards like cubietruck/bananapi/etc, as it's all supported upstream, but only one generic image/variant (like minimal or gnome) and just adapt the uboot bootloader. The only exception though will be for raspberrypi (2 and 3 ) : while the Generic image will work (tested already) with upstream kernel, we'll still offer a variant using the rpi foundation kernel, as we did in the past, as that will ensure that such users will also continue to get kernel updates as they get those right now
Do you have plans to provide a generic armhfp root filesystem like Jim does for aarch64, e.g. [1]?
[1] http://mirror.centos.org/altarch/7/isos/aarch64/CentOS-7-aarch64-rootfs-7.4.... Cheers Uli
On 26/03/18 16:27, Uli Middelberg wrote:
Am 26.03.18 um 15:36 schrieb Fabian Arrotin:
Hi list,
Time permitting, in the last days/weeks, we worked with Pablo (thanks again) to catch up with some things in the CentOS armhfp land. So we'd like to discuss some of the changes we'll probably implement for the next 7.5.18xx release (we still don't know when that will happen though) :
# images :
- we'll switch from our current rbf scripts to appliance-creator, and
we'll host the used kickstart files so that everybody can also respin various images or variants
- as we now have Gnome/KDE working correctly and all built, we'll
probably start building such images (like for Fedora)
- selinux context is now good so doesn't need the "touch /.autorelabel
&& systemctl reboot" to then switch to enforcing mode
- one "Generic" image to rule them all ! Idea is to not build/test for
boards like cubietruck/bananapi/etc, as it's all supported upstream, but only one generic image/variant (like minimal or gnome) and just adapt the uboot bootloader. The only exception though will be for raspberrypi (2 and 3 ) : while the Generic image will work (tested already) with upstream kernel, we'll still offer a variant using the rpi foundation kernel, as we did in the past, as that will ensure that such users will also continue to get kernel updates as they get those right now
Do you have plans to provide a generic armhfp root filesystem like Jim does for aarch64, e.g. [1]?
[1] http://mirror.centos.org/altarch/7/isos/aarch64/CentOS-7-aarch64-rootfs-7.4.... Cheers Uli
Well, I don't think we ever got such request, but can be easily done : appliance-creator will create the image, but it's then easy to extract what we need/want with virt-tar-out/virt-copy-out :-) The only question I have is the following one then : one consolidated RootFS that would include /boot ? as for the actual (and new) images we have /boot a separate partition, so I guess you mean the whole thing as a RootFS ?
Am 26.03.18 um 16:32 schrieb Fabian Arrotin:
Well, I don't think we ever got such request, but can be easily done : appliance-creator will create the image, but it's then easy to extract what we need/want with virt-tar-out/virt-copy-out :-)
I've written some scripts which automatically compose vendor firmware, vendor/mainline kernel and a root filesystem for some ARM boards which aren't supported officially. In the past I've ripped the root filesystem contents from the images you've provided for the BananaPi.
The only question I have is the following one then : one consolidated RootFS that would include /boot ? as for the actual (and new) images we have /boot a separate partition, so I guess you mean the whole thing as a RootFS ?
Yes, the whole thing including /boot.
For the board setup, I prefer a single partition layout as most of the u-boot firmware images are able to read from ext4 filesystems.
If you have installed more then one OS for your board, it's easier to handle them.
Cheers Uli
On 26/03/18 17:43, Uli Middelberg wrote:
Am 26.03.18 um 16:32 schrieb Fabian Arrotin:
Well, I don't think we ever got such request, but can be easily done : appliance-creator will create the image, but it's then easy to extract what we need/want with virt-tar-out/virt-copy-out :-)
I've written some scripts which automatically compose vendor firmware, vendor/mainline kernel and a root filesystem for some ARM boards which aren't supported officially. In the past I've ripped the root filesystem contents from the images you've provided for the BananaPi.
The only question I have is the following one then : one consolidated RootFS that would include /boot ? as for the actual (and new) images we have /boot a separate partition, so I guess you mean the whole thing as a RootFS ?
Yes, the whole thing including /boot.
For the board setup, I prefer a single partition layout as most of the u-boot firmware images are able to read from ext4 filesystems.
If you have installed more then one OS for your board, it's easier to handle them.
Cheers Uli
That works for me, so let me already build such RootFS with the tool, so that you can validate that it works and we'll then be ready for that additional change for the next release.
On 27/03/18 09:42, Fabian Arrotin wrote:
On 26/03/18 17:43, Uli Middelberg wrote:
Am 26.03.18 um 16:32 schrieb Fabian Arrotin:
Well, I don't think we ever got such request, but can be easily done : appliance-creator will create the image, but it's then easy to extract what we need/want with virt-tar-out/virt-copy-out :-)
I've written some scripts which automatically compose vendor firmware, vendor/mainline kernel and a root filesystem for some ARM boards which aren't supported officially. In the past I've ripped the root filesystem contents from the images you've provided for the BananaPi.
The only question I have is the following one then : one consolidated RootFS that would include /boot ? as for the actual (and new) images we have /boot a separate partition, so I guess you mean the whole thing as a RootFS ?
Yes, the whole thing including /boot.
For the board setup, I prefer a single partition layout as most of the u-boot firmware images are able to read from ext4 filesystems.
If you have installed more then one OS for your board, it's easier to handle them.
Cheers Uli
That works for me, so let me already build such RootFS with the tool, so that you can validate that it works and we'll then be ready for that additional change for the next release.
Just quickly built a .img and extracted / through virt-tar-out. Can you validate that it's what you wanted/needed ? https://armv7.dev.centos.org/repodir/images-testing/CentOS-Userland-7-armv7h...
Am 27.03.18 um 10:16 schrieb Fabian Arrotin:
That works for me, so let me already build such RootFS with the tool, so that you can validate that it works and we'll then be ready for that additional change for the next release.
Just quickly built a .img and extracted / through virt-tar-out. Can you validate that it's what you wanted/needed ? https://armv7.dev.centos.org/repodir/images-testing/CentOS-Userland-7-armv7h...
Hi Fabian,
thank you very much, it works like a charm. Do you think you will be able to provide the kernel as a zImage as well? My utilite pro u-boot has trouble to boot the provided uImage for whatever reason. I still have my own mainline kernel, no need to worry.
Cheers Uli
Hi Fabian,
On 03/26/2018 03:36 PM, Fabian Arrotin wrote:
# images :
- we'll switch from our current rbf scripts to appliance-creator, and
we'll host the used kickstart files so that everybody can also respin various images or variants
For my armv5 project I would also like to try appliance-creator, as I hope the selinux compatibility would be better. (no more minutes of waiting at the first boot while the system relabels)
Can I use your kickstart files to get me going? Where are they hosted?
Thanks,
Jacco
El 1/6/18 a las 06:07, Jacco Ligthart escribió:
Hi Fabian,
On 03/26/2018 03:36 PM, Fabian Arrotin wrote:
# images :
- we'll switch from our current rbf scripts to appliance-creator, and
we'll host the used kickstart files so that everybody can also respin various images or variants
For my armv5 project I would also like to try appliance-creator, as I hope the selinux compatibility would be better. (no more minutes of waiting at the first boot while the system relabels)
Can I use your kickstart files to get me going? Where are they hosted?
Jacco, we haven't published those yet (due to lack of time mainly), but as soon as it is done we'll let you know. Basically, all the tools are from Fedora, with some changes for dnf/yum and python version. The ks files should be easier, and I'll coordinate with Fabian to release those ASAP.
Thanks. Pablo.
On 01/06/18 11:07, Jacco Ligthart wrote:
Hi Fabian,
On 03/26/2018 03:36 PM, Fabian Arrotin wrote:
# images :
- we'll switch from our current rbf scripts to appliance-creator, and
we'll host the used kickstart files so that everybody can also respin various images or variants
For my armv5 project I would also like to try appliance-creator, as I hope the selinux compatibility would be better. (no more minutes of waiting at the first boot while the system relabels)
Can I use your kickstart files to get me going? Where are they hosted?
Thanks,
Jacco
Hi Jacco,
I realize now that I forgot (my fault, sorry) to push those directly. Those were now pushed here : https://github.com/CentOS/sig-core-AltArch/tree/master/image_build
WRT tools, Pablo is now working on a new appliance-tools rpm pkg, as the one I use was locally patched (hot-patched in .py code and not through rpm build) . As soon as we'll have that, those will be signed/pushed to mirror.centos.org, and also sources on git repo
Cheers,
-
Fabian Arrotin -
Jacco Ligthart -
Pablo Sebastián Greco -
Uli Middelberg