SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Yes, could be done and would be nice to be done like this, but the first condition for a design like this is that the kernel files to have an "incoming" treatment, then to be forever leaved alone by the pkgtools.
Of course, otherwise it does not have much sense. In some way pkgtools could install them in parallel, but that would also make a call to that extra script and ask you for action.
In some way pkgtools could install them in parallel,
I always use "installpg" from the pkgtools package to only add all of the new kernel packages I want and then adjust some symlinks (non EFI, of course):
vmlinuz.bak to the older backup kernel which is reliable working
vmlinuz to the one I want to reboot TO
vmlinuz.new to the one I want to try out, but not make the boot default yet
and then run "lilo". Its config has been set up to use those links.
The same trick with links can be done for the initrd files, of course (I currently do not any, all of my kernels are custom or huge).
Then at the next reboot I can choose in the lilo menu any of those three, but without interaction it will boot to the vmlinuz one.
As they are only links lilo's config doesn't need to know any of the real kernel versions those three are linked to, so normally doesn't have to be changed at all.
Last edited by ehartman; 05-02-2020 at 10:04 PM.
Reason: typing errors corrected
Mutt 1.14.0 was released on May 2, 2020. This release has new features and bug fixes. See the UPDATING file, or for more details see the release notes page.
Some time ago there was an rc.nfsd snippet to create /proc/fs/nfsd/nfsv4recoverydir but that was removed. I don't know if creating /var/lib/nfs/nfsdcltrack should be part of rc.nfsd or if that is something that should be left to users.
I'm not sure this thread is the best place to report such a thing, but the last ChangeLog.txt message is not formatted properly in the slackpkg install-new window, is off by about 10 characters, so line endings get truncated.
I'm not sure this thread is the best place to report such a thing, but the last ChangeLog.txt message is not formatted properly in the slackpkg install-new window, is off by about 10 characters, so line endings get truncated.
Why not enabling these entries in the kernel? Are very useful (and necessary) to use hugepages for virtual machines and pci passtrough(gaming, but not only).
What matters with regard to UEFI is the machine's architecture, in other words the hardware. Using a 32bit UEFI image on a 64bit hardware is not supposed to work. Whether the installer be 32bit or 64bit doesn't matter with regard to UEFI as when the installer is loaded it has taken over the hardware, so the firmware is out of sight of the UEFI image.
Right, you need your UEFI loader to match your hardware. Ideally you could use the loader to load anything, but I don't think it's that simple. I've got a 64-bit loader on 64-bit hardware trying to load a 32-bit kernel/initrd. It makes some progress loading the files, then immediately reboots. Legacy boot is the only way I've been able to make it work.
Anyway, none of that has to do with the problem I'm reporting. Section 3.5.1.1 of the UEFI spec says BOOTIA32.EFI is the conventional file name for a 32-bit loader with PE executable machine type 0x14c. The 32-bit usbboot.img has 32-bit elilo (with the 0x14c machine type) installed as BOOTX64.EFI, not BOOTIA32.EFI.
My apologies if this isn't completely right - I don't have a 32-bit machine or VM available for testing right now, but it seems like the 32-bit samba needs to be rebuilt on top of nettle? I converted the latest samba using convertpkg-compat32 for use on my multilib system, and it seems that samba-4.12.2 wants to use libbnettle.so.7 and libhogweed.so.5, but nettle-3.6 has libnettle.so.8 and libhogweed.so.6.
How about some slackpkg hooks for customization of things like the lookkernel function in post-functions.sh? I add my own code there for updating initrd/kernels/grub, but presumably it will be overwritten when slackpkg is updated. Would be nice if I could keep this persistent.
You just need to create your own custom function in /usr/libexec/slackpkg/functions.d/
The custom function will survive package updates.
The technique is described here
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
