LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM
User Name
Password
Slackware - ARM This forum is for the discussion of Slackware ARM.

Notices


Reply
  Search this Thread
Old 08-12-2019, 02:06 AM   #1
elyk
Member
 
Registered: Jun 2004
Distribution: Slackware
Posts: 241

Rep: Reputation: 49
SARPi out of space in /boot


I was about to pull the trigger on upgrading the kernel-sarpi stuff when I noticed this:
Code:
# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        29G   13G   14G  48% /
devtmpfs        341M     0  341M   0% /dev
tmpfs            32M  564K   32M   2% /run
tmpfs           469M   14M  456M   3% /dev/shm
cgroup_root     8.0M     0  8.0M   0% /sys/fs/cgroup
/dev/mmcblk0p1  107M  107M  2.0K 100% /boot
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.
 
Old 08-12-2019, 02:46 AM   #2
pan64
LQ Addict
 
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 21,804

Rep: Reputation: 7306Reputation: 7306Reputation: 7306Reputation: 7306Reputation: 7306Reputation: 7306Reputation: 7306Reputation: 7306Reputation: 7306Reputation: 7306Reputation: 7306
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.
 
Old 08-12-2019, 06:15 AM   #3
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware AArch64
Posts: 1,043

Rep: Reputation: 665Reputation: 665Reputation: 665Reputation: 665Reputation: 665Reputation: 665
Quote:
Originally Posted by elyk View Post
I was about to pull the trigger on upgrading the kernel-sarpi stuff when I noticed this:
Code:
# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        29G   13G   14G  48% /
devtmpfs        341M     0  341M   0% /dev
tmpfs            32M  564K   32M   2% /run
tmpfs           469M   14M  456M   3% /dev/shm
cgroup_root     8.0M     0  8.0M   0% /sys/fs/cgroup
/dev/mmcblk0p1  107M  107M  2.0K 100% /boot
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.
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.
 
Old 08-12-2019, 09:19 PM   #4
elyk
Member
 
Registered: Jun 2004
Distribution: Slackware
Posts: 241

Original Poster
Rep: Reputation: 49
Code:
# ls /var/adm/packages/kernel*
/var/adm/packages/kernel-firmware-20190726_dff98c6-noarch-1
/var/adm/packages/kernel-headers-4.19.65-arm-1
/var/adm/packages/kernel-modules-sarpi3-4.19.56-armv7-1_slackcurrent_27Jun19_sp1
/var/adm/packages/kernel-source-4.19.65-arm-1
/var/adm/packages/kernel_sarpi3-4.19.56-armv7-1_slackcurrent_27Jun19_sp1
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.

Code:
# ls /boot
COPYING.linux             bcm2710-rpi-cm3.dtb  kernel7.img
LICENCE.broadcom          bcm2711-rpi-4-b.dtb  overlays/
README                    bootcode.bin         start.elf
README-kernels.txt        cmdline.txt          start4.elf
README.boot               config.txt           start4cd.elf
System.map                fixup.dat            start4db.elf
bcm2708-rpi-b-plus.dtb    fixup4.dat           start4x.elf
bcm2708-rpi-b.dtb         fixup4cd.dat         start_cd.elf
bcm2708-rpi-cm.dtb        fixup4db.dat         start_db.elf
bcm2708-rpi-zero-w.dtb    fixup4x.dat          start_x.elf
bcm2708-rpi-zero.dtb      fixup_cd.dat         version-kernel_sarpi3.txt
bcm2709-rpi-2-b.dtb       fixup_db.dat         version-sarpi3-boot.txt
bcm2710-rpi-3-b-plus.dtb  fixup_x.dat          version-sarpi3-installer.txt
bcm2710-rpi-3-b.dtb       initrd.gz
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?
 
Old 08-12-2019, 10:11 PM   #5
elyk
Member
 
Registered: Jun 2004
Distribution: Slackware
Posts: 241

Original Poster
Rep: Reputation: 49
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:
Code:
# ls
README-kernels.txt  README.initrd@
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).
 
Old 08-13-2019, 08:50 AM   #6
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware AArch64
Posts: 1,043

Rep: Reputation: 665Reputation: 665Reputation: 665Reputation: 665Reputation: 665Reputation: 665
Quote:
Originally Posted by elyk View Post
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?
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.
 
Old 08-13-2019, 09:43 PM   #7
elyk
Member
 
Registered: Jun 2004
Distribution: Slackware
Posts: 241

Original Poster
Rep: Reputation: 49
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.
 
Old 08-14-2019, 01:16 AM   #8
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware AArch64
Posts: 1,043

Rep: Reputation: 665Reputation: 665Reputation: 665Reputation: 665Reputation: 665Reputation: 665
Quote:
Originally Posted by elyk View Post
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.)
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).

Quote:
Originally Posted by elyk View Post
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.
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;

Code:
~# echo b > /proc/sysrq-trigger
and to shut down using SysRq trigger you'd type;

Code:
~# echo o > /proc/sysrq-trigger
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.

Last edited by Exaga; 08-14-2019 at 03:39 AM. Reason: grammar and more coffee
 
  


Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] SARPi install, missing boot partition DBLouis Slackware - ARM 10 03-05-2018 01:21 PM
SARPi website new URL - sarpi.co.uk Exaga Slackware - ARM 4 01-28-2018 06:36 PM
FatDog SARPi - one site to rule them all Exaga Slackware - ARM 9 12-03-2016 03:47 AM
[SOLVED] Sarpi Website Down. Need How-To and ISO files... Nh3xus Slackware - ARM 5 11-27-2016 02:26 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM

All times are GMT -5. The time now is 10:32 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration