[SOLVED] Use 32-bit Slackware? Post here to let the developers know!
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.
I am on 32-bit for the simple reason that I always buy used IBM Thinkpads. Been a while since IBM made them now... but Slackware runs smoothly on my T60.
I'm using 64-bit Slackware on the box from which I'm working. However, I have another box with an old Athlon XP processor that will only run 32-bit OS'es. Please don't ditch 32-bit Slackware yet. I realize that at some point our boxes that can run only 32-bit software will die. Until then, however, please keep 32-bit Slackware around.
The questions that come to my mind here:
- If I understand that correctly, some UEFI systems do not support 32 bit installations?
- What (if anything) must be different from the standard 64 bit kernel if I want to use a 64 bit kernel in place of a 32 bit one?
- Is there any (somewhat common) use case where 32 and 64 bit kernels should be available on the system?
...you might be interested in how I've been going with my slackware-on-uefi experience on a samsung smart pc pro:
To summarise:
I installed slackware (32-bit) on a uefi-windows 8 machine under CSM/legacy mode (didn't want to risk bricking the samsung machine!) after having created a partition for it within windows;
I didn't install lilo (of course), I just made a usb bootstick during setup and continued booting it this way;
Once the samsung-safe kernels were available in slackware-current I tried uefi booting by renaming elilo-x86_64.efi to /EFI/Microsoft/Boot/bootmgfw.efi, with elilo.conf in the same directory with a line "image=..." pointing to a 32-bit slackware huge kernel
You could already do this. Just grab the 64-bit kernel and modules packages from Slackware64 (e.g. kernel-generic-3.2.29-x86_64-1 and kernel-modules-3.2.29-x86_64-1 on 14.0) and install these instead of their 32-bit counterparts.
and bingo it works! So the answer to your second question above is possibly "nothing": Alien Bob's multilib stuff is only compat32 libraries etc, no changes to the kernel are needed (as I understand it). I guess the 64-bit kernel is compiled with 32-bit compatibility enabled.
I only use 32-bit code. Of the 24-or-so machines that I have, only one is 64-bit-capable, but I've never run any 64-bit code on that one because I've never had a need to address more than 4GB of memory.
@michaelslack: Thanks for your answer, it does indeed answer my questions. So if I understand it right, only 64 bit kernels will work with UEFI in most machines, so Slackware 32 bit should in the future be delivered with an optional 64 bit kernel, if UEFI support is an aim for PV for the 32 bit version.
I've since done a bit of reading around about this which turned up a few interesting little points.
If you have a 64-bit kernel (and modules) but 32-bit userland, then "uname -m" returns x86_64 so e.g. typical slackbuilds will generate packages with the architecture marked as that. But this can be fixed with a little utility called linux32 apparently.
The only remaining issue is: what to do if you need to compile a kernel module, or indeed a kernel for your system? The great example I came across is compiling KVM where userland applications and kernel modules need to be built all at once.
I'd be curious to see how to get around that one!
Cheers,
Michael
Last edited by michaelslack; 03-31-2013 at 09:45 AM.
If you have a 64-bit kernel (and modules) but 32-bit userland, then "uname -m" returns x86_64 so e.g. typical slackbuilds will generate packages with the architecture marked as that. But this can be fixed with a little utility called linux32 apparently.
The correct way would be asking the default cc, which target it compiles for (i486-slackware-linux) and then use the arch from that. You also don't have to workaround the i486/i586/i686 issue then. Setarch/linux32 usually has to be used for compiling 32 bit packages on 64 a multilib system.
Quote:
The only remaining issue is: what to do if you need to compile a kernel module, or indeed a kernel for your system? The great example I came across is compiling KVM where userland applications and kernel modules need to be built all at once.
You have to install and use a 64 bit cross compiler. There is some stuff that doesn't support mixed configurations. I think VMware Player works (once you got the modules to compile), VirtualBox doesn't and the status of KVM I don't know.
@michaelslack: Thanks for your answer, it does indeed answer my questions. So if I understand it right, only 64 bit kernels will work with UEFI in most machines, so Slackware 32 bit should in the future be delivered with an optional 64 bit kernel, if UEFI support is an aim for PV for the 32 bit version.
If a 32-bit kernel doesn't work with UEFI (and it looks like that is the case), then the 32-bit version of Slackware will not support UEFI. If people want to use the 64-bit kernel hack, they'll need to manage that themselves. The inability to compile any modules or new kernels, and the issues with SlackBuilds misidentifying the architecture are all reasons this shouldn't be officially recommended (or at least supported).
I'd heard that the problem with booting a 32-bit kernel was that it would try to contact the 64-bit firmware, causing the crash, and that passing "noefi" would get around the problem, but it doesn't work here.
If a 32-bit kernel doesn't work with UEFI (and it looks like that is the case), then the 32-bit version of Slackware will not support UEFI. If people want to use the 64-bit kernel hack, they'll need to manage that themselves.
SlackBuilds also misidentify the architecture, when built in a 32 bit multilib enviroment (via /etc/profile.d/32dev.sh). So there is currently no supported way to build 32 bit packages on a x86-64 UEFI system.
Quote:
The inability to compile any modules or new kernels, and the issues with SlackBuilds misidentifying the architecture are all reasons this shouldn't be officially recommended (or at least supported).
I don't think that people trying to boot 32 bit Slackware on UEFI machines want that for compiling kernels. Most software, that requires 3rd party kernel modules doesn't work anyway (one exception being the binary nvidia driver).
SlackBuilds also misidentify the architecture, when built in a 32 bit multilib enviroment (via /etc/profile.d/32dev.sh). So there is currently no supported way to build 32 bit packages on a x86-64 UEFI system.
This is independent from UEFI and AFAIK multilib systems are not only currently not supported by SlackBuilds.org, but they aren't in general.
i have to agree the only reason i use 32bit at all is for skype trying to get my kids to use anything but windows because thats all that they use at school and since skype is purely 32bit
You can get a Skype package from slacky.eu that contains all necessary 32 bit libraries and get installed to /opt, so you don't need a 32 bit OS or even multilib for Skype.
I've only started recently using Slackware 64 because I've bought an ultrabook with UEFI on (and no compatibility/legacy mode for the BIOS). Since then, any new installs I've done are 64bit if the processor/architecture permits. However, I still have a good number of servers in production withe Slackware 32bit on them - and many of them are too old to support 64bit. So ideally, I'd like to keep them running for as long as they will last.
If a 32-bit kernel doesn't work with UEFI (and it looks like that is the case), then the 32-bit version of Slackware will not support UEFI. If people want to use the 64-bit kernel hack, they'll need to manage that themselves. The inability to compile any modules or new kernels, and the issues with SlackBuilds misidentifying the architecture are all reasons this shouldn't be officially recommended (or at least supported).
I'd heard that the problem with booting a 32-bit kernel was that it would try to contact the 64-bit firmware, causing the crash, and that passing "noefi" would get around the problem, but it doesn't work here.
Thanks Pat for letting us know. It makes the decision to switch (back) to slackware64 much easier. Also I think the reasons I went to 32-bit slackware on 64-bit hardware in the first place are less relevant now: more stuff is available in 64-bit and more importantly I understand things a little better now!
If a 32-bit kernel doesn't work with UEFI (and it looks like that is the case), then the 32-bit version of Slackware will not support UEFI.
I believe a 32-bit kernel would theoretically work with UEFI - if it was a 32-bit UEFI. On the other hand, a number of places on the Internet seem to suggest that the only UEFI 32bit implementations that ever existed were some early Mac machines. See this quote from http://support.microsoft.com/kb/930061:
Quote:
Microsoft determined that vendors would not have any interest in producing native UEFI 32-bit firmware because of the current status of mainstream 64-bit computing and platform costs. Therefore, Microsoft has chosen not to ship support for 32-bit UEFI implementations.
Apple uses EFI for its line of Intel-based Macs. Mac OS X v10.4 Tiger and Mac OS X v10.5 Leopard implement EFI v1.10 in 32-bit mode even on newer 64-bit CPUs, but full support arrived with Mac OS X v10.8 Mountain Lion.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.