You will notice: https://gitlab.com/sndwvs/images_bui...s/broadcom.inc

Slarm64 uses the Raspberry Pi kernel. There is nothing to talk about. I am not arguing or debating. I am stating the facts. If you would like to discuss this further, please create a new thread.

@enorbet - Sorry for the off-topic.

Well I am making some little progress but it is frustratingly slow. Again thank you for the Uboot link since some web searched info notes that "Rockpro is different" but doesn't explain beyond that note.

Mostly my frustration is due to be because of my x86 training and prejudice and that I generally dislike system configuration automation and I despise inconsistencies. One inconsistency is that on one install I got a dialogue asking me if I wanted to use the installer sdcard as /boot and delete the packages. I messed up by choosing what seemed to be the only possibility to continue and allowed /boot to be on the installer card. When I realized my error I again wiped the SDD and created /dev/sdd1 as Swap, /dev/sdd2 as /boot, and /dev/sdd3 as SlackRoot.

Since I knew removing the installer would change disk labels I made sure /etc/fstab was all "LABEL= foo" so the system would be sure to find the correct locations. It hasn't worked and apparently I haven't found the Uboot-SP1 flasher you provided, and which I definitely prefer allowing early USB and drive access, so it still fails to boot.

When re-installing yet again, this time there was no dialog regarding /boot and I have no idea what triggers that. So as of today I can only boot AarchSlackware64 on my RockPro64 IF the installer microSD is inserted. I don't like it so I have miles to go.

I also don't understand why /usr/sbingeninitrd is present but fails to run. telling me no /var/lib/pkgtools/setup/setup.01.mkinitrd exists.

I'll apparently have to read up on mkinitrd since I never use one on x86 and the default installed one may be a problem with seeing either SATA or USB drives. <sigh>

The tool you want to generate initrd is "os-initrd-mgr" and is one of the differences between x86_64 and Aarch64. The man page is fairly easy to make sense of if you are used to geninitrd or mkinitrd on x86. You may need to verify that your partitions are labeled.

Changing the LABEL in /etc/fstab without actually having the right disk labels will not work. The installer will handle disk labels and the installer will in fact use the SD card as /boot by default.

Checkout https://docs.slackware.com/slackware...3399_rockpro64 for more details.

Thank you once again mralk3 but some discourse...

No. I am not at all familiar with anything regarding initrd as I have never encrypted ROOT and always and immediately build a custom kernel that doesn't require initrd. So I will need to bone up on mkinitrd if nothing else works.

By "actually having the right disk labels" do you mean "right" as in spelled and identified correctly or do you mean by some special propriety? To be perfectly clear, the /dev/sdc2 partition which is assigned to and contains "/boot" is labeled "SLKboot" and that's exactly how "LABEL = SLKboot" in /etc/fstab.

I want the uBoot installer image you kindly put together for me a few months ago and since I am not certain I have it, and it's no longer at "Brent/testing". I'd love the link if you don't mind. It does exactly what I want.

If you mno longer have it or have had problems with it I'd like to know about it but I don't want you to go to the trouble of rewriting.

This.
I no longer have the installation image. That image was taken down due to having an outdated kernel. The main change I made was to enable the keyboard via USB support. This is already implemented in the official installation image.

You can find the most recent RockPro64 installer here: https://slackware.uk/slackwarearm/pl...rch64-current/

Currently the boot image is called: rk3399_generic-sdimg_5.18.19_1.img.xz. This image will be recreated on each kernel upgrade within Aarch64 -current.

The Rockpro64 recovery image will erase SPI flash, downloaded here: https://slackware.uk/slackwarearm/pl...covery/rk3399/

EDIT: My USB keyboard would only work on my RockPro64 if I plugged it directly into the USB 2.0 port. U-boot did not find my keyboard while plugged into my USB hub in either USB 2 or 3 port. Plugged directly into the USB 3.0 port, U-boot did not find my keyboard.

I'll get back to you after tonight on the installers but maybe I could give a little something back by informinmg you that the Logitech K400+ wireless keyboard/trackpad combo has worked perfectly for me and only uses 1 USB since they are combined. I'm not overly fond of trackpads but saving a port is great and I got a bit used to ersatz mice with an older PS/2 no-name keyboard and trackball combo. The Logitech is pretty cheap here and has never failed no matter what I try it on.

I need to tidy up some and I'd prefer not requiring a boot MicroSD but I'm back up and running decently. Thanks for all your patient assistance.

BTW I am glad to see the initial issues that made it temporarily necessary to disable early USB have been solved and the default is now better for it. Is there a way to have Uboot accessible for examination and editing? Certainly I am heavily biased but I sorely miss some feature like BIOS/UEFI that displays fundamentals and provides the means to tweak. For example I'd very much like to have my CPU fan run immediately upon startup rather than at the very end of the boot process. I'd like to know how drives are assigned designation BEFORE I have to go through the entire boot process.

U-boot is not a BIOS or UEFI firmware. Its only goal is to find the boot assets, boot them, and enter user space. You can edit u-boot settings right in the u-boot console before your boot menu is displayed. Tap space bar or escape before the countdown finishes. Then you can easily edit u-boot variables.

I recommend you leave the u-boot configuration at defaults. MoZes set sane defaults that compliment the boot process. U-boot does not know about your fan, kernel configuration or the contents of your /etc/fstab. The partition layout should be created BEFORE the installer is ran (setup). UEFI is not implemented in Slackware u-boot. No need for an EFI partition or GPT layout. No need to label the partitions prior to running the installer. Follow the installation directions I linked a few posts back and you will be just fine.

Thanks but I am aware U-boot is not at all like BIOS/UEFI. That's why I miss it. For example let's say I have 4 SATA ports, 2 for a simple RAID0, and one Root drive. I wanmt to know how the system sees the order of those drives. They don't always respect Port #1,2,3 and 4. I'd like to know before I attempt a long boot process so I will know I can leave a 4th drive attached and not have to unplug it until most of the boot process completes.

As I said, I have re-installed more than once since this debacle began a little over a week ago and my problem, or the main one, was not recalling I ever needed a MicroSD drive to boot. Somehow (wishful thinking?) I thought my RockPro64 only needed SPI and a SATA drive.

Tidying up is nearly done other than some odd behaviours with slackpkg. After I got a few KDE errors I launched "slackpkg reinstall kde" (and plasma for good measure) and KDE would crash saying "libxcvt could not be found". Since I found it manually I fixed that but some kde stuff behaves badly. Now that I have saved a proper installer eMMC drive I will likely just restore my previous backup and rescue the root password and get back what I'd lost due to MEMS.

We aren't using Linux 5.19 in Slackware AArch64 yet.


Huh? Please elaborate. Another web site? The documentation for the supported Hardware Models (RockPro64, RPi3/4, PinebookPro) is all on docs.slackware.com. There are no other web sites involved, and nobody's grumpy.

Assemble /boot from the manufacturer? Again, please elaborate.
I'm not sure you're looking at the official documentation. I wrote all of it and nothing you've written here reminds me of it.

Well almost there with the cloned image. I copied the /boot directory to storage, cloned the drive image back to SSD (which as before had /boot empty for reasons I still don't know) and then manually copied the save /boot contents back to the SSD /boot. It tries to boot and gets very far along but halts at

Frankly this pisses me off since I can't fix the problem easily without the system continuing and running without a GD fan wasn't a problem until then. Seriously! WTF!??! Granted ultimately it falls on my own ignorance and dependence on x86 BIOS control over such things as some fan control but I suspect that means the problem is with initrd. Why the address and capabilities of fan control would ever change makes no sense to me but I will try...

1) Copying an alternate intird to /boot
2) Chroot in and try to create a new initrd

Man! I am hating MEMS more every day. What irresponsible coding.

The fan is controlled by /etc/rc.d/rc.platform. It has nothing to do with the initrd-armv8. You do not need to copy boot to your root disk. /boot is empty on your root partition and when the SD Card is mounted, it populates /boot with kernel and assets.

You can modify the initrd with the os-initrd-mgr command. When in doubt, check the docs!

To be clear since I suspected initrd for fan control I copied it to the boot MicroSD now being aware that /boot on root disk is just a placeholder.

I'm fully aware of os-initrd-mgr because I do read docs, especially when I realize I don't know something and as I've mentioned I am very unfamiliar with initrd since I never use it. So I first did "man mkinitrd.conf" then "man mkinitrd" before trying to run it which told me to use os-initrd-mgr. Naturally I then did "man os-initrd-mgr". I realize it could seem that I don't check the docs since I tend to try things but it isn't without first getting clues from docs.

It doesn't work well for me to "paint by numbers". I need to know fundamentals and I'm still gathering that information by experience... often painful experience but it works out in the long run. Granted as I've mentioned I do have some resistance to the embedded nature of SBCs as so much stuff is just hidden from view and that rubs me wrong but I'll get there or not bother with the current state of ARM for awhile. However it does rub me really wrong that 2 different disks are required to boot one system but then it rubbed me wrong that OS/2 required a few floppies to begin installation from a CD. It made more sense to me to be either 100% one or the other, despite the minor advantage of being able to edit floppies before CD writers were common.

More to the immediate point, how is it that /etc/rc.d/rc.platform ever changed? The system backed up on an image worked perfectly. So not only does it seem reasonable it would work again but why would the boot process just hang when I know the CPU is not overheating?

FINALLY!! Everything is back like it should be and works great. I had problems getting it to work with just cloning back the partition image but I suppose that I would need to clone the existing MicroSD as well. Instead I reinstalled without formatting so that it kept my original /home and any files that don't exist on a fresh install. I had extracted /etc (with all the NAS server settings) and /tmp (with all the package builds) to a backup drive and after I was sure it would boot, copied over my backup /etc by renaming the installed /etc to /etcFresh, and any /tmp package builds.

I did discover a nice advantage to having the real boot on the separate MicroSD as I could like keep the Installer menuitem working as a quick repar service access, but I'll work on that later. Right now it's blazing away at an incremental rsync

Many thanks for all the help and especially the patience for my quirky ways.