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.
Just an FYI but, I've been messing around with the installer on a spare laptop (UEFI & elilo) and if I make the root filesystem use f2fs, the system fails to boot because it is missing the crc32 module. If I do "modprobe --show-depends f2fs" nothing shows up (other than f2fs).
This Debian change mentions "crc32 as hidden dependency module for f2fs" so I rebuilt the initrd.gz to include crc32 (mkinitrd_command_generator.sh --run -m crc32) and the system boots OK.
Just an FYI but, I've been messing around with the installer on a spare laptop (UEFI & elilo) and if I make the root filesystem use f2fs, the system fails to boot because it is missing the crc32 module. If I do "modprobe --show-depends f2fs" nothing shows up (other than f2fs).
This Debian change mentions "crc32 as hidden dependency module for f2fs" so I rebuilt the initrd.gz to include crc32 (mkinitrd_command_generator.sh --run -m crc32) and the system boots OK.
I have been using the f2fs as a root filesystem for quite a while (in fact, have even sent a patch to the kernel so that the xattrs feature is build by default with f2fs, which is required for properly using it on the root).
But I do that using a "huge" kernel, which is by far a much safer option in every respect, since _a single file_ is the only thing that you need to have to make the system boot up to a survivable state, so I definitely recommend just using the "huge" kernel.
(If you search the forum, there I have also posted a report on building a kernel with an initrd appended to it. I wish I had time to finish this.)
added to /etc/inputrc ? It is a relatively (a few years old) new addition to readline, but I find it cool.
This binding is also in accord with Emacs's backward-sexp/forward-sexp.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,089
Rep:
Quote:
Originally Posted by avian
What was the issue you had with wireguard-linux-compat and wireguard-tools out of interest? I've been maintaining both packages on SBo for a bit, if it was anything beyond a configuration problem, it would be good to get it solved.
Avian,
Many thanks for the updated WireGuard packages!
Greatly appreciated!
Last edited by cwizardone; 05-16-2020 at 10:36 AM.
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.
Well, this might pretty much explain why either UEFI install fails then?
Syslinux as a project is in a comatose state. The best downstream patches are Debian's. But a lot of patches have been suggested to upstream over the years and never even looked at. Dr Ady is trying hard to keep the patient alive but he is not a developer (that's what he says, anyway).
Last edited by Didier Spaier; 05-17-2020 at 01:11 PM.
Pre-installing package cups-filters-1.27.4-x86_64-1...
mv: impossible d'évaluer 'etc/fonts/conf.d/99pdftoopvp.conf.new': Aucun fichier ou dossier de ce type
due to 'config etc/fonts/conf.d/99pdftoopvp.conf.new in the 'doinst.sh'
probably inherited from an older version of 'cups-filters'
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
