Installing GenPi64 / gentoo-on-rpi-64bit on USB3 SSD

[ElRay70K70H]

I have an 8GB RPi4 that I am struggling to get Gentoo running on. It has been running Raspain when I got it, then Ubuntu 24-bit and most recently Raspberry Pi OS 64-bit, all from the SSD, all without a hitch

I've tried:

• Raspberry Pi/ARM64 in place installation
• Raspberry Pi4 64 Bit Install

and both resulted in an overscanned white/red screen prompting for a net boot, diagnostics, etc. when attempting to boot from the SSD.

Can I write one of the images from GenPi64 / gentoo-on-rpi-64bit to the SSD, edit:

Code: Select all

fstab
config.txt
cmdline.txt

to reference /dev/sda1 & /dev/sda2 and expect a bootable system?

Alternately, can I write the image to a microSD, copy the rootfs and /boot partitions to the appropriate place on the SSD, edit the previously mentioned files, and boot off the SSD?

The Pi4 is set-up to boot off the microSD if present, and the SSD if not and this has worked through three OSes.

[NeddySeagoon]

ElRay70K70H,

What do you have in your /boot partition now?

What filesystem do you have on /boot?

It sounds like the firmware on the Pi that is supposed to read /boot can't for some reason so it falls back to netbooting.
That the image is overscanned, suggests that /boot/config.txt has not be read.

Please share /boot/config.txt too.

[ElRay70K70H]

Thanks.

… Please share …

Will do. See below.

The RPi4 is currently in the middle of what was to be the third attempt. This time I walked through the four RPi4-64 bit guides I could find, in parallel, checking against each other and making sure every warning/error was dealt with before moving on. I haven't tried to boot this one yet, maybe I can salvage it before starting over. This means the 'cmdline.txt' and 'config.txt' files below are untested.

What prompted me to look for a "LiveCD" solution and start again was issues with kernels. First, no kernel sources were being pulled-down. I tracked that down to /usr/src/linux being a directory. So I rmdir'ed 'linux' and added 'symlink' to my USE flags. Then I got file collision errors trying to get the raspberry sources and started looking for something more LiveCD-like. Also, at one point, "select kernel list" showed a list of about six variations of the 5.15.32-r1 kernel (rc.local, systemd, desktop, etc.), but no RPi-related kernels. Now it only shows:

Code: Select all

(chroot) piBox /etc # eselect kernel list
Available kernel symlink targets:
  [1]   linux-5.10.63_p20211029-raspberrypi *
  [2]   linux-5.15.32-gentoo-r1

The 'raspberrypi' kernel is only 5 months old, but it's an odd mid-release of the 5.10 series (the last arm64 5.10 release was 5.10.109).

What kernel should I be running? If I could get a confirmation on which one should be "good", I'll shutdown, pop-out the microSD card and test.

Also, I'm concerned about the firmware. If I look in /lib/firmware, I've got 20 symlinks that the target can't be found. See below.

Current contents of /boot:

Code: Select all

(chroot) piBox / # ls /boot
bcm2708-rpi-b.dtb       bcm2710-rpi-3-b.dtb       bcm2711-rpi-cm4s.dtb  fixup4x.dat   kernel8.img       start_cd.elf
bcm2708-rpi-b-plus.dtb  bcm2710-rpi-3-b-plus.dtb  bootcode.bin          fixup_cd.dat  kernel.img        start_db.elf
bcm2708-rpi-b-rev1.dtb  bcm2710-rpi-cm3.dtb       cmdline.txt           fixup.dat     LICENCE.broadcom  start.elf
bcm2708-rpi-cm.dtb      bcm2710-rpi-zero-2.dtb    config.txt            fixup_db.dat  overlays          start_x.elf
bcm2708-rpi-zero.dtb    bcm2710-rpi-zero-2-w.dtb  COPYING.linux         fixup_x.dat   start4cd.elf
bcm2708-rpi-zero-w.dtb  bcm2711-rpi-400.dtb       fixup4cd.dat          issue.txt     start4db.elf
bcm2709-rpi-2-b.dtb     bcm2711-rpi-4-b.dtb       fixup4.dat            kernel7.img   start4.elf
bcm2710-rpi-2-b.dtb     bcm2711-rpi-cm4.dtb       fixup4db.dat          kernel7l.img  start4x.elf
(chroot) piBox / # 

Current contents of /boot/cmdline.txt:

Code: Select all

(chroot) piBox / # cat /boot/cmdline.txt
console=serial0,115200 console=tty1 root=223ecc81-7069-45f9-9309-c641eba776c8 rootfstype=ext4 fsck.repair=yes rootwait
(chroot) piBox / # 

That is the correct UUID for the rootfs partition:

Code: Select all

(chroot) piBox / # blkid
/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="E5B6-FD41" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="3a83545e-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="a4b3ef34-532d-430b-a401-589e4a6a5d2c" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="3a83545e-02"
/dev/sda1: LABEL_FATBOOT="boot" LABEL="boot" UUID="10EB-30C5" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="d32ad659-01"
/dev/sda2: LABEL="rootfs" UUID="223ecc81-7069-45f9-9309-c641eba776c8" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="d32ad659-02"
(chroot) piBox / # 

I previously tried using LABEL and '/dev/sda2', but neither worked -- Same Polish Flag Boot Screen

Current contents of /boot/config.txt (commented-out lines deleted to save space):

Code: Select all

(chroot) piBox / # cat /boot/config.txt
disable_overscan=1
hdmi_drive=2
dtparam=audio=on
camera_auto_detect=1
display_auto_detect=1
dtoverlay=vc4-kms-v3d
max_framebuffers=2
arm_64bit=1
gpu_mem=16
[cm4]
otg_mode=1
[pi4]
arm_boost=1
[all]
(chroot) piBox / #

The current 'make.conf' is:

Code: Select all

(chroot) piBox / # cat /etc/portage/make.conf
# These settings were set by the catalyst build script that automatically
# built this stage.
# Please consult /usr/share/portage/config/make.conf.example for a more
# detailed example.
COMMON_FLAGS="-march=native -mcpu=native -mtune=native -pipe -O2 -ftree-vectorize -fomit-frame-pointer"
MAKEOPTS="-j4"
# Default
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"
FCFLAGS="${COMMON_FLAGS}"
FFLAGS="${COMMON_FLAGS}"
# WARNING: Changing your CHOST is not something that should be done lightly.
# Please consult https://wiki.gentoo.org/wiki/Changing_the_CHOST_variable before changing.
CHOST="aarch64-unknown-linux-gnu"
# NOTE: This stage was built with the bindist Use flag enabled
USE="-gui symlink"
# This sets the language of build output to English.
# Please keep this setting intact when reporting bugs.
LC_MESSAGES=C
(chroot) piBox / #

and 'make.profile' is a symlink to:

Code: Select all

/var/db/repos/gentoo/profiles/default/linux/arm64/17.0/systemd

Broken symlinks in /lib/firmware:

Code: Select all

lrwxrwxrwx  1 root root      31 Apr 22 23:40 brcmfmac43012-sdio.bin -> ../cypress/cyfmac43012-sdio.bin
lrwxrwxrwx  1 root root      36 Apr 22 23:40 brcmfmac43012-sdio.clm_blob -> ../cypress/cyfmac43012-sdio.clm_blob
lrwxrwxrwx  1 root root      31 Apr 22 23:40 brcmfmac43340-sdio.bin -> ../cypress/cyfmac43340-sdio.bin
lrwxrwxrwx  1 root root      31 Apr 22 23:40 brcmfmac43362-sdio.bin -> ../cypress/cyfmac43362-sdio.bin
lrwxrwxrwx  1 root root      30 Apr 22 23:40 brcmfmac4339-sdio.bin -> ../cypress/cyfmac4339-sdio.bin
lrwxrwxrwx  1 root root      31 Apr 22 23:40 brcmfmac43430-sdio.bin -> ../cypress/cyfmac43430-sdio.bin
lrwxrwxrwx  1 root root      31 Apr 22 23:40 brcmfmac43455-sdio.bin -> ../cypress/cyfmac43455-sdio.bin
lrwxrwxrwx  1 root root      36 Apr 22 23:40 brcmfmac43455-sdio.clm_blob -> ../cypress/cyfmac43455-sdio.clm_blob
lrwxrwxrwx  1 root root      30 Apr 22 23:40 brcmfmac4354-sdio.bin -> ../cypress/cyfmac4354-sdio.bin
lrwxrwxrwx  1 root root      35 Apr 22 23:40 brcmfmac4354-sdio.clm_blob -> ../cypress/cyfmac4354-sdio.clm_blob
lrwxrwxrwx  1 root root      30 Apr 22 23:40 brcmfmac4356-pcie.bin -> ../cypress/cyfmac4356-pcie.bin
lrwxrwxrwx  1 root root      35 Apr 22 23:40 brcmfmac4356-pcie.clm_blob -> ../cypress/cyfmac4356-pcie.clm_blob
lrwxrwxrwx  1 root root      30 Apr 22 23:40 brcmfmac4356-sdio.bin -> ../cypress/cyfmac4356-sdio.bin
lrwxrwxrwx  1 root root      35 Apr 22 23:40 brcmfmac4356-sdio.clm_blob -> ../cypress/cyfmac4356-sdio.clm_blob
lrwxrwxrwx  1 root root      31 Apr 22 23:40 brcmfmac43570-pcie.bin -> ../cypress/cyfmac43570-pcie.bin
lrwxrwxrwx  1 root root      36 Apr 22 23:40 brcmfmac43570-pcie.clm_blob -> ../cypress/cyfmac43570-pcie.clm_blob
lrwxrwxrwx  1 root root      30 Apr 22 23:40 brcmfmac4373-sdio.bin -> ../cypress/cyfmac4373-sdio.bin
lrwxrwxrwx  1 root root      35 Apr 22 23:40 brcmfmac4373-sdio.clm_blob -> ../cypress/cyfmac4373-sdio.clm_blob
lrwxrwxrwx  1 root root      31 Apr 22 23:40 brcmfmac54591-pcie.bin -> ../cypress/cyfmac54591-pcie.bin
lrwxrwxrwx  1 root root      36 Apr 22 23:40 brcmfmac54591-pcie.clm_blob -> ../cypress/cyfmac54591-pcie.clm_blob

[pingtoo]

Hi ElRay70K70H,

I use GenPi64 (I think it was alpha 8 ) It work fine for my purpose. I have yet to update it's kernel (Linux pi-3.home 5.10.11-v8-p4 #1 SMP PREEMPT Tue Apr 27 18:58:07 -00 2021 aarch64 GNU/Linux) because this kernel work just fine and I don't see new kernel offer any benefit.

Your current posted setting is very different from mine, so you are not using GenPi64 based image?

I be happy to help if you wish start from GenPI64.

I notice few things in your post

• /boot/cmdline.txt, "root=223ecc81-..." will not work unless you have a initramfs that know what to do with that. It should be root=PARTUUID="d32ad659-02"
• /boot/config.txt, there is no "kernel=...", I am not sure if that will work, may be your bootloader version have a default value for it?
• /lib/firmware directory contents. it looks wrong, not sure how you got them.

Edit: Noticing from Neddy's post, I got wrong PARTUUID in my original post. it should be root=PARTUUID="d32ad659-02".

[NeddySeagoon]

ElRay70K70H,

On github, the current Pi Foundation kernel is rpi-5.15.y, so that's a good start. 5.10.y should be good too, its just that 5.15 in the new LTS.
Your linux-5.15.32-gentoo-r1 is based on the upstream kernel so will be missing some Pi specific patches.
It has a few other quirks you need to take account of too.

So far though, the kernel plays no part in your errors as its not being loaded.

/boot looks good.

The firmware does something sensible with regards loading a kernel with cmdline.txt and config.txt both missing.
Rename those two files and leave everything else as is.
If it still tries to netboot, its got nothing to do with your install. It should load a kernel then fail to mount root.

kernel.img is for the original Pi, its armv6j
kernel7.img is for the armv7-a Pis
kernel7l.img is for the P4 in 32 bin mode.
kernel8.img is for the Pi3 and Pi4 in 64 bit mode.

The Pi4 firmware will load one of the last two.

Onto /boot/cmdline.txt. Gentoo does not provide the serial0 symbolic link. Well the systemd version may but I've not tried that.

I would be surprised if root=223ecc81-7069-45f9-9309-c641eba776c8 worked.
Thats a UUID of sorts. root=UUID= or root=PARTUUID= is expected, or a /dev

root=UUID= requires an initrd but the kernel understands root=PARTUUID= all on its own.
You don't have an initrd.
root=LABEL= also requires an initrd

root=PARTUUID=d32ad659-02 would be good.

The next step is to see the Pi do its own thing and load a (any) kernel before it falls to mount root.

[ElRay70K70H]

... Your current posted setting is very different from mine, so you are not using GenPi64 based image? ...

No. I'm working off the regular arm64 stage 3. The docs on the Gentoo site reference one of them, nothing from the GenPi64/gentoo-on-rpi-64bit GitHub site

• /boot/cmdline.txt, "root=223ecc81-..." will not work unless you have a initramfs that know what to do with that. It should be root=PARTUUID="3a83545e-02"

Good catch. I don't know how many times I stared at that and completely missed the missing 'PARTUUID='

• /boot/config.txt, there is no "kernel=...", I am not sure if that will work, may be your bootloader version have a default value for it?

AFAIK, it's hardcoded to run 'kernel8.img'. I'll double-check one of the working non-Gentoo boot microSDs I have.

• /lib/firmware directory contents. it looks wrong, not sure how you got them.

What's there is the result of one of the following:

• git clone --depth 1 https://github.com/raspberrypi/firmware/
• cp -rv /lib/firmware/brcm/ /mnt/gentoo/lib/firmware/ (The original PiOS boot medium)
• emerge --ask sys-boot/raspberrypi-firmware

[ElRay70K70H]

• /boot/cmdline.txt, "root=223ecc81-..." will not work unless you have a initramfs that know what to do with that. It should be root=PARTUUID="3a83545e-02"

Good catch. I don't know how many times I stared at that and completely missed the missing 'PARTUUID='

I'm not sure what the problem was before, but this (essentially) did the trick. Two comments

• 'UUID ≠ PARTUUID'
• Don't mix&match 'UUID' and 'PARTUUID' across cmdline.txt and fstab.

It's now booting off the SSD, but the boot sequence has stalled at:

Code: Select all

[  222.815420] random: crng init done

I'm not sure what it's doing right now, but I know I did have it set to 'fschk' the drive on boot-up.

[pingtoo]

I sometime got into same condition as your's, That usually happen when I messing around boot device. So may be you are in same condition, that root device are wrong.

I have correct a mistake I post earlier where I use wrong PARTUUID. I hope you were using the correct one from Neddy's port, but if you take copy from mine, My apology Please see above post use the "d32ad659-02".

your kernel command line parameter "rootwait" cause kernel waiting indefinitely for root device to ready. So may be take out "rootwait" for now to let kernel panic so we can be sure where went wrong.

Also suggest do find a initramfs to use, it will help during initial setup to learn what went wrong.

[ElRay70K70H]

Thanks all.

I'm going to try the test w/o cmdline.txt and config.text and the PARTUUID clean-up.

Just to be clear, I don't need a Gentoo kernel to run Gentoo on top of? Can I still emerge the kernel config tool and use that with the Pi Foundation kernel?

Is there a "verbose" mode that can be turned on during boot so I can see what's happening during a hang like the one I just had? Is there anything written to a log that I can view after the fact by booting to an OS on a microSD card?

[NeddySeagoon]

ElRay70K70H,

If you mean genkernel, I don't know. It builds a kernel that demands an initrd, which is harmless.
However, it will not set up config.txt to load either the kernel or the initrd.
I have not used it ever. I suspect that it will use an unsuitable kernel .config as a starting point.

The default kernel names expected by bootcode.bin/Pi4 firmware are the ones in /boot already.
None of those kernels need an initrd.

If you want to use other kernel/initrd/*.dtb file names you can as long as you make the correct entries in config.txt.

The kernel, its optional initrd, and its *.dtb (Device Tree Binary) are a matching set.
The dtb file is built with the kernel.

The default Pi4 configuration in the Pi Foundation kernel works well under Gentoo.
Trying the mainline kernel is still on my todo list.

[ElRay70K70H]

The default Pi4 configuration in the Pi Foundation kernel works well under Gentoo.
Trying the mainline kernel is still on my todo list.

Currently the 5.10 Raspberry Pi kernel is selected. Let me get this to boot, then I'll try the newer Pi Foundation kernel.

[NeddySeagoon]

ElRay70K70H,

With the test I suggested, it will boot one of the *.img files.
That's fine. Its fine for it to fail too.

[pingtoo]

Just to be clear, I don't need a Gentoo kernel to run Gentoo on top of?

Yes, Any kernel that build specific for RPI4 will do, but as per Neddy point out must use matching DTBs that build with the kernel.

Is there a "verbose" mode that can be turned on during boot so I can see what's happening during a hang like the one I just had?

I don't know any kernel standard parameters can do that. But if you can introduce a initramfs with right toolset you can debug rootfs discovery/mounting process easily.

Is there anything written to a log that I can view after the fact by booting to an OS on a microSD card?

logging usually happen rootfs mounted, since no rootfs, there is no place to log Again, if you use initramfs you can usually trace step by step.

If you use GenPi64, you can add "shell" at cmdline.txt, than GenPi64's initramfs will put you into command line, so you can debug the discover/mount processes.

[NeddySeagoon]

ElRay70K70H,

Change rootwait to rootdelay=30.

rootwait will wait forever for root to become available and it looks like its not.

rootdelay=30 will make the kernel wait 30 second then try to mount root, regardless of if its available or not.
If root is not ready, the kernel panic message will be useful.

As pingtoo says, you need an initrd to pravide some diagnostic userspace tools to poke about after root fails to mount.
With no root fs, there is nowhere to log anything to.

Its OK to use either PARTUUID or UUID is fstab.
UUID needs the userspace mount command, which is available once root in mounted.
They are different numbers referring to different things.

PARTUUID is a property of a partition.
UUID is a property of a filesystem, which is created on a partition.

[ElRay70K70H]

I made the edit suggestions above, but I went with removing 'rootwait' instead of setting 'rootdelay'. then I:

Code: Select all

pi@piBox:/mnt/gentoo/boot $ mv cmdline.txt cmdline.txt.bak
pi@piBox:/mnt/gentoo/boot $ mv config.txt config.txt.bak

and tried again. Same hang, at the same point. It looks like the choices are down to setting up an 'initramfs' to continue to troubleshoot, or jump ship and try the 'GenPi64/gentoo-on-rpi-64bit' route.

[NeddySeagoon]

ElRay70K70H,

Put your kernel..config onto a pastebin site.

I suspect that its not a hang, its a missing console driver, so the console is using black text on a black background.
It may well be booting normally.

If you want that kernel8.img to boot so you can see it, you need to put its modules into /lib/modules on your root filesystem.
The default kernel does not give you a console until root is mounted and the modular driver is loaded.

The Pi 4 install guide suggest that you enable Simple Framebuffer, so you get an earlier console.

[ElRay70K70H]

…The Pi 4 install guide suggest that you enable Simple Framebuffer, so you get an earlier console.

The only noted I've found on this are from the GwnPi64 GitHub site:

you can fall-back to the standard framebuffer mode by commenting out the dtoverlay=vc4-fkms-v3d line in /boot/config.txt

But, if config.txt is missing, shouldn't I get the standard frame buffer behavior? I'll read from the non

I'll swap to a bootable microSD and get the kernel config file. If I can find a USB-A to USB-A cable first, I'll just pull it directly from the SSD.

[NeddySeagoon]

ElRay70K70H,

But, if config.txt is missing, shouldn't I get the standard frame buffer behavior? I'll read from the non

Yes and no.

Yes if the kernel can mount root, as the framebuffer driver you need is built as a module.
If than works you get 10 or so seconds of blank screen after the rainbow, before console text appears.

When root fails to mount, or the module is missing or built with the wrong version magic, you get nothing.
Simple framebeffer works before root is mounted, that way you can see the panic message when root fails to mount.

[ElRay70K70H]

Sorry for the delay. Life got in the way of plans.

... Put your kernel..config onto a pastebin site. ...

There's not a kernel.config in /boot. The two that exist on the roots are:

Code: Select all

/usr/src/linux-5.10.63_p20211029-raspberrypi/tools/testing/selftests/wireguard/qemu/kernel.config
/usr/src/linux-5.15.32-gentoo-r1/tools/testing/selftests/wireguard/qemu/kernel.config

and from before, my kernel choices are:

Code: Select all

(chroot) piBox /etc # eselect kernel list 
Available kernel symlink targets: 
  [1]   linux-5.10.63_p20211029-raspberrypi * 
  [2]   linux-5.15.32-gentoo-r1

so, it looks like they're the right ones.

• Here's the pastebin for the linux-5.10.63_p20211029-raspberrypi kernel: https://pastebin.com/mJK494bQ
• Here's the pastebin for the linux-5.15.32-gentoo-r1 kernel: https://pastebin.com/6mT1paV6

I'll try to get "simple frame buffer" running tonight.

[NeddySeagoon]

ElRay70K70H,

Those pastebins are config file fragments.

The .config files will be in
/usr/src/linux-5.10.63_p20211029-raspberrypi and /usr/src/linux-5.15.32-gentoo-r1

[ElRay70K70H]

Here they are:

• /usr/src/linux-5.10.63_p20211029-raspberrypi/.config - https://pastebin.com/ur7eQs5E
• /usr/src/linux-5.15.32-gentoo-r1/.config - https://pastebin.com/7TedXQKz

[NeddySeagoon]

ElRay70K70H,

Your /usr/src/linux-5.10.63_p20211029-raspberrypi/.config won't show you a console as it has

Code: Select all

# CONFIG_FB_BCM2708 is not set

That's the console driver for all the Pis.

/usr/src/linux-5.15.32-gentoo-r1/.config does not even have that option, so its probably hidden by something else that it needs.
That's means its off. there too.

None of the Pis support EFI, so none of your kernels provide a working console.
Rebuild the kernel using the Raspberry Pi sources and the default Raspberry Pi kernel config.

For a Pi 4 that's

Code: Select all

make bcm2711_defconfig

Its sub optimal in that there is a lot of bloat but make it work first.
Make it better later.

[ElRay70K70H]

Thanks again. I'll try the config reset.

The kernel config that's there is what was pulled-down during the

Code: Select all

>git clone --depth 1 https://github.com/raspberrypi/linux.git

step in the various RPi4 64-bioit guides.

Finally, just to be sure, this:

Code: Select all

  │ Symbol: FB_SIMPLE [=n]                                                                                                 │  
  │ Type  : tristate                                                                                                       │  
  │ Defined at drivers/video/fbdev/Kconfig:2195                                                                            │  
  │   Prompt: Simple framebuffer support                                                                                   │  
  │   Depends on: HAS_IOMEM [=y] && FB [=y] && !DRM_SIMPLEDRM [=n]                                                         │  
  │   Location:                                                                                                            │  
  │     -> Device Drivers                                                                                                  │  
  │       -> Graphics support                                                                                              │  
  │         -> Frame buffer Devices                                                                                        │  
  │ (6)       -> Support for frame buffer devices (FB [=y])                                                                │  
  │ Selects: FB_CFB_FILLRECT [=y] && FB_CFB_COPYAREA [=y] && FB_CFB_IMAGEBLIT [=y]

Is the Simple Framebuffer that's being discussed, correct?

[NeddySeagoon]

ElRay70K70H,

The

Code: Select all

git clone --depth 1 https://github.com/raspberrypi/linux.git

gets you a copy of linus's mainline kernel with Raspberry Pi patches applied.
The kernel .config you get at the end of that step is not useful to anyone.

Its full of different default configurations for every platform that the kernel can support.

You need the

Code: Select all

make bcm2711_defconfig

to select the Pi4 default kernel .configuration.
It looks like you skipped that step.

[ElRay70K70H]

I've got the kernel rebuilding. We'll see how the new kernel works.

Between my previous email and @NeddySeagoon reply, I turned on the console/simple FB. This time the error was:

Code: Select all

Not syncing : VFS: unable to mount root fs on unknown-block (0,0)

This may not be exactly right, I'm typing that from memory, but the end was 'unknown block (0,0)'. So, I went back and compared the default values of:

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

from a base Pi OS microSD card. The only thing that stands out as might be part of the problem is 'fstab'.

From the Pi OS microSD:

Code: Select all

piUser@piBox:/boot $ cat /etc/fstab
proc                  /proc           proc    defaults          0       0
PARTUUID=1e921981-01  /boot           vfat    defaults,flush    0       2
PARTUUID=1e921981-02  /               ext4    defaults,noatime  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

From the Gentoo SSD:

Code: Select all

gentoo@piBox:/boot $ cat /mnt/gentoo/etc/fstab
proc                 /proc    proc defaults                     0 0
shm                  /dev/shm tmpfs size=4G,nodev,nosuid,noexec 0 0
PARTUUID=d32ad659-01 /boot    vfat defaults                     0 2
PARTUUID=d32ad659-02 /        ext4 defaults,noatime             0 1

As far as I can tell, those are the right PARTUUIDs:

Code: Select all

gentoo@piBox:/boot $ blkid
/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="37E2-62C3" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="1e921981-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="6a932c1f-7335-42d9-9351-1b1b2ca538d4" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="1e921981-02"
/dev/sda1: LABEL_FATBOOT="boot" LABEL="boot" UUID="10EB-30C5" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="d32ad659-01"
/dev/sda2: LABEL="rootfs" UUID="223ecc81-7069-45f9-9309-c641eba776c8" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="d32ad659-02"

But then again, if the problem is that the rootfs isn't loading, then /etc//fstab hasn't been read yet. So it looks like something else is preventing the rootfs from mounting.

• Do I need the 'proc' or 'shm' entries?
• There are several 'tmpfs' devices created by the time the Pi OS microSD boots do they need to be specifically enabled/created?
• Looking at the default kernel .config, I see that all of the 'INITRAMFS..." options are turned off. Should I enable: INITRAMFS_FORCE, INITRAMFS_SOURCE and/or any to the other 'INITRAMFS...' options?
• If yes, then how are they configured at boot, if all the initrc/systemd info in on the rootfs?