another way to select another fs as the root, for example xfs.
you just need to add rootfstype=xfs to uEnv.txt

Back to not booting on the ssd - I've had a chance to try my modified rc.S I'd shoved in a line earlier removing an unecessary check around line 247 Then starting around line 297 I have this Whereas I can't read the lines on boot as they roll up the screen, I would spot the asterisks & spaces rolling up screen. Now I booted My Pi on that, and it never rolled up screen, whereas I would expect it to. The plot thickens … It's clearly going funny on the ssd, although it works on usb key/mmc card.

This is getting funny - I've a grin on my face here.

I did a debug version, adding stuff like echoing variable values to screen, and this I had 3 "sleep 5" statements in it. I got that in position on the ssd / and made it executable, and rebooted. AFAICT, rc.S didn't run at all. I certainly had no 'sleep 5' commands slowing me down on the bootup. I made the mistake of not marking rc.S executable here first time, so I had to revisit and fix that.

When you look at what's in rc.S, a lot of that stuff doesn't apply to a simple sbc like the Pi. So I'll plod along. Today's been a bad day here, and this is a family, not a workshop.

EDIT: I have booted my ssd to runlevel 3, remounted / rw, and can start X with the 'lightdm' command. So things may not be kosher, but they work.

it feels like init comes from another disk.

There is no other disk. The ssd boots the same software as the MMC, & the usb key, and only the ssd gives issue. I thought maybe the runlevel in /etc/inittab with rc.S wasn't happening. I felt fairly sure rc.M was, so I tried an unconditional "exec /etc/rc.d/rc.S" into rc.M, but even that didn't happen. But I can invoke it no issue once I log in.

I'm going to go away and come back with more energy, and perhaps enter comments and wait statements into rc.M just to be sure. I have the sdcard; I'll run on it. Trying the ssd is simple, as I just power off, pull the sdcard and power on. The ssd still has the media I'm watching.

Even watching, there's a lot less output from the same ssd using the ssd.

Just playing away here. I decided to rebuild the kernel, seeing as it has that offensive CONFIG_CMDLINE setting referencing mmcblk0p2

I'm missing the command 'bc' so things puke in the scripts. What package provides that?

I tested the migration script, found one problem not related to mounting, and it works correctly.
slarm64-current-aarch64-xfce-raspberry_pi_4-5.15.12-build-20211230.img.zst

bc-1.07.1-aarch64-5

Thanks. To get the kernel going, I also needed

• flex
• m4
• bison
  

but it's cooking now. It's morning here, so I'll check it periodically. I prepended 'time' to the make instruction. I really should have done something about the extra drivers in that, but I didn't mess with the config, so a whole lot of drivers for competitor sbcs will be built.

FTR, Slackware doesn't set CONFIG_CMDLINE at all. All that stuff is in cmdline.txt which I presume is fed as kernel input anyhow.

Well, I recompiled the kernel 5.15.5 with CONFIG_CMDLINE pointing at sda2 but I still had the read-only / on my ssd drive.

I tried a hybrid - booting from mmcblk0p1 with root=/dev/sda2, but that gave me a read-only / also.

I've tried the 5.15.12 revision of the xfce image and your transfer-to-disk script is still misbehaving. The display doesn't function. But it copied the files despite showing 0% onscreen. The script effectively wipes the entire disk. OK, perhaps on a small usb key but definitely not ok on anything bigger. All the config files have to be modified by hand, anyhow. Rsync probably does a better, easier job as things stand. The trick is

1. rsync the /boot partitions
2. unmount the /boot partitions.
3. Mirror the / partitions

Lastly, I rebuilt a usb key with the 5.15.5 image, modified the config files (etc/fstab, /boot/config.txt, & /boot/cmdline.txt), booted without u-boot and THAT booted read-only on / as well. I'm pretty confident that if I booted to runlevel3, remounted / & ran lightdm, I could get going. The second usb key is slower, but that surprised me because I had a memory of it working. I could have been booting to runlevel 3 and remounting / myself. There wasn't many restarts done.

That aside, I'll give up at this stage. I am not inclined to return to bullseye, but I desired a system from ssd. I feel your solution is to go with the PARTUUID solution that Debian uses. I will run from an sdcard for the moment, and use the ssd as a data disk. I actually ended up with a few possible diagnoses that I couldn't fully explore, so I'll lay them out

1. mmcblk0 is hardcoded somewhere and is causing grief. It's actually hardcoded in an awful lot of places
2. The init system is malfunctioning. Perhaps init level S (which runs rc.S) is getting missed?
3. Your two boot systems and specifying a partition in so many places are causing needless confusion.

So Slarm64 is not running here from the usb ports. That is the bottom line.

maybe you used the previous image, and not slarm64-current-aarch64-xfce-raspberry_pi_4-5.15.12-build-20211230.img.zst, in the coming ones there was a problem with the rights to files, therefore, did not start lightdm. I checked the transfer script, it works correctly.

I have already described how the booting takes place and what files are used.

Due to the fact that the fs is still mounted on the correct partition, it looks like there is another problem (broken fs, physical problems with the disk) once it sees errors during mounting and mounts in read mode.

I also suggested that you try another type of FS.

also be sure to remove the parameter from fstab data=writeback

I've checked the disk, & remade the partitions in case there was an issue. Debian works from that ssd, no issue. I've grasped at enough straws, thanks. I even changed the ssd case, in case the controller board was doing something funny. I'm past that. I'll try nothing, but styay on the sdcard for the moment.

I have stopped on this, but I tried one idea that cropped up which yielded something.

I tried appending <init=/sbin/init> to /boot/cmdline.txt (no u-boot here). Nothing changed.
So I tried <init=/bin/bash> which worked. But I couldn't invoke init properly from a terminal, the error said.
Lastly I tried <init="/sbin/init S"> on cmdline.txt, which should be exactly what the system in fact does, according to the man page. But that also complained about the way I called init, and the kernel panicked because there was no 'init S'. It apparently took the '<space>S' as part of /sbin/init, and failed to find it.

This area is something I should have checked earlier. Now I'm not going to sweat over this, but I may have put a finger on something, you may want to.

Boy, do I feel stupid writing this.

I was running away happily on sdcard, but I somehow managed to screw that installation. I had had a rake of hardware issues together here.

Never mind, I thought, I'll just dd over another image. My 600G backup usb disk had died, but I had a backup of the backup, and that was OK. The xfce image I had there was the one with the 5.15.5 kernel, so I made the sdcard and that went well. Then, totally expecting failure, I rsync'ed it over to my ssd. I'm good by this stage making the necessary adjustments (for non u-boot booting)

• /boot/cmdline.txt
• /etc/fstab

and on the sdcard I had also made a few mods in /etc/rc.d/ to get away from those horrendous rc.inet*, rc.networkmanager and rc.wiress* scripts. I insert a tiny script, replace rc.inet1 with a symlink to it and change one line in rc.M.

Anyhow, my ssd booted first time with no bother. It's perfect. The root partition is R/W - the exact image that I couldn't boot in post #1!

I have discovered a few things along the way which may explain this:

• Slackware ships with a little known program called wipefs. The purpose of this is to fully wipe beginnings and ends of gpt/mbr partitions. Obviously, a deleted partition isn't really gone and can upset things.
• If you take a USB Key and dd an image to it to use it in a RazPi, you destroy the usb disk’s ability to boot in a pc. I have two such usb disks now. They're fine as data disks, but not as boot PC disks. Perhaps making sure the first 1MB is not written would help. Partition tables start at sector 2048 (* 512 = 1 Meg)

Now I still couldn't set a user password. A check on my PC showed root with a password in /etc/shado* and users with a password in /etc/passw*, which is as things should be. But in Slarm64, adding a user via your script does not add that user to /etc/passwd, or /etc/passwd-. Go figure that out!

I have a user on my pc, so I took that line and copied & pasted it into Slarm64. The password didn't work, of course. But when I changed the passwd with root, I can log in as a user

So you have a problem with user passwords that could well be a permissions issue, but you have a definite linbe of inquiry as once the user gets in to /etc/passwd, you can fix the password ok.

after executing the script, you need to set the password:

As root? I did, of course, many times. No user passwords stuck in /etc/passw*