Disk Structures

[Doug Hardie]

I have a couple of Raspberry Pi 5s. One of which is a production server for mail. It works just fine. However, the disk structure is quite confusing. I only noticed this because of trying to bring up another similar server.

If I list the dev entries for mmcsd, I get the following.

mail# ll /dev/mmcs*
crw-r----- 1 root operator 0x49 Nov 26 15:47 /dev/mmcsd0
crw-r----- 1 root operator 0x4a Nov 26 15:47 /dev/mmcsd0s1
crw-r----- 1 root operator 0x4b Nov 26 15:47 /dev/mmcsd0s2
crw-r----- 1 root operator 0x4e Nov 26 15:47 /dev/mmcsd0s2a
crw-r----- 1 root operator 0x4f Nov 26 15:47 /dev/mmcsd0s2b

This looks like the drive was partitioned using GPT. However, gpart list shows MBR. I removed the non-relevant entries:

mail# gpart list mmcsd0
Geom name: mmcsd0
entries: 4
scheme: MBR
Providers:
1. Name: mmcsd0s1
Mediasize: 52428800 (50M)
type: fat32lba
2. Name: mmcsd0s2
Mediasize: 128124452864 (119G)
type: freebsd

There are the two partitions I expected. A boot partition, and a data partition. Looking at the df output:

mail# df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/ufs/rootfs 108G 9.1G 90G 9% /
devfs 1.0K 0B 1.0K 0% /dev
/dev/msdosfs/EFI 50M 25M 25M 50% /boot/efi
tmpfs 12G 85M 12G 1% /tmp
/dev/da0s2 25G 1.3G 22G 6% /mailbkup
mail#

The entries for / and /boot/efi are not at all what I expected. The /mailbkup seems normal. How do I make sense of all this?

I duplicated the microSD card but it doesn't boot the new machine. I believe that is caused by a hardware failure in the Pi. It does some strange rebooting before ever reading the SD card. Never the less, I should be able to mount the copied SD card on a working machine, but can't figure out how to do that. Messages shows the new disk is da1.

mail# mount /dev/da1s2 /mnt
mount: /dev/da1s2: No such file or directory
mail# mount /dev/mmcsd1s2b /mnt
mount: /dev/mmcsd1s2b: No such file or directory

I would like to verify that the new SD card is good.


-- Doug

[Daniel Anderson]

Are you using the official Raspberry Pi images or imager? I believe there’s a few specific requirements for the partitions...

[Doug Hardie]

The original installation was from FreeBSD-14.2-RELEASE-arm64-aarch64-RPI.img and I have been trying FreeBSD-15.0-RELEASE-arm64-aarch64-RPI.img

-- Doug

[Daniel Anderson]

Right but how are you getting it to the micro SD card?

[Doug Hardie]

dd if=FreeBSD-14.2-RELEASE-arm64-aarch64-RPI.img of=/dev/da1 bs=10M

or 15.0 as appropriate

When I did this with 14.0, the Pi came up just fine. Also the Pi5 did also. I am confident what I see below is correct, I just don't understand it.

-- Doug

[Daniel Anderson]

Raspberry Pis have a weird partition system.  IIRC the first partition has to be under 256MB.  I did a quick google and found the below link.  I should mention that you can download a Raspberry Pi imager that will let you do more customizations than is available with dd https://www.raspberrypi.com/software/ 

[Marco Moock]

On 13.12.2025 13:54 Doug Hardie <bc...@lafn.org> wrote:

> There are the two partitions I expected. A boot partition, and a
> data partition. Looking at the df output:
>
> mail# df -h
> Filesystem Size Used Avail Capacity Mounted on
> /dev/ufs/rootfs 108G 9.1G 90G 9% /
> devfs 1.0K 0B 1.0K 0% /dev
> /dev/msdosfs/EFI 50M 25M 25M 50% /boot/efi
> tmpfs 12G 85M 12G 1% /tmp
> /dev/da0s2 25G 1.3G 22G 6% /mailbkup
> mail#
>
> The entries for / and /boot/efi are not at all what I expected. The
> /mailbkup seems normal. How do I make sense of all this?

If that system uses EFI to boot, those partitions need to exist as they
contain the EFI bootloader.

Is that the case for your machines?

efibootmgr shows you that in case you booted in EFI mode.

--
kind regards
Marco

Send spam to abfall17...@stinkedores.dorfdsl.de

[Sad Clouds]

On Sat, 13 Dec 2025 13:54:04 -0800
Doug Hardie <bc...@lafn.org> wrote:

> mail# df -h
> Filesystem Size Used Avail Capacity Mounted on
> /dev/ufs/rootfs 108G 9.1G 90G 9% /
> devfs 1.0K 0B 1.0K 0% /dev
> /dev/msdosfs/EFI 50M 25M 25M 50% /boot/efi
> tmpfs 12G 85M 12G 1% /tmp
> /dev/da0s2 25G 1.3G 22G 6% /mailbkup
> mail#
>
> The entries for / and /boot/efi are not at all what I expected. The /mailbkup seems normal. How do I make sense of all this?

What do you mean by "not what you expected"? If you refer to
the /dev/XXX paths, then it looks like / and /boot/efi are mounted using
file system labels and /mailbkup is mounted using MBR slice.

I have instructions on how to format Raspberry Pi disk with GPT and
install FreeBSD but never got round to publishing this on my blog.

I only have Raspberry Pi 4 and I normally mount
FreeBSD-15.0-RELEASE-arm64-aarch64-RPI.img and copy all files in
/boot/efi or /boot/msdos as this contains the bootloader.

After this I manually format microSD card or USB disk with FAT32 and GPT
partitions and install FreeBSD.

The following commands were executed on Raspberry Pi 4 with FreeBSD on
microSD card and installing it again to a USB disk. You may need to
double check /boot/loader.conf in case it is different for Pi 5.

geom disk list

... and find the disk you want to install to.

Create partitions:
gpart destroy -F da0
gpart create -s gpt da0
gpart add -t efi -l "efi" -a 1M -s 64M da0
gpart add -t freebsd-ufs -l "root" -a 1M -s 32G da0
gpart add -t freebsd-swap -l "swap" -a 1M -s 4G da0
gpart add -t freebsd-ufs -l "var" -a 1M -s 4G da0
gpart add -t freebsd-ufs -l "data" -a 1M da0
gpart show -l da0

Setup U-Boot:
newfs_msdos -F 32 -c 1 /dev/gpt/efi
mount -t msdosfs -o longnames /dev/gpt/efi /mnt
cp -a /boot/msdos/* /mnt
umount /mnt

Setup UFS:
newfs -j -L root /dev/gpt/root
newfs -j -L var /dev/gpt/var
newfs -j -L data /dev/gpt/data

fetch \
https://download.freebsd.org/ftp/releases/arm64/14.0-RELEASE/base.txz \
https://download.freebsd.org/ftp/releases/arm64/14.0-RELEASE/lib32.txz \
https://download.freebsd.org/ftp/releases/arm64/14.0-RELEASE/kernel.txz \
https://download.freebsd.org/ftp/releases/arm64/14.0-RELEASE/kernel-dbg.txz

Setup root:
mount /dev/gpt/root /mnt && mkdir /mnt/var
mount /dev/gpt/var /mnt/var
for i in base lib32 kernel kernel-dbg; do tar -C /mnt -xpUf ${i}.txz; done
sync

mkdir /mnt/data

cat > /mnt/boot/loader.conf << 'EOF'
# Configure USB OTG; see usb_template(4).
hw.usb.template=3
umodem_load="YES"
# Multiple console (serial+efi gop) enabled.
boot_multicons="YES"
# Disable boot_serial as it causes console issues with single user mode
#boot_serial="YES"
# Disable the beastie menu and color
beastie_disable="YES"
loader_color="NO"
EOF

cat > /mnt/etc/fstab << 'EOF'
# Device Mountpoint FStype Options Dump PassNo
/dev/gpt/root / ufs rw 1 1
/dev/gpt/efi /boot/efi msdosfs rw,noatime 0 0
/dev/gpt/swap none swap sw 0 0
/dev/gpt/var /var ufs rw 2 2
/dev/gpt/data /data ufs rw 2 2
tmpfs /tmp tmpfs rw,size=1g,mode=1777 0 0
EOF

cat > /mnt/etc/rc.conf << 'EOF'
hostname="netsrv.home.lan"
keymap="uk.kbd"
ifconfig_genet0="inet 192.168.1.18/24"
defaultrouter="192.168.1.254"
sendmail_enable="NONE"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"
sshd_enable="YES"
powerd_enable="YES"
dumpdev="AUTO"
update_motd="NO"
EOF

cat > /mnt/etc/resolv.conf << 'EOF'
search home.lan
nameserver 192.168.1.4
EOF

umount /mnt/var /mnt

[Polytropon]

On Sat, 13 Dec 2025 13:54:04 -0800, Doug Hardie wrote:
> I have a couple of Raspberry Pi 5s. One of which is a production server
> for mail. It works just fine. However, the disk structure is quite
> confusing. I only noticed this because of trying to bring up another
> similar server.
>
> If I list the dev entries for mmcsd, I get the following.
>
> mail# ll /dev/mmcs*
> crw-r----- 1 root operator 0x49 Nov 26 15:47 /dev/mmcsd0
> crw-r----- 1 root operator 0x4a Nov 26 15:47 /dev/mmcsd0s1
> crw-r----- 1 root operator 0x4b Nov 26 15:47 /dev/mmcsd0s2
> crw-r----- 1 root operator 0x4e Nov 26 15:47 /dev/mmcsd0s2a
> crw-r----- 1 root operator 0x4f Nov 26 15:47 /dev/mmcsd0s2b
>
> This looks like the drive was partitioned using GPT.

No, looks like MBR. Suffixes s[12] are the "DOS primary partitions",
i. e., the slices, and s2[ab] are the BSD partitions inside the 2nd
slice (the labels, disklabels).

GPT partitions would be listed as p[1234...].

> However, gpart list shows MBR.

Correct.

> I removed the non-relevant entries:
>
> mail# gpart list mmcsd0
> Geom name: mmcsd0
> entries: 4
> scheme: MBR
> Providers:
> 1. Name: mmcsd0s1
> Mediasize: 52428800 (50M)
> type: fat32lba
> 2. Name: mmcsd0s2
> Mediasize: 128124452864 (119G)
> type: freebsd
>
> There are the two partitions I expected. A boot partition, and a data
> partition.

At least the 2nd partition is FreeBSD. The other one seems to be DOS
(FAT32), which typically indicates something related to (U)EFI.

> Looking at the df output:
>
> mail# df -h
> Filesystem Size Used Avail Capacity Mounted on
> /dev/ufs/rootfs 108G 9.1G 90G 9% /
> devfs 1.0K 0B 1.0K 0% /dev
> /dev/msdosfs/EFI 50M 25M 25M 50% /boot/efi
> tmpfs 12G 85M 12G 1% /tmp
> /dev/da0s2 25G 1.3G 22G 6% /mailbkup
> mail#
>
> The entries for / and /boot/efi are not at all what I expected.
> The /mailbkup seems normal. How do I make sense of all this?

The partitions also have labels, and this is what you see in the
first column, instead of the device name. As I've guessed, the
/dev/mmcsd0s1 partition was labeled "EFI" and therefore became the
entry /dev/msdosfs/EFI, mounted at /boot/efi; the /dev/da0s2 seems
odd though... it should have been da0s2a because of /dev/mmcsd0s2a,
and /dev/mmcsd0s2b is a swap device (letter "b"), so it won't show
up in the mounted volume list (because it isn't mounted at all).

The letters for the labels indicate a boot partition ("a"), a swap
partition ("b"), the whole slice as a partition ("c"), and the
subsequent letters indicate further arbitrary partitions.

See this example:

% df -h

Filesystem Size Used Avail Capacity Mounted on

/dev/ad10s1a 989M 438M 471M 48% /
devfs 1.0k 1.0k 0B 100% /dev
/dev/ad10s1d 989M 347M 563M 38% /tmp
/dev/ad10s1e 989M 407M 503M 45% /var
/dev/ad10s1f 48G 41G 3.3G 93% /usr
/dev/ad10s1g 4.9G 4G 505M 89% /opt
/dev/ad12 1.8T 1.7T 625M 100% /home

As you can see, ad12 (being ad12c in fact) is a data partition that
does not have any slices (called "dedicated"). Also swap isn't on
this list (ad10s1b).

> I duplicated the microSD card but it doesn't boot the new machine.

Using which tool? Note that GPT also might store stuff at the end of
a medium, so usually only real 1:1 copies work as expected.

> Messages shows the new disk is da1.

The device name is assigned according to detection order, that's
why labels are so convenient.

> mail# mount /dev/da1s2 /mnt
> mount: /dev/da1s2: No such file or directory
> mail# mount /dev/mmcsd1s2b /mnt
> mount: /dev/mmcsd1s2b: No such file or directory

Correct. You can not mount a slice, you need to mount a partition.
You also cannot mount a swap partition (see above).

The command should probably be:

# mount -t ufs -o ro /dev/da1s2a /mnt

or

# mount -t ufs -o ro /dev/mmcsd1s2b /mnt

Though -t ufs is the default, you can always make it explicit to
be sure. You also could use the label names, listed in /dev/ufs
or /dev/msdos (according to the file system); GPT labels exist
(if formatted GPT) in a different directory, /dev/gpt,

> I would like to verify that the new SD card is good.

A successful boot should prove it. ;-)



--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

[Liam Proven]

On Sun, 14 Dec 2025 at 06:07, Marco Moock <m...@dorfdsl.de> wrote:
>
> If that system uses EFI to boot, those partitions need to exist as they
> contain the EFI bootloader.
>
> Is that the case for your machines?

It is a Raspberry Pi. It is an ARM computer, not an x86 PC. The Pi
does not use EFI; it does not use a bootloader at all. The system is
controlled by the VideoCore GPU which runs the Microsoft ThreadX RTOS
and after that boots, the GPU loads the Arm OS from a FAT32 partition
then starts the Arm and passes it the OS image as a payload.

> efibootmgr shows you that in case you booted in EFI mode.

No, not on a Pi.

--
Liam Proven ~ lpr...@sitpub.com
Open Source Reporter, the Register ~ https://www.theregister.com/
Isle of Man tel: +44 7624 227612 ~ UK tel: +44 7939 087884 (*not* 24x7)
Czech tel: +420 702 829 053 (also WhatsApp/Telegram/Signal)

[void]

On Sat, Dec 13, 2025 at 01:54:04PM -0800, Doug Hardie wrote:
>I have a couple of Raspberry Pi 5s. One of which is a production server for mail.

>It works just fine.

>2. Name: mmcsd0s2
> Mediasize: 128124452864 (119G)
> type: freebsd

Sorry this hasn't anything to do with your question, but I'd like to ask
please:

You're running FreeBSD on the rpi5 fine?

I wasn't aware this was possible yet.
Does onboard ethernet work?
--

[Doug Hardie]

My mail server is a Raspberry Pi 5 running FreeBSD 14.3-P5. It has been running for close to a year now. I have started to bring up another server on a Pi 5, but it is not going well. I suspect the issue is the power supply appears to be intermittent. It frequently reboots during the boot process. I haven't had time to work with that lately.

The various additional chips on the Pi 4 have been integrated into the processor on the Pi 5 and as a result there are not drivers for them. I don't see any development effort in this area. I am using a USB ethernet connector. You also have to use a USB stick formatted with the boot code for the Pi 5. It is not as clean an installation as the Pi 4, but there is a significant performance improvement with the Pi 5.

-- Doug