After the success of getting the old 2007 iMac running, I decided to take a stab at a used Intel Macbook. Many of these are being obsoleted as MacOS for Intel systems reaches end of life / end of support. For most basic office productivity tasks, a 5-10 yr old system is plenty good enough.

fter perusing the used computers marke places, I settled on an old Macbook Pro mid-2017 14,2

Specifications:

The Macbook needed some repair: a few new key caps to replace worn/broken, and a new battery. I split the drive into 2 partitions, leaving MacOS intact for now as a backup in case the Linux installation failed.

In MacOS, first use Disk Utility to resize and the create new empty space (or not - you can always just go for it!), shrinking the MacOS partition as needed to create space for the linux partitions. Now, boot the Slackware installer as usual: hold "option" key to get the icon for the USB drive (generic EFI icon next). When booting, chose 'nomodeset' to avoid console resolution issues (discussed below), use cfdisk to setup new root partition to Linux, and add a swap partition (needed for suspend/hibernate, more on that later). Leave Apple's EFI partition as-is. I opted for the current development branch of Slackware since this will have the latest hardware support. After performing the recommended full install procedure, skipping the lilo/elilo installation section. Lilo won't work on a Mac, and elilo will usually brick the Apple's implementation of UEFI. Finish up, but do not reboot yet. If all goes well you will have:

Since we can't use lilo or elilo, we will now set up grub2 since this is already installed and available. At this point, the root partition should still be mounted on /mnt so we will chroot:

This last one exposes the efi vars grub needs to access for the boot loader configuration.

We are now running our new Slackware! To install grub2, using the kernel and initrd already set up during the install process,

If all goes well you should see

We need to make one "small" update. Apple won't see the grub efi file unless you move and rename grubx64.efi. You can save a step by specifying '--bootloader-id=boot'. I decided to manually copy install so as to have a reminder.

If you forget to copy the efi file, you can boot back into MacOS, open the terminal:

Before we can reboot, we need one more edit. When linux boots it "guesses" the incorrect Retina Display resolution for the console framebuffer. This results in the ~5-10 lines on the bottom of the screen being outside the display area. I was not sure how to fix this via grub, or if it would stick on updates, so I opted with just adding a simple fix to /etc/rc.d/rc.local:

This will make is easy to log in and run startx. You can also just configure runlevel 4 as well since X figures out the correct screen size.

At this point you can exit the chroot and reboot. Now when you hold down the 'option' key on boot up, your should see the Apple Mac icon and the generic EFI icon. The latter will boot Slackware via grub. The Macbook will remember this choice for the next reboot.

Congratulations! You are now running Slackware on the Macbook!

At this point, most everything works using the December 2025 - Jan 2026 Slackware current except for a few items, even, amazingly, bluetooth. I was able to tether my iPhone via bluetooth for network access. I had posted on Linuxquestions.org a few months back to adjust the kernel configuration for the APPLESPI modules (CONFIG_KEYBOARD_APPLESPI is not set) thus eliminating the need to have an external keyboard during installation. Three final items needed some work: WIFI, touchbar, and audio/sound. None of these worked at all after installation.

Also, I highly recommend using kernel 6.18.x from /testing as this newer kernel seems to be a bit more operational that the install default 6.12.x or 6.14.x also in /testing.

WIFI

Ah, the bane of open source: Broadcom wireless chipsets

Network controller: Broadcom Inc. and subsidiaries BCM43602 802.11ac Wireless LAN SoC (rev 02)

While I had checked for basic support, I had overlooked a weird quirk. While the modules and firmware were available, this chipset required a configuration text file for proper operation.

/lib/firmware/brcm/brcmfmac43602.txt

For some reason, Broadcom doesn't distribute this file. You can find the one I use in Shell Scripts and Utilities.

The file linked above is the latest iteration and works well - at least so far! Otherwise, you could sometimes scan and see the access point SSID but could not connect. The whole story is here.

Edit the provided configuration file to use to your specific MAC address. The rest should already be set up.

macaddr= <enter your actual brcm MAC address here>

If you think its weird to require the MAC address, same here. The other settings allow full power, all channels and both 2.4/5 GHz. Next, add the following to /etc/modprobe.conf/brcmfmac.conf to stabilize connections and reduce drops:

Lastly, if using, NetworkManager, turn off power management. Create the file /etc/NetworkManager/conf.d/default-wifi-powersave.conf with the contents

Reboot and wifi should work. It is still a bit cranky sometimes but seems to better now with kernel 6.18.x.

TOUCHBAR

For those MacBook models with the touchbar ribbon, hunting down the driver module updates was an adventure. While keyboard and trackbad drivers are now part of the kernel, and touchbar support for newer T2 based Macbooks is drifting into the kernel, for T1 Macbooks, it doesn't look like mainline support will be added anytime soon. Apple has also dropped the touchbar from new Macbooks. You can skip the touchbar, but then you won't have ESC, Fn keys, multimedia keys, etc.

When I started this adventure a year ago, Slackware current was using an older kernel in mainline (now 6.12.x), and a newer one in /testing (now 6.18.x). For either kernel series, you will need the updated macbook12-spi-driver. First, downloaded and install dkms. For kernels before 6.14:

For kernels before 6.14 and newer (or at least 6.18.13 as of this post), you will need an updated fork:

The new modules will be installed in /lib/modules/6.x.y/. You will need to run dkms command again manually on kernel upgrades if you do not enable automatic kernel rebuilding. The power button/finger scanner will work only as a power button. Biometrics support is not implemented.

You now have basic touchbar functions if not as fancy or colorful as with MacOS.

AUDIO

The Linux kernel does have Macbook audio support out-of-the-box, maybe. However, Apple tends to make "changes" the audio chipset so that the generic modules do not work. Fortunately, we found a fix to the kernel driver for sound on Macs with Cirrus 8409 HDA chips:

https://github.com/davidjo/snd_hda_macbookpro

This project has a handy script, for those "other" linux distros, to handle patching the kernel source. It will download the kernel source for the running kernel, patch the cirrus driver, and compile and install the new kernel module. The script checks for various "other" distros for the kernel headers, and will exit since Slackware isn't "detected" - as in not even considered. Yes, lots of quotations so I can voice my displeasure without starting a flame war. Fortunately a simple edit fixes this oversight.

To start, grab the repo and put it somewhere (I use $HOME/Builds/audio/ from my normal user):

You will need to edit the installation script to bypass the header check, for example,

or use your favorite editor. Simply add a check for Slackware so that the script skips all the other distro logic. Here is the patch file for the changes:

I was too lazy to customize this script any further, and leave that task as an exercise for the reader. As root, run the script to generate the new module. If already generated the touchbar modules, you should already have dkms installed. Reboot to load the new module. Sometimes, for sound to initialize, you may need to fully power off the Macbook.

Currently, the left speaker is about 1/2 volume of the right speaker. The headphone jack works and audio is balanced. The speakers work properly in MacOS (dual boot), so I suspect something is still a bit off with the audio drivers.

This Macbook Pro has 4 USB-C ports. The 2 on the left are Thunderbolt 3; the 2 on the right are USB3. Any port can be used to charge. I've run into a few glitches where devices aren't fully detected when plugged in, but with a reboot all is well. Also some devices work on either side, some only on the USB3 side. Curiously, I have 2 USB-C hubs with USB-A, C, HDMI and sdcard ports. Both work, but one only reports as USB 2.0. This same hub reports as USB 3 when plugged into a USB-C port port on my AMD Ryzen desktop box. Go figure.

To avoid rebooting, you can try at reset the USB hub or device. On this Macbook, we see via lsusb and lspci

You can try resetting a root hub via sysfs as root, for example, to reset iBridge,

Alternatively, you can also try to reset the entire USB controller. Note: Each Thunderbolt port appears to be on its own controller.

The HiDPI retina display will need some scaling adjustments so that the icons and test for KDE/Plasma or Xfce aren't tiny scribbles. This is easily done in the appropriate settings applet. However, if you use Xfce, but still use the occassional KDE program, as I do, the KDE program will not see the correct scaling factor, even if you previously set it in KDE. To fix this, add to your user's .bash_profile similar

https://forum.xfce.org/viewtopic.php?id=16870

Do not add this globally as it can confuse/override KDE settings.

This was quite the adventure getting everything to work. If you can pick up an Intel Macbook for cheap, it will make a good spare or backup laptop. I use it for general tasks (web, email), as well as streaming our linux user group meetings to Twitch with a GoPro Hero 13 and OBS Studio.

A while ago, Valve added a built-in system for creating and sharing your game play footage in the Steam Client. This makes it easy to record game videos "on the fly" and easily share clips without having to learn OBS Studio and video editing software. Game recording works quite well and was even ported to the Steam for Linux Client.

There is one glitch, however. On Linux, with a AMD GPU, and sometimes with an Nvidia GPU, trying to export a video or video clip from the 'Original' tab results in the error:

"Failed to export, try again"

Not very helpful. This occurs when trying to export in H.265 format - the default format Steam uses to record the video. Turns out this was reported a while back:

https://github.com/ValveSoftware/steam-for-linux/issues/11850

Steam lis looking for libcuda.so.1, even when running on a non-Nvidia GPU. You can export with transcoding to H.264 in the 'Custom' tab just fine. This works fine (you may need to install ffmpeg and the relevant codecs for your linux distro).

I found a workaround in a small blog post:

https://y.tsutsumi.io/reading-steam-game-recordings

To copy the original H.265 stream, look in you Steam directory:

.local/share/Steam/userdata/{id}/gamerecordings/clips

You will see one or more directories of the format:

clip_{game id}_{date_time in UTC}

Locate your game and open the directory. The original vidoe is the in

video/fg_{game id}_{date_time in UTC}

where you with find the video stream *.m4s files as well as the important session.mpd' XML file. Ffmpeg can read mpd file natively, so simply

ffmpeg -i session.mpd -c copy out.mp4

Other container formats compatible with H.265 and AAC audio will work as well. You now have the full original video to copy, upload, modify etc.

Have Fun!

A few months ago I picked up a GoPro Hero 13 cheap as another gadget to play with just for fun. You can review the specification details here. It's a decent enough portable camera for outdoors in the bright lights. Indoors...well not so much. You can read reviews elsewhere; just be a bit skeptical when the reviewer gushes about this camera's capabilities. It has some odd limitations.

For one, webcam mode is limited to 1080p 30fps. Also, you can't save a 4K copy on the sd card while in webcam mode. Nuts.

But this is not a review of the GoPro Hero 13.

I was interested in getting the GoPro to talk to my Linux based computers (Slackware, of course), without having to go through any of GoPro's bespoke apps. The first step to to simply plug in the USB-C cable. Linus recognizes the camera as a MTP device. You can easily upload and download files stored on the sd card.

Each video is stored as 3 files: low resolution video (LRV), high resolution video (MP4), and a thumbnail image (THM). You can even update the firmware manually by uploading it directly to the sd card if you don't like to update OTA via the phone Quik app.

By the way, the official Quik app is now the only official way to access and use the camera. All Windows or MacOS programs are deprecated. Gopro decided that editing and streaming is only for mobile devices. Sure you can operate the camera from the app, stream to Twitch, etc, but you got to do so on your phone, and you better have a fast and solid WIFI connection.

Nuts...but this is not a review.

Fortunately, GoPro has released the entire API to access the camera features programmatically. Unfortunately, access is via a web API. You can find the full API specification as well as tutorials and software examples on the Open GoPro Github repository. There are numerous examples and how-tos on the internet, especially written in Python, but, as I will show you below, some are needlessly complicated, or haven't been updated for the Hero 13 and newer firmware.

For the sake of this "proof of concept" discussion, I'll skip access via BLE and WIFI and concentrate on the USB connection. It turns out that the USB-C port does support standard ethernet TCP/IP networking. Once you plug the USB-C cable in and turn on the camera, a new wired network device will appear. With Network Manager this is automatic; if you are running Slackware without Network Manager, then simply restart the network:

In this example, we have a new device (eth1) and IP address. The camera runs its own DHCP server so that your computer is now 172.2X.1YZ.54 and the camera IP is fixed at 172.2X.1YZ.51. Each camera has a unique IP address. The values XYZ are the last three digits of the camera's serial number. In my case, I will send and receive data from address

http://172.25.148.54:8080

Nice. Now it gets complicated.

Now that we have access, we can start controlling the camera. Following the examples, we can send and receive camera information via an HTTP or curl GET request. For example, to get the camera information via the CLI with curl:

All the camera settings and function can be accessed in this way, including some settings not exposed to the camera settings UI.

So how do we extract a video stream over USB ethernet to use the camera as a webcam? This can get a bit tricky, if you want to use the GoPro camera in most webcam apps, since the software will be expecting the video over V4L2 and /dev/video0 (for example, a standard USB webcam). At this point, the camera behaves like a standard IP camera. To get the video routed to regular webcam apps, you will need to set up a V4L2 loopback device to simulate a USB webcam.

I'll leave that as an exercise for the reader. We will use the IP video stream directly.

Via the web API, we can send the GoPro camera video directly to applications such as OBS Studio, VLC, etc, or process the video directly with ffmpeg.

NOTE: You may need to install a few extra video codecs if these are not automatically included in your Linux distro. For example, you will need at least the codecs for H.264 and aac since this is the video format that the camera transmits.

In my case, I've added aac, x264, x265 and recompiled ffmpeg, VLC, and OBS.

Remember that I mentioned a few "odd limitations"? Streaming video over USB, and setting webcam mode limits the video to 1920x1080 30 fps and h.264 and all the most settings are unavailable. Why? Go ask GoPro.

Enough preamble. It's time to whip the llama's ass!

Once you now the HTTP get commands to use, the next step is find the stream URL. There are 2 ways. You can start a preview stream. This is the same stream as the preview on the Quik app. This stream comes to use as UDP on port 8554 (default). We'll use ffplay, from ffmpeg, to test.

The webcam mode can also stream via RTSP, and this can be handy if you want to grab the stream with several programs. Here is a basic work flow to start webcam mode, start the stream, view, and exit webcam mode. Resolution is set to 1920x1080, Linear aspect ratio, protocol RTSP and port 554:

Here is a simple bash script that puts all these concepts together.

To use OBS, we first start webcam mode. We'll use RTSP for this example, but UDP works as well. If you are going to stream to Twitch, webcam mode is already H.264.

We'll now need to set up OBS to to look at "rtsp://172.25.148.51:554/live". Add the Gopro Media Source to your scene and set the parameters:

If for some reason, the Media Source option is cranky, and you have VLC installed, you can instead create a new VLC Media Source:

Complete the OBS configuration as you require for your streaming pleasure. Webcam mode, if I am not mistaken, has a bitrate of ~2500-3000 Kbps, so keep this in mind when setting up your encoding parameters. If you set OBS to record the stream, be careful with the settings and the capabilities of your computer. Running both streaming and recording processes can overwhelm older CPUs and GPUs.

Although the HTTP API to control the GoPro camera seems a bit convoluted and overly complex to me, it does work well enough to operate the camera as a webcam. I guess this old timer is just not hip to all this web API nonsense. I just wish they would allow

• Higher resolutions, fps, and bitrates in webcam mode.
• Allow access to all the fancy image settings in webcam mode.
• Easier, direct access to WIFI without having to use BLE to enable it.
• Have both the USB and WIFI not use fixed IP addresses via the built-in DHCP server and use just a DHCP client. The camera should connect to your network as just another network device or computer.

Have fun!

Proton provides and officially recommends graphical desktop utility to access their VPN services. Unfortunately, these are supported on just a few "official" Linux distributions. Proton deprecated their bash command line (CLI) version. There is a community CLI version available, written in python, but both of these will be defunct after Proton upgrades their openvpn infrastructure on 31 March 2025.

Therefore, instead of trying get there official client to work (why no offline installer, or simple tar.gz etc archive?), we created our own simple, manual bash script targeting the freely available VPN servers. Thanks goes to a fellowPortland Linux User Group member for script improvements, suggestions and testing.

Proton provides instructions to manually configure both openvpn and wireguard for VPN access. This article will focus on openvpn.

Prerequisits

For this example, since for my Linux configuration, I will need to log in as 'root' user, I created directories under /root for the required files.

Log into your Proton account and download the .ovpn configurations. Also copy the openvpn user name and password you will require into a file, one per line, to 'protonvpn_auth.txt'.

Next, download the 'update-resolv-conf' script, copy to /etc/openvpn and set it to executable. This script will update your /etc/resolv.conf for the vpn tunnel.

If not already done, make sure that the lines

are placed in the .ovpn files so that this resolv script will be executed. Your /root folder should now contain the following tree, for example:

I've placed a copy of the script in the files section. It's functional but still a bit of a work in progress.

protonvpn.sh

Simply open a command shell and login in as root. Then provide the script with the .ovpn country:

Comments and suggestions are welcome: kingbeowulf@linuxgalaxy.org

A year ago, I refurbished a vintage 2007 iMac: 1TB SSD and new(-ish) power supply and it has been working pretty good for the most part.

Installing Slackware64-15.0 on an iMac 2007

Two issue still remain: Bluetooth (BT) and a tendency for the power supply over heat. I still haven't found a solution yet to the BT driver; this will wait for the next Slackware stable release "when it's ready; real soon now."

The mid 2007 iMac did have a tendency to overheat. Having poked around inside, there just isn't enough air flow to cool the power supply which can run extra hot under load. We can adjust the fan speed manually as root, once you figure out which fan cools both the CPU and the power supply. For example:

I was about to cobble something together when I stumbled across a great little daemon to do it all for me. So, why reinvent the wheel?

mbpfan: Adjust fan speed using the applesmc module

mbpfan is a great, simple program to tweak the fan curves when running Linux an a macbook or an iMac.

https://github.com/linux-on-mac/mbpfan

For Slackware (there are other distros?), you can build a nice installable package,

http://slackbuilds.org/repository/15.0/system/mbpfan/?search=mbpfan

For example, to run mbpfan at system boot, add it to /etc/rc.d/rc.local

Then edit /etc/mbpfan.conf as needed:

You may need to experiment a bit for your particular Mac.

Have fun!

Yesterday was the 30th Anniversary Meeting of Portland Linux/Unix Group - one of the oldest LUGs still in progress. Not only did we have cake,

We also had a special guest speaker: Linus Torvalds.

We had a lively discussion of the history and future, and development process, of the Linux kernel, as well as a few random topics.

A while ago, I had started beating on the ROCm build system to try to get a "simple" set of packages for those of us that only need basic OpenCL runtime support on Slackware64. AMD's ROCm includes that but also includes various tools to build HIP and OpenCL GPU compute programs. My prior efforts were the legacy OpenCL binary Ubuntu packages which wasn't very stable due to being compiled on Ubuntu. I had to take a pause due to a few health issues and only recently started looking into this again.

Recently, a post on the Slackbuilds.org mailing list completed what I could not: a set of slackbuild scripts for ROCm-5.5.1

https://github.com/414n/slackbuilds.org/blob/rocm-5.5.1

A big thanks to 414n to sift through and sort all the various ROCm bits and pieces. Much appreciated!

Now that I had a set of build scripts, and nice READMEs for which one does what and a workable build order, I dug up my notes to see which packages are needed to have OpenCL runtime support. AMD sure did not make this easy on package maintainers!

To start, grab a few packages from Slackbuilds.org that are external dependencies:

For rocminfo: numactl

For rocblas (optional package):
python3-wheel
msgpack-c
python3-virtualenv

For rocsolver (optional package):
fmt

Optional (utility):
clinfo
(or use the one provided with ROCm)

Before you build any of these packages, take note of the information and build order below. Rocblas and rocsolver are not required for the OpenCL runtime.

As I mentioned, I sifted through the packages to get a better idea of the build order for ROCm. What follows is the result.

B = build time dependency only
R = OpenCL runtime dependency
U = ROCm/OpenCL utility

The compile/build order in each Build stanza is optional.

Build 1st

rocm-llvm (B)
hsakmt-roct (R)
rocm-cmake (B)
python3-cppheaderparser (B) - included in 414n's git repository ROCm branch.

Build 2nd

rocm-device-libs (R)

Build 3rd

rocm-compiler-support (R)
hsa-roc (R)

build 4th

rocminfo (U)
rocm-smi-lib (U)
rocm-opencl-runtime (R)

The remaining packages are optional and are not required for basic OpenCL support. This includes the HIP runtime and various headers and libraries to build HIP and OpenCL programs.

Build 5th - Optional

rocm-clang-ocl [deprecated Dec 2023 for newer ROCm] (B)
hip-runtime-amd (B,R)

hsa-amd-aqlprofile-bin (optional, binary blob).
A code profiling/analysis binary blob library that is needed only for development and to suppress silly library missing errors.

Build 6th - Optional
in approximate build order

rocrand
rocblas
rocm-core
rocprim
hipcub
rocsparse
hipsparse
rocsolver
hipblas
composable-kernel
half - included in 414n's git repository ROCm branch.
miopengemm
miopen-hip
rocfft
hipfft
rocthrust
hipsolver
hipify-clang
rccl
roctracer

Once the the packages are built, which ones are necessary for just the OpenCL runtime? For basic ROCm OpenCL support:

numactl (for rocminfo)
hsa-rocr
hsakmt-roct
rocm-compiler-support
rocm-device-libs
rocm-opencl-runtime
rocm-smi-librocminfo

That's it!

The following utilities are provided in /opt/rocm/bin that provide

clinfo - OpenCL platform information
rocminfo - ROCm HSA agent information
rocm-smi - GPU status and control

The OpenCL ICD loader may have difficulty locating the correct OpenCL ICD and therefore the correct OpenCL library locations. If this happens (for example BOINC), either move or rename

etc/OpenCL/vendors/mesa.icd

So far, OpenCL works for BOINC and phoronix-test-suite with benchmarks hashcat and clpeak.

I ran across an article in Ars Technica [1] about nifty project DOS_Deck [2] - a cross platform implementation of old DOS in a web browser. DOS_Deck simplifies the process of getting an old DOS game running. No more fiddling; just click and play.

Personally, I've always enjoyed the hours tweaking my old MSDOS configurations, and later, DOSBox on Linux, to get my games running. Although, I do recognize that some may feel that is an exercise in frustration.

They plan to add more examples from the vintage era of gaming.

[1]

https://arstechnica.com/gaming/2023/11/dos_deck-offers-free-all-timer-dos-games-in-a-browser-with-controller-support/

[2]

https://dosdeck.com/

Now that Apple has moved on to their own "Apple silicon", all Intel CPU based Mac computers are on live support - and Apple ready to pull the plug. No more MacOS updates of any kind, even for recent models, as has already happened for the older Mac models. Recall that this is the same process as when Apple transitioned from PowerPC to Intel CPUs.

Granted, Apple does tend to support their hardware a bit longer than the Windows PC crowd, but it is still a shame to have to toss still perfectly good hardware. This post will describe how to breathe new life into a vintage 2007 iMac.

Apple long since pulled the plug on 2007 iMacs. After I replaced a dead power supply, I was perfectly happy with OS X El Capitan (10.11.6 2018) . This was the newest MacOS supported, but was also long past it's support date. Thus aluminum all-in-one is still a nice looking computing appliance, with a nice 24-inch 1920x1200 LCD screen. Full Specifications can be found here:

https://everymac.com/systems/apple/imac/specs/imac-core-2-duo-2.4-24-inch-aluminum-specs.html

This iMac already had been upgraded to 4GB DRAM, and after I replace the dead power supply, I swapped the old hard drive with a spare Samsung EVO 750 SSD.

A good place to start for instructions on how to crack open a Mac and for parts, check out ifixit. Recommended.

https://www.ifixit.com/

Both the standard Slackware installer DVD or USB drive will boot up. However, I recommend the Slackware Live Edition (currently version 1.70, "liveslak"). The install and setup is a bit easier.

https://download.liveslak.org/

Information and details about liveslak can be found here:

https://docs.slackware.com/slackware:liveslak

liveslak was developed by long time Slackware contributor Alien BOB. Recommended.

The liveslak I selected provides for KDE/Plasma and XFCE desktops. Editions with Cinnamon, Mate desktops, as well as a customized Digital Audio Workstation (DAW), are available. For the adventurous, the development branch, Slackware-Current, can be downloaded.

Please note: I am assuming you are familiar with the regular Slackware installation process. If you run into issues, I can provide some assistance. Post on Linuxquestions.org, email me, or see if I am active on IRC (#linuxgalaxy libera.chat)

Insert the live DVD or USB drive and power on the iMac. Hold the OPTION key (alt on non-Mac keyboards), until you here the boot chime. Eventually, a list of EFI boot devices will be available. You will see something similar to:

Select the EFI USB icon to boot the USB. The DVD version will be a DVD icon. Ignore the Windows icon if present - that is for hybrid media that can also boot via DOS/MBR.

After the boot process (and this may be a bit slow), log in with the "live" user with password "live". The root password is "root". To install, click the installation icon in the upper left corner and follow the instructions. if you logged in as "live", then provide sudo with the "live" password.

First, choose 'yes' to GPT partition your hard drive. I recommend something similar to the following (partition names are optional) with swap roughly twice the RAM:

Save the new partitions and continue with the installation. When you get to the lilo/elilo install section, skip both. Neither work with Macs. Will set up grub instead later.

Once done the installer will exit and you will still be in the liveslak environment. Do not reboot yet! Now we need to set up a grub as the boot loader. Open a terminal and "su -" change to root if needed. Verify your partitions:

Now wee need to chroot into the new Slackware installation. For details, refer to

https://docs.slackware.com/howtos:slackware_admin:how_to_chroot_from_media

Next, let's get this drive set up to but with grub. These instructions were adapted from

https://docs.slackware.com/howtos:slackware_admin:set_up_grub_as_boot_loader_on_uefi_based_hardware

If you receive a message similar to "UEFI variables not supported on this machine," you will need to exit the chroot and mount the EFI variables:

Then hop back into the chroot and re-run the grub-install command. Once grub-install completes successfully, continue with

Now, exit the chroot environment and reboot the iMac. Remember to remove the USB drive, etc.

Enjoy Slackware on your recycled iMac!

On the iMac 2007, everything worked out-of-the-box (so far!) except for wifi and bluetooth (BT). The wifi chipset is Broadcom BCM4321. The b43 kernel driver and needs the appropriate firmware which you can install via Slackbuilds.org

https://www.slackbuilds.org/repository/15.0/network/b43-firmware/

I haven't looked into what drivers are needed to get BT working yet. Stay tuned.

Older Macs may have a few issues booting due to corrupted SMC and PRAM.

1. iMac powers on, fans and DVD spin up, but screen stays blank/blank. Reset SMC: hold power button for 15 seconds. On some Macs, hold down the Shift+Control+Option keys and the Power button at the same time. If that does not work, unplug the power cable for 10-15 minutes.
2. iMac sound boot chime but screen stays gray. Try to reset SMC as above. If that does not work, reset PRAM: power off then on again. At the boot chime hold "Command+Option+P+R" keys until next boot chime (gray/chime - blank - gray/chime). If you get the flashing ? file folder icon after reboot or power cycle, boot into liveslak and repeat the grub-install/grub-mkconfig steps.

Given the size and weight of discreet GPU cards the past few years, GPU support brackets have become popular to prevent sag (tower cases with GPU mounted side-ways) and thus potential damage to the GPU and motherboard. Most current motherboards, say last 5 years os so, feature at least one reinforced PCI-express x16 slot for these heftier cards. GPU manufacturers also have balanced the card and trimmed the weight a bit as well. However, we often see recommendations to add a GPU support bracket to your new or existing build. Is this support required?

Generally, no. If you do see significant GPU sag, first check the end bracket connection and make sure the card is fully seated in the slot. Some larger cards can be a bit difficult to get snapped in correctly in a tight space.

Case in point: XFX Radeon RX 5700 XT THICC Ultra III

This is a massive card, heavy, and dwarfed my prior 900- and 1000-series Nvidia GPUs. It was a very tight fit in my large full tower Antec P100 case and seemed to wobble a bit. So I used a twist tie to provide a bit of lift.

No need to spend money on some silly piece of plastic or metal.

The new Sapphire Pulse Radeon RX 6800 XT Gaming OC is quite a bit lighter, but I strung it up just in case!