On 25-09-16 18:31, Bjarne Saltbæk wrote: > > 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). > I think all is in the patches (or in own SRPMs). In the begin it took a lot of tinkering to get it all to compile. Especially all the missing dependencies. regarding git, I tried using git.centos.org but I find it a pain. Sometimes it does not create the SRPM and other times the SRPM it produces differs from the shipped version. I now use that git to create the patches, but the SRPM is created by applying the patch to a rpmbuild dir. hmm this sounds a bit vague ... it's something like this: - git clone https://git.centos.org/git/rpms/<rpm name>.git - git checkout c7 - git checkout -b redsleeve - apply previous patch - fix the errors (the patches never apply cleanly) - git commit - git format-patch c7 - rpm -i <rpm name>.src.rpm - apply patch - rpmbuild -bs <rpm name>.spec - mock <rpm name>-redsleeve.src.rpm
Now that I write this, it sounds a little labor intensive. but there are not that many patched RPMs in RSEL7. If you have a better method, let me know. > > 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. Like I said previously, I use rbf (https://github.com/mndar/rbf/). I just downloaded that, created a raspberrypi redsleeve template (this is somewhere in an earlier mail) and the let it make the image by "./rbf.py build templates/<template name>.xml" just yesterday I tinkered a little with the script you can run after image creation. I added: echo "set autorelabel" touch $ROOTPATH/.autorelabel echo "remove rbf repos" rm $ROOTPATH/etc/yum.repos.d/*_rbf.repo echo "zero the disks freespace" dd if=/dev/zero of=$ROOTPATH/zero dd if=/dev/zero of=$ROOTPATH/boot/zero sync rm -f $ROOTPATH/zero $ROOTPATH/boot/zero These things are probably a good thing to store on git. We also have an empty org laying around in github: https://github.com/redsleeve-linux maybe that's a good location? > >> 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 ;) I was aware that the upstream kernel src.rpm now just builds on redsleeve. but it only produces kernel-headers. while nice, this hardly counts as a kernel. for what device is this kernel? Gordan always said that 2.6 could only support kirkwood, but none of the other arm devices. > 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 OK I read this, you put a new (4.4.22) source in the old redhat spec. Please have a look at what Fabian and I have been doing: http://armv7.dev.centos.org/repodir/arm-kernels/rpi2-4.4.14/ https://lists.centos.org/pipermail/arm-dev/2016-September/002283.html > >> * 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 ) point is that raspberry pi does not use u-boot. all the images I got from others don't have a (u)initrd and my machines boots perfectly without. Are there other reasons than must-do-for-booting ? > >> * 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. .rpmsave is no good. we *need* those files. with that name. hmm, looking at this: http://stackoverflow.com/questions/22456217/rpm-scriptlet-ordering-for-install-remove-upgrade-using-yum I could do something with %pre and %posttrans. copy a backup first and then as very last step move it back. that is maybe not that strange. > >> * 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? maybe, I think it might also link outside the install_root. I wondered if there are more exceptions, but I now don't think so. I'll try to add another mkdir to the post image creation script. > >> "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 yup, I use those, but beta is not there. > 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 ;) I guess I'm going to try to send them a polite request. > >> - 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 yes please. how do you make a repo of it after building? I notice epel repo's normally don't hold old versions of rpm's. how do you get them out? looking at your koji, I notice odroidc1plus-3.10.103-1.20160919gitc6c2cf7 which is a sort of a coincidence, as I was working yesterday on odroidxu3-kernel-3.10.103-2.20160926gitee5e188 maybe this is also a good candidate for a git. specially because the centos-arm people are probably also interested. > >> >> 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). yup let's use the github thing. Jacco
_______________________________________________ users mailing list [email protected] https://lists.redsleeve.org/mailman/listinfo/users
