On 23-12-15 14:34, Bjarne Saltbæk wrote: > Hi Jacco. > > Happy Holidays :) > > I haven't tried, but can /boot/kernel.img (or /boot/kernel7.img) be a > symlink? Can the bootloader handle this, if so, removing the kernel > would be a cleaner process - just redirecting the symlink to another > kernel. I don't think symlinking is supported on vfat ...
> Or why don't just use the upstream pre/post scripts in the RPM ? ? which upstream? CentOS/RHEL do not need to copy kernels, they adjust grub. pidora (which stood model for this rpm, to a large extend) does exactly what I do now. > > > > > Nice! (I always edit the thing by hand) > > > > i would recommend to use mock in stead of rpmbuild -ba, but that's a > > minor thing here. > > Haha, a discrete kick I my b*** to get my koji project going :P > (on that note - I'm still struggling with getting sigul working > correct - its so so so undocumented) > > ofc I prefer mock as well. The script was sort of a shout-out to the > community until somebody (cough* you Jacco) will make a repo available > with regular builds - could easily be done with a GitHub-githook > (should I make one?). I noticed a small missing piece. Besides date, commit uuids and kernel version I also might want to update the release string. The idea is/was that we could have multiple kernel rpms with the same basic kernel version, but with an increased release number. In practice I don't do this, because I seldom see the need to release new kernel rpms with the same version. But if we are going to automate this based on git, this will happen. (and git uuid is not good enough, because it is not guaranteed to increase, leading to issues finding the latest kernel by the post(un)install scripts) > > > If you want to spend some brain cycles on this, I recently found a > > rather annoying bug in the rpm. the bug is in the (un)install scripts. > > Installation goes fine, but on remove it does the wrong thing. (and as > > update is actually an install followed by a remove, updates don't work > > as expected.) > > I remember some recommendation somewhere long time ago NEVER "update" > a kernel, always do an "install". I think it is set in upstream > yum.conf only to install kernels. Yeah, I probably did not express myself careful here. There is now a limit of three installed kernels in yum.conf. If a newer kernel comes along, it will get installed and the oldest of the three installed ones gets removed. The issue I tried to describe is not on the installation, but on the removal of that oldest rpm. > > > point is that there are files called kernel-<version> in /boot and that > > the one to be used is to be copied to kernel.img. on install this works > > well, we know what kernel was installed and copy that to kernel.img. on > > remove however we should make sure that one of the kernels, that is > > still there, is copied to kernel.img (people might want to remove the > > latest kernel). > > Hmm not a 100% perfect solution could be doing a > cp /boot/kernel.img /boot/kernel-<the_new_kernel_verion>-bak.img > on pre-ins > and on post-un > copy it back to /boot/kernel.img > > Then at least you do a backup and restore in the RPM > ? > BR > Bjarne I'm not sure I understand what you mean. I think the issue is only present at uninstall. Of course you could first copy the existing kernel.img away and at post copy it back, but that would be the same as doing nothing. (kernel.img is not part of any rpm. it only gets there when copied from a postinstall script) And then the issue still exists that you cannot remove the latest kernel. (or you can, but the actual kernel.img does not get changed) Jacco
_______________________________________________ users mailing list [email protected] https://lists.redsleeve.org/mailman/listinfo/users
