SARPi out of space in /boot
 

I was about to pull the trigger on upgrading the kernel-sarpi stuff when I noticed this:
Only 2K free space in /boot makes me nervous if any of the files within decide to grow a bit larger. Does anyone else have a similar amount of free space? Any problems due to it? I believe I followed all the installation instructions correctly, I don't remember ever resizing this partition.

probably you need to remove old boot images. You won't be able to upgrade next time if the system wanted to install a new image.

Sorry for wasting 2Kb space.

Would you mind advising me on which SARPi image/packages and RPi version you're working with please? It's way more facilitating to advise others using hard facts rather than my crystal ball. ;)

Don't forget the /boot dir on the Slackware ARM installer for the RPi is only temporary. The initrd is loading into RAM and is deleted at the end of the installation process... this happens before you install any new /boot files. So, there's lots of /boot wasted space as a consequence after that. There's an explanation of this [i.e. what you're concerned about] in the SARPi "Slackware ARM on a Rapberry Pi installation tutorial" and why it is the case. Obviously you either haven't seen it, or have skipped that bit. :D

The two sarpi3 packages have a July 3rd timestamp, so that's when I originally installed it. Whatever the state of -current was at that time.

I did remove the kernel_armv7 and kernel-modules-armv7 packages during the installation.

I see an initrd.gz but I swore I deleted one as part of these instructions. This is safe to remove, right?

I'm missing README.initrd from the sarpi3-boot-firmware package. Maybe I deleted that instead of initrd.gz, but then I may not have had enough space to install the sarpi3 packages, and I would have had to delete it after installing them. Doesn't make sense.

Also I see version-sarpi3-installer.txt and README that aren't in any package. Not sure how they got there. Now that I think about it, there was something weird with mounting /mnt/boot, seemed like files already existed there. Then I remember the reboot didn't work, and it had something to do with /mnt/boot not unmounting. Might have something to do with the reason for the reboot -f suggestion.

Something that struck me as weird, if I follow the installation steps in order, I uninstall kernel_armv7 (has stuff in /boot, or probably /mnt/boot at the time), then mount /mnt/boot, then remove more stuff from /mnt/boot (the initrd.gz), then install new packages to /mnt/boot. Is that what is going on? Is /mnt/boot already mounted and I'm confusing it by trying to mount again?

Or is it that /dev/mmcblk0p1 isn't mounted as /mnt/boot when packages are being installed? If I unmount /dev/mmcblk0p1, I see two files in /dev/mmcblk0p2's /boot:
README-kernels.txt had to come from aaa-base.

There's the missing README.initrd, but it's a symlink. Had to come from the mkinitrd package.

Those two would remain in /boot after removing kernel_armv7 and kernel-modules-armv7.

Then mounting /dev/mmcblk0p1 as /boot would shadow them, and somehow initrd.gz, README, and version-sarpi3-installer.txt somehow got transferred here. That's the only remaining mystery I think.

Then when I upgraded mkinitrd (I just noticed that the August 5th update "upgrades" mkinitrd from build number 12 to build number 1, but the version number is unchanged), that would have removed /boot/README.initrd and would try and fail to replace it with a symlink (since it's on a vfat partition).

Technically, the initrd.gz is safe to remove after you have loaded it into RAM and that could be 5 seconds after the OS has loaded to the command prompt. After you've booted into the Slackware ARM installer you can re-configure your system entirely and remove all partitions before setting them up the way you need them to be. The initrd.gz is fundamentally MoZes' miniroot filesystem with added bits so that it works on the Raspberry Pi.

You can blame Dave Spencer for the version-sarpi3-installer.txt file. That was his idea and I very much liked it. So, it's staying for the foreseeable future. Blame Dave for having good ideas!

You might think the installation of SARPi kernel packages is strange and sometimes it might be. When MoZes releases a new kernel there's every possibility that it will be younger than any SARPi kernel(s). So, you could in fact be uninstalling a newer kernel that's included with Slackware ARM from MoZes, and installing an older kernel from SARPi. The same could happen if you were installing Slackware ARM using an older SARPi version.

You don't need to mount /boot but of course you can do it manually if you so choose. Slackware 'setup' process will do this for you when setting up non-Linux partitions [i.e. the FAT32 /boot partition]. You will already know that the Raspberry Pi requires /boot to be a FAT32 filesystem in order to boot the device.

I don't know which instructions you are referring to but what you're doing doesn't seem familiar to me. Therefore I'd assert that I had no part in formulating said instructions. :)

I think I've figured everything out now. The installer image is basically the original contents of /boot after a fresh install, plus the 3 "extra" files I found that weren't part of any package (initrd.gz, README, and version-sarpi3-installer.txt). The /dev/mmcblk0p1 partition is sized so that all those files take up 100% of it. I must have botched the step where you're supposed to delete initrd.gz. But since the sarpi3 packages are already identical to everything in /boot, installing them didn't take up any extra space. (However it did update the timestamps on those files, because vfat timestamps are weird, and those 3 extra files weren't updated.)

So the main effect of installing kernel_sarpi3 and sarpi3-boot-firmware is to put those already-existing files under the package manager's control. Uninstalling the kernel_armv7 stuff probably isn't strictly necessary since those files are hidden when /boot gets mounted. But removing them frees up some space and avoids problems if they were to be upgraded (old files that are hidden wouldn't be found, new files would end up on the vfat /boot partition).

I've got some other questions about the kernel but they belong in another thread.

Hmmm... sort of. The SARPi disk image /boot files are designed to facilitate the installation of Slackware ARM. That's their only purpose. The /boot files after installation obviously don't include the initrd, but will be the same kernel, modules and boot-firmware versions to keep things simple. The /boot partition [in 2012] used to be 50Mb max. and today it's ~130Mb. It's always been a case of juggling with the size of the partition to fit everything on it. After I'm done with bastardising MoZes' minirootfs to include all the Raspberry Pi shizzle required in order to boot the device, it's footprint on the system is almost 100Mb larger. It's a trade-off solution for a solution, if you get what I mean. There are other ways and means of achieving the same thing but in order not to convolute the process and keep it as straight-forward as possible, this is how SARPi does it. Back in 2012 when we first started this project we followed Dave Spencer's work [Dave's Collective] and fashioned our own Slackware ARM installer and packages to support the device because the only support at that time was in the form of pre-installed images, which is someone else's idea of how to 'install' Slackware ARM. Since that time we have just continued using the same format and configuration because it just works. The 'extra' files which aren't in packages are for information only and do not impress on the system what-so-ever [the README, and version-sarpi3-installer.txt files, etc.]. As for the size of the /boot partition, there's no difference between having 2Kb or 200Mb free space where installing Slackware ARM is concerned. You will see the size and free space of the /boot partition change frequently in the SARPi disk images.

As with any installation of Slackware [ARM] you can modify and change settings, package selection, and configure many other system parameters, during 'setup'. There's no difference at all in the Slackware ARM installer which SARPi provides and the bona fide official version from MoZes. Those files, the entire installation process, and every other established Slackware process or procedure, are inviolable as far as I'm concerned. If I ever feel there's room for improvement in that respect it will be addressed via the appropriate channel(s).

Yes. The kernel armv7 stuff is clean and pristine and beautiful. The stuff you're replacing it with is hacked, butchered, and patched all the way to Hell and back in a hand-basket. Enjoy!

I forgot to mention 'reboot' and yes I am aware there is an issue. If 'reboot -f' isn't working as well, invoke the magic SysRq key function to shut down or reboot the system. You can thank MoZes for this information because he kindly apprised me of the SysRQ functions when I briefly spoke to him about the 'reboot' issue.

So, to reboot the system using SysRq trigger you'd type;

and to shut down using SysRq trigger you'd type;

Be careful with the magic SysRq key. It instructs the kernel directly outside of userland. I advise everyone that it's prudent to learn about it before playing with it. Only 'root' can use it. So, be careful. :)