Hi Jacco. On 25-09-2016 12:39, Jacco Ligthart wrote:
Yayh, great work. Could you share all your work somewhere (is all work in the patches directory)?Have you stored it on Github or somewhere else? (feel free to use my git server at https://gitserver.dev.saltbaek.dk if you want). On 25-09-2016 12:39, Jacco Ligthart wrote: Hi All, Over the weekend I have been working on the 7.2 release. It was not that the underlying RPMs were not there, nor that they were not working, but it was just not logical to work with it. There are now 5 directories under 7.2: base, extra, patches, updates and upstream-extra: - base holds all the rebuild (and maybe changed) RPMs from the upstream vendor. (some packages are just a bit newer than upstream, I also included available updates at the time of release) - updates are the updates to that - extra is stuff that we add, think redsleeve-* packages, uboot, other arm specific things, build tools, etc. - upstream-extra is a partial rebuild from the extra stream of the upstream vendor. mostly the packages needed to build base are included - patches holds all patches to upstream RPMs I signed all packages with my redsleeve-testing key and made a new redsleeve-release package depending on that key. In short: if you already have Redsleeve7 working, please update the release rpm (http://ftp.redsleeve.org/pub/el7-devel/el7/7.2/extra/RPMS/redsleeve-release-7-2.1511.el7.2.armv5tel.rpm) and you should be good to go. (It still might take some time for all the mirrors to catch up) Next I went to make new images for the raspberrypi's (all models). I made new kernels based on Fabian's (of CentOS ARMv7 fame) SRPMs. These are actual builds (different from just packaging binary blobs, as I did previously). Fabian altered the .config file to allow for SELinux :) I also made a new raspberrypi-config package and new images (should be here later: http://www.mirrorservice.org/sites/ftp.redsleeve.org/pub/el7-devel/el7/rootfs/) Do you have the exact build process for those? I can supply boot-SD's for Odroid C1+, Banana PI M3 and the CuBox-i4x4 I would like to make the same updated boot-SD's for RSEL 6.8. I'm quite happy about the images, but there are a couple of open points in the whole setup, where I'd like some input: * I found out after the fact that the current kernel cannot uninstall itself. Of course I'll make an update soon. The question is, if this a reason to pull this RPM now? Nah, if just the updates fixes it. Over the weekend I have succeeded building a working kernel from the upstream ( http://vault.centos.org/6.8/os/Source/SPackages/kernel-2.6.32-642.el6.src.rpm ) so I assume that the upstream guys have done some proper post script ;) It is still a work-in-progress - still needs some tweaks here and there - you can follow the progress at - https://gitserver.dev.saltbaek.dk/summary/?r=rsel6/kernel-raspberrypi.git and https://gitserver.dev.saltbaek.dk/summary/?r=rsel6/kernel.git * Fabian made the kernel make an initramfs with dracut. This won't work well with previous images, due to /boot size. Does any of you know why you'd like a initramfs, if the machine boots perfectly fine without? (how to test if it is used at all?) I (and I guess Fabian) needs the initramfs temporary to create the U-Boot file uInitrd my SPEC code is: dracut --force --verbose %{buildroot}/boot/initramfs-%{version}-%{release}.img %{version}-%{release} mkimage -A arm -O linux -T ramdisk -C none -n %{version}-%{release} -d %{buildroot}/boot/initramfs-%{version}-%{release}.img %{buildroot}/boot/uInitrd-%{version}-%{release} After the uInitrd is created I do not need the initramfs anymore (just to lazy to delete it from the /boot partition =:-o ) * the new kernel allows for SELinux. if you update a machine to it, you could end with a SELinux enabled machine on a filesystem without labels. (It will disallow bash ...) any idea on how to prevent such a scenario? * I could not make a labeled filesystem with RBF. I added .autorelabel to the image. now the first boot takes a couple of minutes while the sytem relabels. Is this acceptable? * The image is made with RBF. RBF will create some files itself, notably /etc/fstab and /etc/sysconfig/network-scripts/ifcfg-eth0 These files were earlier part of raspberrypi-config. I removed them from that package. This works well for new images. But for updates these files could be lost on update. Anyone an idea on how not to delete files if the RPM gets updated? Release an intermediate "old" package with preservation code so rpm makes .rpmsave backups when upgraded. * the image throws a small error on boot about missing the /var/lock/ppp directory. The dir should be part of the ppp package. ppp is needed because NetworkManager depends on it. I guess on install time there is something wrong with the /var/run symlink. /var/run is tmpfs at install time maybe? "yum reinstall ppp" fixes the issue. I am not sure what the correct fix is here. Apparently ppp just does a "mkdir -p /var/lock/ppp" as post install script. I'll try to do something similar as part of RBF's finalize script. The plan for the coming time is: - update all odroid kernels, see if I can also build them (vs package binary blobs) see if they also can do SELinux - update the odroid-release package and sign all odroid packages - make images for the odroids - update epel-release and sign all packages -> which key to use? redsleeve-testing? or a new one specific for epel? well it is sort of a part of the distribution, right? So the redsleeve-testing. I think the signing should follow the build system AKA yours. If I get clearance to distribute redsleeve packages i will use my own key for my buildsystem. - build RSEL 7.3 if upstream finishes their beta testing. (anyone knows how to get SRPMs from the beta program? that would speedup the whole process) ftp://ftp.redhat.com/redhat/linux/enterprise/7Server/en/os/README Current sources for Red Hat Enterprise Linux 7 have been moved to the following location: https://git.centos.org/project/rpms Red Hat Enterprise Linux customers can obtain the RHEL 7 SRPMS in the Red Hat Customer Portal: https://access.redhat.com/site/downloads/. You can download them using a web browser or using yum-utils on a rhel7 system. I do have a company RHEL account, but I do not think I am allowed to distribute anything from inside the Customer Portal. Screenshots maybe ;) - do the yearly epel refresh I do mine every day and they get build at http://koji.dev.saltbaek.dk at 04.00 UTC. Want the script? :D Some of these items should, I guess, also make it to the wiki / bugzilla. I'm however a bit lost there. Me too Github tickets (or the ticket system in my Gitblit might be better). BR, Bjarne
_______________________________________________ users mailing list [email protected] https://lists.redsleeve.org/mailman/listinfo/users
