Slackware - ARMThis forum is for the discussion of Slackware ARM.
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.
Thanks for the added background. I still have to get through this whole thread, so looking forward to some good reading this weekend, but I'll address a couple of points that jumped out at me on a quick lookover.
Quote:
Originally Posted by Exaga
[EDIT]
There's no need to run the mkinitrd unless you intend to create an initial RAM disk image. Is that an x86 thing?
It is an x86(_64) thing if you switch from the default huge kernel to the generic kernel, as I've done on my x86_64 Slackware 14.2 and Slackware -current installations. Upgrading kernel packages using the steps I do (while new and previous kernels are still installed), after each kernel upgrade, you must create an initrd by first running the script
then running the command it generates, manually substituting in the new kernel version number (since the command script picks up the version number of the previous, still installed kernel.)
Then if all goes well (which it usually does) I'll then reboot the system and hopefully it will be successful and use the new versions.
That's a key condition for me. I have had kernel packages install incorrectly a couple of times. I have installed a wrong kernel package. Upgrading kernels step-by-step this way, although more time consuming than a batch run, prompts me to look at the output each time I run installpkg or upgradepkg. I'm more likely to catch and fix an error before I go on to break more things. I would rather do that, certainly on my main (14.2 on x86_64; less critical on my arm and trial x86_64 -currents) than to puzzle out and fix later what went wrong, even if occurrence is rare. I accept the tradeoff of not going through those occasional "learning experiences" :-).
OK. One thing you may not be aware of is that the Raspberry Pi's '/boot' partition _MUST_ be FAT32 - if you're using the proprietary Raspberry Pi boot-firmware.
Yes, I'd already picked up on that, but wasn't aware why! Thanks for the explanation!
I have no problems with the way you are going about things, so please don't think I'm being critical! I'm not! But I DO want to run 64-bit, and at the moment, the only option for that is slarm64. I did have problems with the slarm64 boot process, which I was never completely able to resolve on the Pi 400, despite sndwvs excellent efforts. Your description gives me some indication why!
Thanks also for the links both here and in the other (related) thread. The information is out there, but you need to know where to look! I now have a few pointers!
Upgrading kernel packages using the steps I do (while new and previous kernels are still installed), after each kernel upgrade, you must create an initrd by first running the script
I hear you. It's such a long time since I've done anything like that. Seem to have a faint recollection of doing this in times gone by.
That's a key condition for me. I have had kernel packages install incorrectly a couple of times. I have installed a wrong kernel package. Upgrading kernels step-by-step this way, although more time consuming than a batch run, prompts me to look at the output each time I run installpkg or upgradepkg. I'm more likely to catch and fix an error before I go on to break more things. I would rather do that, certainly on my main (14.2 on x86_64; less critical on my arm and trial x86_64 -currents) than to puzzle out and fix later what went wrong, even if occurrence is rare. I accept the tradeoff of not going through those occasional "learning experiences" :-).
When I mess things up on Slackware it's a big, big problem that I try hard to avoid. When I mess things up on Slackware ARM it's a few mins re-writing the image and copying over whichever files I need. Sometimes with the latter I'll re-install from scratch, just to have a fresh start and the chance to revise my methods. HAHA!
Thanks also for the links both here and in the other (related) thread. The information is out there, but you need to know where to look! I now have a few pointers!
No problem. Asking is always the best policy with Slackware ARM. In this LQ forum we don't have any 'one-upmanship' or competitions between users to project themselves as the most learned gurus, or each user offering a 'better' solution than the last. Unless someone actually does, and then it's usually addressed and dealt with very graciously.
I don't think you're being critical at all. You're doing what you like/want to do, and that's admirable. SARPi has [had] its critics and objectors. As long as the Slackware Team guys are OK with how I do things, that's all that matters. I try to make it as good at it can possibly be and then, at least, I know it's on the right trajectory.
I did notice some weird hanging when upgrading and rebooting - but only for the first time - on the RPi3 and RPi4 - but not on the RPi (1) and RPi2. After powering off-on and getting past the first reboot it seems to operate within established parameters very well indeed.
The hang was something to do with the bootloader because it didn't even attempt to load the kernel. If it's a boot-firmware issue that caused it then I'm sure the RPi guys will be aware and on top of it. I'll be keeping an eye on any similar incidents when I build the next SARPi batch.
Just upgraded to 5.10.4 on RPi4, but unlike my smooth 5.10.2 upgrade and like your 5.10.2 upgrade, I got a hang - it stopped at "Rebooting". Power off-on [edit: for the first reboot only] and with several flawless reboots after, I can confirm that, like for you, it only hung at first reboot after upgrade.
(then first reboot with hang, power off-on, subsequent reboots ok.)
Reviewing a difference in installed kernel and sarpi packages on my RPi between these two upgrades: I still had a couple of SlackwareARM packages before the upgrade to 5.10.2. I replaced those with Sarpi packages before the 5.10.4 upgrade. Could the cause of the first-reboot hang be there, or is it more likely to originate in the boot-firmware or elsewhere?
- Before upgrade to 5.10.2, flawless first reboot following upgrade
If the worst that happened during upgrade is a hang on first reboot, then I'm not worried.
Happily running SlackwareARM -current with 5.10.4 on RPi4!
Thanks very much for posting your results TKS. I'm thinking, "damn this issue!" It could be one of those headache boot-firmware niggles (again).
For me this time around with kernel 5.10.4 everything went perfectly on the RPi3/4 but it wasn't on the RPi2. Like your experience, and as before with my own, power off/on was successful the second time around, and every subsequent occasion.
The RPi (1) is also suffering a hang on boot, right before networking is initialised, but it *is* eventually successful. Having previously booted as expected with kernel 5.10.2, I'm currently looking into what could be causing it. Very strange indeed.
The RPi (1) is also suffering a hang on boot, right before networking is initialised, but it *is* eventually successful. Having previously booted as expected with kernel 5.10.2, I'm currently looking into what could be causing it. Very strange indeed.
Looking in /etc/rc.d/rc.M: right before the network gets set up (rc.inet1), the entropy-gathering haveged is started (rc.haveged). Do you see the line "Starting haveged entropy daemon" before the delay, or after?
I am very interested in narrowing down the culprit program, and figuring out what's going on under the hood. Entropy gathering is my first suspicion, from this thread: https://www.linuxquestions.org/quest...on-4175680148/ (disclaimer: I popped up a few times in that thread).
But note that entropy-gathering in the kernel was significantly re-worked in v5.6 by eliminating the blocking pool and pushing responsibility for crypto-secure into user-space.
As a side question: maybe you also have a file /etc/rc.d/rc.rngd ? It can get called after setting up haveged. I find references to "rngd" in the SBo packages "rng-tools" and "onerng". Do you have either of those packages installed?
Looking in /etc/rc.d/rc.M: right before the network gets set up (rc.inet1), the entropy-gathering haveged is started (rc.haveged). Do you see the line "Starting haveged entropy daemon" before the delay, or after?
I am very interested in narrowing down the culprit program, and figuring out what's going on under the hood. Entropy gathering is my first suspicion, from this thread: https://www.linuxquestions.org/quest...on-4175680148/ (disclaimer: I popped up a few times in that thread).
That's not a disclaimer. That's an accreditation!
Quote:
Originally Posted by gus3
But note that entropy-gathering in the kernel was significantly re-worked in v5.6 by eliminating the blocking pool and pushing responsibility for crypto-secure into user-space.
As a side question: maybe you also have a file /etc/rc.d/rc.rngd ? It can get called after setting up haveged. I find references to "rngd" in the SBo packages "rng-tools" and "onerng". Do you have either of those packages installed?
Very many thanks for this advice. I don't have '/etc/rc.d/rc.rngd', or the 'rng-tools', or 'onerng' pkgs installed. I do have 'haveged-1.9.13' pkg installed on Slackware ARM current, but not on the RPi (1) Slackware ARM 14.2 version.
OK! So, aside from not believing this was a Slackware ARM 14.2 problem, unequivocally because there has been only one pkg update since the start of this issue and now - and that was 'glibc-zoneinfo*.txz', the timezone database, which has no bearing on this what-so-ever - I wasn't willing to make any changes to the OS infrastructure in any case. Experience has taught me that, under these circumstances, it's a complete waste of my time when there are inklings of the bespoke RPi boot-firmware being the culprit.
Yesterday there were changes to a few files in the RPi Github Linux kernel source and a new boot-firmware commit. So I've built and tested accordingly and found that the strange boot-hang has now been resolved and the Raspberry Pi (1) is now booting, loading the kernel and the Slackware ARM 14.2 OS as expected. However, the device suffered the "initial reboot-hang after upgrading" problem as I'd experienced on other RPi devices. On all subsequent reboots it seems to work perfectly.
As a consequence I am done with this and this and have looked into the permutations of the 'shutdown', 'halt' and 'poweroff' commands. I'm very much open to advice on this one because I've wasted enough time on it already. So, perhaps somebody might be so kind as to apprise me of their most assured and/or correct way of shutting down and rebooting the system successfully. Thanks in advance for sharing any experience(s) with this.
I updated my RPi 2 a couple hours ago, with the latest firmware and kernel packages from Exaga. No hiccups at all.
A WD Pi Drive is my primary, but /dev/mmcblk0p1 is mounted on /boot.
I did a straight "upgradepkg." And I took the plunge, as a test, to see if I'd get through it unscathed. The package order: firmware, headers, kernel, modules. (I skipped the hacks package, since I already took care of those on my own, a couple years ago.)
Once the packages were upgraded, I flushed buffers and rebooted. The re-start was successful, with no hangs or anything. It went straight from "reboot" command to a new kernel with a login prompt, with no manual intervention required.
I updated my RPi 2 a couple hours ago, with the latest firmware and kernel packages from Exaga. No hiccups at all.
Thanks for the feedback gus
Today I've built, tested, and uploaded a new SARPi batch running RPi kernel 5.10.6 which seems to be working as expected without any errors. RPi (1) is still building and will be another day or so before that becomes available.
I skipped kernel 5.10.5 source because I became somewhat bemused with sifting through device drivers and kernel objects trying to find out what was terminally corrupting the ext4 root filesystem on the RPi2 and 3.
I skipped kernel 5.10.5 source because I became somewhat bemused with sifting through device drivers and kernel objects trying to find out what was terminally corrupting the ext4 root filesystem on the RPi2 and 3.
Does this article show any resemblance to your issue?
I can't say because that article requires a subscription/login to view the information.
Sorry, I forgot all about that.
I checked your two GitHub links, and no, it's nothing like I thought it was. The link I gave was about how a compiler bug in GCC 4.9 for arm64 caused a use-after-free error on the kernel stack, specifically affecting the ext4_chksum() function. The resulting bug in the kernel has a window of exactly one instruction, during which an interrupt can corrupt the stack frame and overwrite the calculated checksum.
The mis-compilation was fixed six years ago, during pre-5.0. But there are two catches: the kernel still (officially) supports compilation with GCC 4.9, but not everyone has upgraded their GCC set with fixed 4.9.x versions.
(For the nerds: ext4_chksum() returned a value from a de-referenced pointer, a la
Code:
return *(u32 *)desc.ctx;
It turned into "fetch desc; free local stack space; get ctx from desc, but hopefully before an interrupt occurs...." The problem is that ctx is a member of desc, and desc has already been freed from the stack. The compiler lost the "live data" attribute between the desc structure and the ctx inside it. Hence, the ctx member could get over-written by an interrupt.)
No problem gus. I am an occasional visitor to that site, especially for the https://lwn.net/Kernel/ content. There's quite a lot of very insightful and educational information available for Linux in general on there.
The issue with the RPi kernel 5.10.5 was a strange one. Networking would fail/crash and the root filesystem superblock was somehow removed/deleted. Trying to repair the ext4 filesystem left me with a 'lost and found' folder and nothing else. Trying to restart networking was futile. So, it was a very terminal fault and I wasn't able to pinpoint the cause. However, it was fixed (thankfully) quite quickly in the next kernel release.
=> Is sarpi4-hacks-4.0-armv7l-1_slackcurrent_17Jan21_sp1 not supposed to make changes to rc.local?
- All of these rc.modules are in /etc/rc.d
Code:
-rwxr-xr-x 1 root root 778 Dec 15 2015 rc.modules*
-rwxr-xr-x 1 root root 1745 Dec 25 06:04 rc.modules-5.10.2-v7l-sarpi4*
-rwxr-xr-x 1 root root 1745 Jan 2 01:44 rc.modules-5.10.4-v7l-sarpi4*
-rwxr-xr-x 1 root root 1745 Jan 17 03:37 rc.modules-5.10.7-v7l-sarpi4*
-rwxr-xr-x 1 root root 1745 Dec 1 02:43 rc.modules-5.4.80-v7l-sarpi4*
-rwxr-xr-x 1 root root 689 Dec 15 2015 rc.modules.local*
=> Is there any reason *not* to delete all but the most recent rc.modules-5.10.7-v7l-sarpi4? (rc.modules.local can stay for possible future use, as there is nothing uncommented.)
- consolekit is in /etc/rc.d
Code:
-rwxr-xr-x 1 root root 572 Nov 29 2018 rc.consolekit
=> Now that ConsoleKit2 is gone from -current, is there any reason not to delete this?
So here is the order of steps I took for this upgrade. It seems to work so I'll stick with it unless I hear of a good reason to change it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
and this 
and have looked into the permutations of the 'shutdown', 'halt' and 'poweroff' commands. I'm very much open to advice on this one because I've wasted enough time on it already. So, perhaps somebody might be so kind as to apprise me of their most assured and/or correct way of shutting down and rebooting the system successfully. Thanks in advance for sharing any experience(s) with this.
Sorry, I forgot all about that.
