On my PC I have both the use of Liveslak as well as several Slackware systems from which I can chroot in and fix issues including password retrieval/rewriting. I'm assuming I could likely create an install on a USB drive and go though the whole setup procedure for a secondary system, or perhaps remove the SSD drive and try to edit it on another PC, but I'm wondering if there exists a live version that would sidestep some issues and save time and effort?

In this specific, current case it is about root password (I can login as User) which I have forgotten from not booting my RockPro64 in over a month and my advancing years and obviously not writing the password down.

I'd welcome a cheap and fast solution but since I have relied rather often on Liveslak to maintain my many systems, that would be great to know, let alone have on hand.

Boot the installer, mount the drives/partitions, and chroot into your system. Then you can change the password or whatever. The installer functions like a live system, being that the system is entirely in RAM. So it doubles as a rescue disk.

I know the installer recommends that the initrd-armv8.gz in /boot be removed. I keep it around as a second boot option when my Slackware aarch64 install is not booting.

Each kernel upgrade I download the updated initrd-armv8.gz (slackware installer ramdisk) and drop it into /boot. This will assure that the kernel modules in /lib/modules are synced with the live system.

2 members found this post helpful.

Thanks mralk3, both seems a very workable solution. especially since my modified bootloader now offers options, largely thanks to you.

1 members found this post helpful.

I have a HoneyComb LX2 that I am booting with Grub + UEFI (installer boots in UEFI mode too). I am planning on adding a few extra entries for rescue, maintenance, serial console, with or without networking, and have grub use a display via HDMI by default.

It's possible something similar could be done for other hardware models but with U-Boot specific configurations. You would just need to edit /boot/extlinux/extlinux.conf to add in those extra menu entries.

No disrespect since it's possible Aarch64Slackware devs have not tried SLARM but it IS a Live Slackware distro for ARM and has a distinct advantage of being available (if a bit hard to find anymore) as a "burnable" image, making creation a very simple and fast process. Today I burned the .img file using Balena-Etcher. It worked perfectly for chroot work as well as simple external edits since it runs nicely on cheap media like MicroSD.

SLARM behaves much like an XFCE version of Liveslak booting directly to Desktop and, having the common hybrid Slackware init system, is definitely a useful tool welcome in my "toolbox" arsenal.

1 members found this post helpful.

I think the idea MoZes had when we started the Aarch64 port was to keep the system as generic as possible. A live operating system indicates that the kernel, supporting files, and root filesystem are loaded in memory. As you stated, Alien's live slack does exactly this for x86.

Regarding Slarm64, it is not a live system. At least it wasn't the last time I used it a few years ago. It requires access to the on-board storage to load kernel drivers and the filesystems once u-boot is finished. The part that is the same between Slarm64 and Slackware Aarch64 is they both boot off of SD cards or SPI flash. The key consideration is that SD Cards have a finite amount of read and write operations and there is no warning when the SD card (containing a Linux installation) could fail. Making SD Card images available for download has a few problems as well, but I will not get into that. MoZes has explained amply why he did not take the SD image route in the past.

A SSD or NVME drive will always out perform, provide far better stability, and freedom regarding how you use your system. Plus you really do not need to worry about disk reads/writes breaking your SD card, resulting in loss of data.

Since the longevity of drives doesn't vary with distributions or architecture I am of course aware of the tradeoffs andlimitations of MicroSD and eMMC (especially eMMC) and fully agree with both you and Stuart that for any longterm or serious work, one should not attempt to rely on those drives. Sure they're cheap but SSDs whether NVME or SATA are no longer expensive, especially in the sizes needed for a simple system, even two of them actually. I've bought brand name 250GB SATA SSDs for under 20bux USD.

As for Slarm being like a LIVE system, once installed from a simple image file on a MicroSD it surely behaves as one, is very useful as a repair and maintenance system and much like optical and USB drives for x86 it isn't prohibitive to "burn" more than one to combat the short lifespan. I understand and agree that as a developer you probably have less need of a ...let's call it "live acting" backup system for repair and maintenance but for those of us still learning and experimenting and likely making errors in the process, some may find that useful.

FWIW I don't understand yet why ARM can't be utilized like x86 to employ a full system image when installing to an SSD or hard drive much like on x86 Slackware installer but then I also don't get it yet why I can't read Uboot or write to it except by blind automated image, but then I am a raw noob at ARM and likely very set in my ways trained by some 35 years in x86.

This is by no means a complaint. I can see the benefits of ARM and it's mostly intriguing and fun. ARM's future, perhaps along with RISC5, looks quite bright to me even with what little I yet know. Apparently it also does by the major players like Intel, AMD, and NVIDIA.

Before I wipe this tomorrow FWIW the main error I see when borked AarchSlackware fails to boot is

Makes zero sense to me that early in the boot process.

serverip is a variable in the U-boot configuration that points to a TFTP server to boot over the network. That is harmless and is probably activating due to u-boot being unable to find any other boot medium. The "bootargs" variable in U-boot should shed some light about what boot order your system should use. You can expand the contents of the bootargs variable in U-boot with:

Essentially your system is looking for some way to boot the system. Probably because it cannot find a partition with /boot containing a kernel and its assets. This is similar behavior to a x86 BIOS exhausting all the boot options and looking to boot over Ethernet.

Yes, this is the behavior I observed when I was shaking out rockpro64 installs.

I think I see a faint glow. I've just wiped and initiated a fresh install and after copying all the file list, the installer asks if SP1 flash should contain /boot. I'm thinking answering "yes" is why there subsequently /boot was utterly empty on my SSD. I cannot even imagine why anyone would want to require a MicroSD for /boot. It's reminds me of Commodore and VIC 20 days where the system could be on tape but BIOS/Boot was on a floppy. What possible advantage could there be especially given we've noted that MicroSD is in essence a vulnerability compared to "real" drives?

If your're referring to "Resize /boot partition to full extent" and the screen shot says

"It is recommended that this SD card is used for nothing more than /boot
however that is not mandatory, and some users may prefer to create
additional partitions subsequently (post installation)."

I'm concerned about this too, maybe one of us is brave enough to try this?

What possible advantage could there be especially given we've noted that MicroSD is in essence a vulnerability compared to "real" drives?

I think it's what mralk3 said in other thread, allows for mounting sdcard on another computer to do rescue things. Like what recourse is there if /boot is on ssd and system isn't booting, are we really locked out? Thinking out loud here, couldn't the ssd be connected to another computer to do rescue things?

I've done exactly that for my Arm workstation. I store /boot on my first NVME disk. This is in part due to the SD Card containing the UEFI firmware provided by the vendor.

I think you can do this on other supported hardware models too. Store /boot along with the root filesystem. Then program u-boot to look for /boot on that disk. You will need to program u-boot to make this happen by pointing to the kernel and other boot assets. You will also need to do a fair amount of manual edits to your partition layout, since the installer defaults to putting /boot on the onboard SD Card on the Rockpro64, Pinebook Pro, and the Raspberry Pi's.

I am not 100% sure about how it would work on the Rasberry pi's. They are very dependent on accessing the SD Card to boot up.

1 members found this post helpful.

It's just an option because the /boot partition occupies such a small footprint on the SD card, that you either make /boot the full size of the SD card or leave space to make more partitions if you wish (or do nothing with the spare space). Some people think it's a great idea to run the entire OS off an SD card -- this option also enables you to do that: you'd create the OS partition as partition 2 (or 3 for the RPi). I think it's a bad idea which is why I don't do it and didn't document it.
I always resize /boot though because I made it the default, so I just press ENTER to move forwards :-)

1 members found this post helpful.

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.