Guide: Installation of *VANILLA* Debian 11 (or later) on a Raspberry Pi 4

[Akeo]

This guide describes the installation of vanilla Debian 11 (or later) using the official ARM64 ISO, on a Raspberry Model 4B.

Vanilla here means that we are going to be installing straight from an untouched ARM64 Debian netinst ISO, with no need for custom kernel modifications or any gymnastics of the original content before installation. In other words, by following this guide, you will get as close to the same experience as the one you have when installing Debian from an x86 ISO on an UEFI PC. As a matter of fact, once the Debian installer starts, it will be indistinguishable from a PC installation experience. You will also end up with everything you'd expect to see from a PC install, including a graphical GRUB prompt as well as a system that'll natively update its kernel and initrd, without the need for further configuration...

Overview of the entire process

Create a GPT ESP (EFI System Partition) onto an USB, extract the netinst.iso content there, add the latest Raspberry PI UEFI firmware and proceed to a standard Debian networked installation. That's it!

Or did you perhaps think that the process of installing Debian on an ARM platform would be different from the process of installing Debian on a UEFI based PC? Why on earth should that be the case? The whole point of having an SBBR-compliant UEFI firmware (which we do have for the Pi 4) is precisely so that we stop with the madness of having each ARM platform require its custom media installation and boot process. SBBR and UEFI gets you the ability to use vanilla installation media to boot and run your OS. Oh, and that works not just for Linux, but for Windows and other OSes too!

Prerequisites

Hardware

• One USB drive or SD card with sufficient space (at least 16 GB or more). A fast USB 3.0 flash-based drive is strongly recommended over anything else, as it'll provide you with a much better overall user experience.
• A Raspberry Pi 4 Model B that is physically connected to the network through the Ethernet port (i.e. For the time being, WiFi is currently hit or miss, so you are much better off trying with a wired connection).

Note that our goal here is to install the system on USB, through netinstall, using a single media for the whole installation process. That same media will also be the target for our installation. In other words, there will be no need to use an additional SD or USB media.

Also note that your Pi 4 should use an EEPROM that supports USB boot. If you purchased it after April 2020, it should probably already be the case, but if you are using an older model, and haven't updated its EEPROM yet, you should create and run an EEPROM update media using the files from here.

Software

• The latest official Debian 11 ARM64 net install ISO.
• The latest Raspberry Pi 4 UEFI firmware binary, (which also includes the relevant Broadcom bootloader support files, i.e. config.txt, fixup4.dat, start4.elf).

Preparation

• Partition the USB/SD media as GPT (not MBR) and create a ~350 MB ESP partition on it.
  Note: Make sure that you create a partition of type ESP and not "Basic Data" as Debian's partition manager will have trouble using it otherwise.
• Format the ESP as FAT32
• Extract the full content of the netinst ISO onto the ESP (including the .disk/ directory).
• Extract the full content of the UEFI firmware zip onto the ESP.
• Eject your USB/SD drive and insert it into your Raspberry Pi 4

Note: Because of Microsoft's obnoxious restrictions, that prevent its OS from mounting an ESP, you may find that the process above is difficult to accomplish manually on Windows. However, this can easily be worked around by using Rufus [disclaimer: I am the author of Rufus] which can be downloaded here.

If you are running Windows and have downloaded Rufus as well as the prerequisite files, then the process becomes:

• Launch Rufus and make sure your media is plugged in
• Click the SELECT button and select the Debian netinst ISO
• Ctrl-Click the SELECT button (yes, that means you should click SELECT again, but this time with the Ctrl key pressed at the same time) and select the UEFI Firmware zip. Ctrl-SELECT is a special mode of Rufus that allows adding files to an already selected ISO, which is what we want to do.
• Change Partition scheme to GPT (Make sure you do select GPT and not MBR or else the process will not work)
• Click START
• When prompted, choose Write in ISO → ESP mode. Note that you will only get this option is you selected GPT for Partition scheme, so if you don't see it, please double check Partition scheme.
• Let Rufus complete the media creation
• Eject your media and insert it into your Raspberry Pi 4

Installation

Just follow the Debian installer prompts. The whole point of the media creation above is so that, once you plug your USB drive and boot the Pi, the installation experience will be the same as the one you would get on a PC, so I will not be covering that in details.

The only elements I will mention are that:

• If using an SD card, you may have to alter your boot options in the UEFI firmware to either disable PXE or make it lower priority than SD card boot.
• If using an SD card, the installer will report that No Common CD-ROM drive was detected. during the media detection. You will have to perform the following:
  • On Load CD-ROM drivers from removable media select No.
  • On Manually select a CD-ROM module and device select Yes.
  • On Module needed for accessing the CD-ROM select none.
  • On Device file for accessing the CD-ROM type the following exactly:
    -t vfat -o rw /dev/mmcblk1p1
• When prompted for non-free firmware files, you should select No as WiFi is unlikely to work for installation and should be avoided. Or, if you really want, you can say yes, knowing that, if you are using an USB based installation media, you will have to unplug and replug it for each file being requested, due to a media detection bug in the Debian installer.
• When/If prompted for the network card, you should select enabcm6e4ei0 (which should be the first one in the list).
• During partitioning, you should leave the ESP as is (which the Debian installer will be smart enough to do on its own, as long as you only use the free space for the new partitions to be created). If you don't know what to choose, you should choose Guided - use the largest continuous free space which is the default.
• If you get an error dialog for Configure the package manager (apt configuration problem: An attempt to configure apt to install additional packages from the media failed) you can safely ignore it by selecting Continue and then choosing your mirror location country from the list.

The reason we want to keep the ESP as is is that it already contains the Pi firmware boot files along with the UEFI firmware and that, by default, GRUB will recognize the ESP and use it as its installation target which means that, once the system is installed, the ESP will serve as the one from which the system boots from.

Post Installation Tweaks

If you are using a 4 GB or 8 GB Raspberry Pi 4 board, and provided that you are using a Debian installation ISO that was created after 2020.09.07 (i.e. one that uses version 5.8 of the Linux kernel), you will find that the system reports only 3 GB of RAM available.

This is because (as far as we know) Broadcom botched their PCIe DMA implementation so that the VIA xHCI controller can only effectively access 3 GB of RAM unless the OS kernel implements bounce buffers or some other workaround. This workaround has recently been added into the Linux 5.8 kernel, which is what recent Debian 11 installation ISOs use, so, after you have confirmed that you are using a post 5.8 kernel (through uname -a for instance), you should perform the following:

• Reboot the OS.
• Go to the UEFI settings by pressing the Esc key when you see the UEFI firmware coloured Raspberry logo.
• Go to Device Manager → Raspberry Pi Configuration → Advanced Configuration and set Limit RAM to 3 GB to <Disabled>.
• Save the settings and reboot

Once you have done that, you will have access to the full RAM available on your device.

Also, if you did install the Wifi firmware blobs, you may find that you get the following error during boot:

Code: Select all

[  +0.000067] brcmfmac mmc0:0001:1: firmware: failed to load brcm/brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model B.txt (-2)
[  +0.000097] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
[  +0.000065] brcmfmac mmc0:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model B.txt failed with error -2

To fix that, simply rename /lib/firmware/brcm/brcmfmac43455-sdio.Raspberry to /lib/firmware/brcm/brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model B.txt. Note that the reason we have to do this is because there is a bug in the Debian installer that makes it fail to handle spaces, and therefore it can only pick the brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model B.txt blob we need to provide as brcmfmac43455-sdio.Raspberry.

Mini FAQ

Can I perform a graphical install? Does X work?

Absolutely. And if you install in graphical mode, you'll also get a graphical GRUB prompt which is nice.

What about Pi 4 devices that aren't supported yet?

It needs to be pointed out that, in order to be SBBR compliant, which is the precise reason why you can use vanilla media and vanilla installation methods, the default boot mode of the platform, as enacted by the UEFI firmware, will be ACPI and not Device Tree, so the question of having hardware X or Y supported in Linux becomes a question of having a driver with the necessary ACPI bindings in the kernel (which means that a driver that only has the Device Tree bindings will not be enough). But again, since this is a pure Linux kernel issue, and not a UEFI one, once they get added to the Linux kernel, they will naturally percolate to your networked Debian installation. Oh, and if you are impatient to have this or that driver working in vanilla Debian, by all means you should submit a driver update to the mainline kernel!

Why use netinst.iso and not mini.iso?

If you are very size conscious, you may wonder why we didn't go for Debian's mini.iso which is quite a bit smaller than netinst.iso, and can actually be used to perform an networked installation just the same. It mostly boils down with wanting to reach a trade-of between speed and size. The advantage of using netinst is that you don't have to download the base system components, so it makes the process of installing Debian faster as a result. But of course, that means that you're going to lose about 300 MB of disk space that's only going to be used once. Considering the current flash-based media capacity, we don't consider this as a major drawback, but if you see it as a dealbreaker, by all means use the smaller mini.iso and resize your ESP accordingly.

What about using the Debian 10 release?

We tried to get the Debian maintainers to backport the Genet ACPI bindings, required for network support, into the 4.x kernel used by Debian 10.x, but unfortunately they have not been receptive to that idea at all. And of course, without a working network driver, this whole process is pointless.

[geev03]

...... you will get as close to the same experience as the one you have when installing Debian from an x86 ISO on an UEFI PC. As a matter of fact, once the Debian installer starts, it will be indistinguishable from a PC installation experience. You will also end up with everything you'd expect to see from a PC install, including a graphical GRUB prompt as well as a system that'll natively update its kernel and initrd, without the need for further configuration...

...

Thank you for a very smooth installation experience.

Code: Select all

root@raspberrypi:~/Desktop# neofetch
       _,met$$$$$gg.          root@raspberrypi 
    ,g$$$$$$$$$$$$$$$P.       ---------------- 
  ,g$$P"     """Y$$.".        OS: Debian GNU/Linux bullseye/sid aarch64 
 ,$$P'              `$$$.     Host: Raspberry Pi 4 Model B C03111 
',$$P       ,ggs.     `$$b:   Kernel: 5.7.0-2-arm64 
`d$$'     ,$P"'   .    $$$    Uptime: 12 mins 
 $$P      d$'     ,    $$P    Packages: 1415 (dpkg) 
 $$:      $$.   -    ,d$$'    Shell: bash 5.0.18 
 $$;      Y$b._   _,d$P'      Resolution: 1920x1080 
 Y$$.    `.`"Y$$$$P"'         DE: Xfce 4.14 
 `$$b      "-.__              WM: Xfwm4 
  `Y$$                        WM Theme: Default 
   `Y$$.                      Theme: Xfce [GTK2], Adwaita [GTK3] 
     `$$b.                    Icons: Tango [GTK2], Adwaita [GTK3] 
       `Y$$b.                 Terminal: xfce4-terminal 
          `"Y$b._             Terminal Font: Monospace 12 
              `"""            CPU: (4) 
                              Memory: 523MiB / 2844MiB 

                                                      
                                                      

[ora726]

@Akeo,
Hi Nice to be talking to the author of Rufus, have used this on and off without knowing too much what I was doing for a long time.
I have tried to follow your Vanilla Debian 11 tutorial and am hitting a wall, wonder if you could help telling me what I am doing wrong.
First of my Goal, boot a RSPI4 4GB from a 512GB USB SSD using of course UEFI. I have managed this with Ubuntu by manually formatting the same 512GB disk as a Hybrid disk respecting the initial MBR on LBA0, adding a EFI partition including into it both the RSPI UEFI and the Ubuntu vanilla package partitioning the remaining disk space as a VG and installing the whole thing, Was very proud when it booted and would have stayed there if it wasn't for the fact that the kernel of the latest Ubunu 20.04 does not support the RSPI4 network adapter.
I tried to follow your tutorial for Debian installing both the Debian ISO and the RPI UEFI package (Using CTRL!). all fine. I can boot Debian but when It come to recognizing the disks Debian does not identify the free space on the SSD and ask me for an install media. Escaping to shell I can see /dev/sda (Disk) and /dev/sda1 (Assumed to be the EFI partition on the SSD. If I give to Debian /dev/sda as install disk he ask for drivers that I don't have. Don't understand why it would need drivers as it has already booted from that disk ?
When trying the same thing from standard USB Flash the RPI4 does not detect the disks and refuse to boot. I tried two, a 4 GB Toshiba and a 64 GB San disk, both are non bootable.
And yes, selected both the ISO and the UEFI, Selected GPT partition and selected the ISO to ESP mode.
I am sure I am doing something stupid but no amount of reading your post is getting me near to the solution.
Will try to reproduce my early success with Ubuntu by massaging my disk by hand and see if that get me nearer to a solution.
Thanks in any case fore the great tool.

[Akeo]

If I give to Debian /dev/sda as install disk he ask for drivers that I don't have. Don't understand why it would need drivers as it has already booted from that disk ?

That's because boot from UEFI and boot from Linux kernel are completely different matters. UEFI has its own device drivers, that the Linux kernel doesn't use, and the Linux kernel has its own device drivers that UEFI doesn't use. So you might as well be saying "I don't understand why Linux would ask me for drivers when Windows recognizes the same device natively...".

UEFI only helps load and boot the kernel, and then it gets completely out of the way, which means that, from that stage, anything that UEFI could access becomes inaccessible again and Linux needs to provide its own driver for it. That's actually the reason why you could use the same process with SD media instead of USB media, and you'll be able to boot the Linux kernel from SD just as you can from USB, since UEFI will have no trouble accessing either, but then the Linux installer won't be able to locate the "source cdrom" on SD, because Linux does not yet have a driver with ACPI bindings for the SD controller used by the Raspberry Pi, even though UEFI does have such a driver...

When trying the same thing from standard USB Flash the RPI4 does not detect the disks and refuse to boot. I tried two, a 4 GB Toshiba and a 64 GB San disk, both are non bootable.

I literally tested the whole process again a few hours ago, with the current weekly (2020.08.24) ISO and Rufus, and everything was fine. Considering that there's nothing that fancy happening with the media creation method in the first place anyway, since all we're doing is creating a GPT ESP and showing all content into it, I believe the problem must be somewhere else. Make sure you don't use the current daily ISO though, as the 2020.08.25 one appears to have an issue (as I pointed out, daily ISOs can be unstable, so it's better to stick with the weekly ones).

I know that, in some circumstances, the UEFi firmware boot selection or UEFI settings may not be stored properly, especially if you use an 8 GB model (we're still trying to figure out why that might be), so you need to make sure that you always use a clean UEFI firmware when you add it to your media. Did you perhaps try to re-use a firmware you had altered instead of the official download? You may also want to open a Rufus issue here and paste the complete log of the media creation in Rufus, so that I can be absolutely sure the media was created properly. Checking the SHA of your ISO to make sure it isn't corrupted might also help. Finally, I've seen issues when using subpar USB 3.0 extension cables, in case your USB drive is not plugged directly into your Pi.

[geev03]

Automatic update to "Kernel Version 5.8.0-1-arm64 (SMP) aarch64" on a "Sony UK Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS UEFI Firmware v1.19 08/13/2020
CPU"

Code: Select all

System Vital

Canonical Hostname
raspberrypi.home
Listening IP
192.168.1.133
Kernel Version
5.8.0-1-arm64 (SMP) aarch64
Distro Name

Debian GNU/Linux bullseye/sid

OS Type

Linux

Uptime
8 minutes
Last boot
Sun, 13 Sep 2020 07:00:16 GMT
Current Users
0
Load Averages
0.02 0.15 0.10
0%

System Language
English United Kingdom (en_GB)
Code Page
UTF-8
Processes
101 (3 running, 56 sleeping, 42 other)

Hardware Information

Machine
Sony UK Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS UEFI Firmware v1.19 08/13/2020
CPU
Number of processors:
4

Cortex-A72

Cortex-A72

Cortex-A72

Cortex-A72
USB
Number of devices:
4

[Akeo]

Yes, 5.8.0.1 is now the default kernel of Debian 11. Or at least that seems to be the case for the 2020.09.07 weekly ISO, which is good news.

If you have a 5.8 kernel, and a 4 GB or 8 GB model, you should go to the UEFI settings (Esc key during boot) and and then go to Device Manager → Raspberry Pi Configuration → Advanced Configuration and set Limit RAM to 3 GB to <Disabled>. This will allow you to access the full 4 GB or 8 GB of RAM of the Pi as the default for the UEFI firmware is to limit it to 3 GB, on account that Linux 5.7 kernels or earlier need a patch, that was only added in 5.8, to fix xHCI DMA access above 3 GB.

I have now updated the guide to reflect the fact that using a recent Debian 11 image should allow you to use full RAM.

[geev03]

......
If you have a 5.8 kernel, and a 4 GB or 8 GB model, you should go to the UEFI settings (Esc key during boot) and and then go to Device Manager → Raspberry Pi Configuration → Advanced Configuration and set Limit RAM to 3 GB to <Disabled>. This will allow you to access the full 4 GB or 8 GB of RAM of the Pi as the default for the UEFI firmware is to limit it to 3 GB, on account that Linux 5.7 kernels or earlier need a patch, that was only added in 5.8, to fix xHCI DMA access above 3 GB.

I have now updated the guide to reflect the fact that using a recent Debian 11 image should allow you to use full RAM.

Pure Debian ,"with out any gymnastics"...
Thank you.

[geev03]

Debian 11 is proving to be useful with automatic Kernel updates .
The 'sd card copier', in Raspberry OS, cannot copy the 'USB drive with Debian 11'. How can the USB stick be cloned to an USB ssd drive ?

[Akeo]

How can the USB stick be cloned to an USB ssd drive ?

Just use dd in Linux. e.g. dd if=/dev/sd# of=/dev/nvme# bs=8k status=progress where /dev/sd# is your USB device (you WILL need to determine what it is by yourself, and make sure this is your source USB device) and /dev/nvme# is your target SSD device (you WILL need to determine what it is by yourself, and make ABSOLUTELY sure this is your target SSD device, as dd is very unforgiving if you use the wrong target drive, and it's very easy to make a costly mistake. The device name may very well be something that doesn't contain "nvme" at all).

Or, instead of cloning, you can just follow the process above and install Debian 11 on your USB SSD from scratch, and then copy your data by plugging the USB stick, since you will then be able to access its data from the booted SSD.

Note that these questions have very little to do with the process of installing Debian 11, so they would be better asked on a general user forum, like https://superuser.com/, as I'd rather keep this thread focused on actual Debian 11 installation issues.

[moto.es]

Hi. I can't create media disk on my USB 3.0 stick with Rufus. Here is rufus log file.
Scanning image...
ISO analysis:
Image is an ISO9660 image
Disk image analysis:
Image has a Zeroed Master Boot Record
Image is a bootable disk image
ISO label: 'Debian testing arm64 n'
Size: 324 MB (Projected)
Note: File on disk is larger than reported ISO size by 3.3 MB...
Uses: EFI
Note: This ISO uses symbolic links, which will not be replicated due to file system limitations.
Because of this, some features from this image may not work...
Using image: debian-testing-arm64-netinst.iso (308.3 MB)
Using archive: RPi4_UEFI_Firmware_v1.20.zip (2.5 MB)

Format operation started
Requesting disk access...
Will use 'D:' as volume mountpoint
Deleting partitions (This may take a while)...
Deleting ALL partition(s) from disk '\\?\PhysicalDrive1':
● Partition 1 (offset: 1048576, size: 29.9 GB)
Opened \\.\PhysicalDrive1 for exclusive write access
No logical drive found (unpartitioned?)
Drive does not appear to be partitioned
Analyzing existing boot records...
Drive has a Zeroed Master Boot Record
Clearing MBR/PBR/GPT structures...
Erasing 128 sectors
Initializing disk...
Partitioning (GPT)...
● Creating EFI System Partition (offset: 1048576, size: 383 MB)
Waiting for logical drive to reappear...
Timeout while waiting for logical drive
Logical drive was not found - aborting

Found USB 3.0 device 'Samsung Flash Drive DUO USB Device' (090C:1000)
No logical drive found (unpartitioned?)
1 device found
No volume information for drive 0x81
Disk type: Removable, Disk size: 32 GB, Sector size: 512 bytes
Cylinders: 3899, Tracks per cylinder: 255, Sectors per track: 63
Partition type: GPT, NB Partitions: 1
Disk GUID: {F660A59B-B508-4F2B-959E-84442FF3F834}
Max parts: 128, Start Offset: 17408, Usable = 32078002688 bytes
Partition 1:
Type: EFI System Partition
Name: 'EFI System Partition'
ID: {C3BFC9FD-A38A-443D-B434-DDFDB8A0BCB6}
Size: 383 MB (401604608 bytes)
Start Sector: 2048, Attributes: 0x0000000000000000
Found USB 3.0 device 'Samsung Flash Drive DUO USB Device' (090C:1000)
No logical drive found (unpartitioned?)
1 device found
No volume information for drive 0x81
Disk type: Removable, Disk size: 32 GB, Sector size: 512 bytes
Cylinders: 3899, Tracks per cylinder: 255, Sectors per track: 63
Partition type: GPT, NB Partitions: 1
Disk GUID: {F660A59B-B508-4F2B-959E-84442FF3F834}
Max parts: 128, Start Offset: 17408, Usable = 32078002688 bytes
Partition 1:
Type: EFI System Partition
Name: 'EFI System Partition'
ID: {C3BFC9FD-A38A-443D-B434-DDFDB8A0BCB6}
Size: 383 MB (401604608 bytes)
Start Sector: 2048, Attributes: 0x0000000000000000

And Rufus end with code error: Windows error code 0xC00305B4 (FormatMessage error code 0x00003AFC)
Can someone tell me what does it mean. I tried to change USB stick to 2.0 16Gb, and it's the same result. Thanks for any help.

[Akeo]

The error you get may indicate that another application (which may be the Windows low level services themselves) is preventing access to the drive.

Here's what you can try:

• Check if you're using any applications listed here (bearing in mind that this list in NOT exhaustive and that you may be using a conflicting application that isn't mentioned there).
• Unplug and replug the drive multiple times.
• Zero the drive with Alt-Z in Rufus.
• Create a FreeDOS bootable drive in Rufus to see if you get the same error.

Unless you have a conflicting application, insisting and zeroing the drive should eventually work.

[moto.es]

Hi evrybody. I have resolved my problem creating media with Rufus on USB 3.0 32Gb stick. On windows 7 X64 Pro, Rufus didn't want to create media, but on Windows 8 X64 evrything went fine. Problem solved.

[moto.es]

Hi Akeo. You're right. Windows 7 preventing access to the stick. Once I have seen for moment a message that windows is accessing the stick. Thanks for Your quick reply.

[gilius]

Nice guide - but after I installed and opened VLC it could barely playback a video that works fine in Raspbian Buster! I then tried to install Kodi and found that the app isn't available in the default repository.

[geev03]

Nice guide - but after I installed and opened VLC it could barely playback a video that works fine in Raspbian Buster! ...

Yes it is a nice guide and, for me, the video playing by 'VLC media player' is very smooth. Just downloaded the video ,that was playing smoothly online, here ( https://www.nytimes.com/2020/09/16/book ... cubed.html ) and it has no problem in playing with VLC media player.

[geev03]

"This document informs users of the Debian distribution about major changes in version 11 (codenamedbullseye)." ,

https://www.debian.org/releases/bullsey ... tes.en.pdf

[b3lt3r]

Apologies for the dumb question.

I currently have a couple of Pi3s running Ubuntu and RpiOS64 respectively which do an initial boot off SD card but mount / from NFS hosted off another Pi. Why? Not so long ago I could buy 64G SSDs but now the absolute smallest is 120G and it's overkill for me. I like the concept of being able to create 7+ environments on 1 SSD and feel safe as I think the SD card just boots firmware and processes cmdline.txt (I think). Anyway it works and bizarrely enough has so far been totally stable running over NFS. Well it is on ethernet, wifi is possible but not reliable on my network.

So. Is there a way to achieve the same scheme on a Pi4 or Pi3 running Debian? Ie, bootstrap off SD or USB just enough to mount and continue to boot from a Debian NFS partition?

I'm assuming that by following this guide I can run netinst from the USB stick but instead of installing the OS to that media I can install to a separate USB connected SSD and once done, it bootstraps UEFI from USB and then continues SSD or have I misunderstood? In my simple head it feels like it should be possible but this is 2020

[Akeo]

I think the only answer to your somewhat off-topic query is: Try it. Then you'll see.

I'm afraid you are trying to do something very custom that few people are likely to be concerned with, let alone have tried on a Pi, so the best way (and probably only way) to get the answer to your question is carry out your own research.

Technically, I don't see why it shouldn't work. Once you have a kernel and a base Linux environment, you can literally do anything you want during init, including mounting NFS shares, as long as you script it. So it "should" work. But the figuring out of how to do it practically on a Pi 4 will be up to you.

[b3lt3r]

Hi

Fair enough - I am going to do that anyway. Hopefully the on-topic portion is that there's nothing stopping installation to an alternate SSD rather than USB? Correct?

Thanks

Mike

[Akeo]

The topic describes the installation of Debian on a single USB drive, nothing more nothing less. The Debian installer should let you pick a different media if you want, but no promise is being made as to being able to make that work easily. Especially, you're definitely going to have to go through manual extra steps to make a separate drive boot, since you won't have the Raspberry Pi boot files or the UEFI firmware.

Once again, if you choose to deviate from the guide, it's up to you to figure out anything extra you have to carry out to make it work. I make absolutely no promise that what's being described in the guide will work, if you choose to deviate from it.

[trejan]

This is because (as far as we know) Broadcom botched their PCIe DMA implementation so that the VIA xHCI controller can only effectively access 3 GB of RAM unless the OS kernel implements bounce buffers or some other workaround.

This limitation was fixed in the C0 stepping of the BCM2711. The PCIe controller can access all the RAM now.

[geev03]

Debian bullseye, Kernel 5.9 ,on 1 core of the 4 core rPi4/8

Code: Select all

root@debian:~# neofetch
       _,met$$$$$gg.          root@debian 
    ,g$$$$$$$$$$$$$$$P.       ----------- 
  ,g$$P"     """Y$$.".        OS: Debian GNU/Linux bullseye/sid aarch64 
 ,$$P'              `$$$.     Host: linux,dummy-virt 
',$$P       ,ggs.     `$$b:   Kernel: 5.9.0-1-arm64 
`d$$'     ,$P"'   .    $$$    Uptime: 11 mins 
 $$P      d$'     ,    $$P    Packages: 1398 (dpkg), 3 (snap) 
 $$:      $$.   -    ,d$$'    Shell: bash 5.1.0 
 $$;      Y$b._   _,d$P'      Resolution: 2560x1440 
 Y$$.    `.`"Y$$$$P"'         DE: MATE 1.24.1 
 `$$b      "-.__              WM: Metacity (Marco) 
  `Y$$                        Theme: Menta [GTK2/3] 
   `Y$$.                      Icons: menta [GTK2/3] 
     `$$b.                    Terminal: mate-terminal 
       `Y$$b.                 Terminal Font: Monospace 13 
          `"Y$b._             CPU: (1) 
              `"""            GPU: 00:0f.0 VMware Device 0406 
                              Memory: 811MiB / 1922MiB 

                                                      
                                                      

[xplanefan]

I'm trying this now and keep running into issues.

First, copying the iso contents to the vfat partition is mostly successful aside from the symlinks in a few directories (fat filesystems can't handle symlinks). The GPT/ESP partition was made in fdisk followed by mkfs.vfat. I have made direct copies of the missing files but still get the following errors after the Pi successfully boots into the installer.
------

Error message 1:

Incorrect installation media detected

In /var/log/syslog I see:

The CD in /dev/sdb1 is not a Debian CD!

I get around this by forcing a mount of /dev/sdb1 to /cdrom in a terminal.

------

Error message 2:

Unable to determine the codename for the release.

I keep a copy of the original iso file on the usb stick and mount that to /cdrom instead of /dev/sdb1.

------

The next string of errors that I can't work around is the following in the /var/log/syslog:

(process:28746): /usr/lib/apt-setup/generators/50mirror: line 32: is_ports_architecture: not found
INFO: Menu item 'apt-setup-udeb' succeeded but requested to be left unconfigured.
INFO: Falling back to the package description for brltty-udeb
INFO: Falling back to the package description for brltty-udeb
INFO: Menu item 'save-logs' selected
INFO: Falling back to the package description for brltty-udeb
INFO: Falling back to the package description for brltty-udeb
INFO: Menu item 'bootstrap-base' selected
base-installer: warning: attempting to install to unclean target
debootstrap: /usr/sbin/debootstrap --components=main --debian-installer --resolve-deps --no-check-gpg bullseye /target file:///cdrom/
debootstrap: tar: can't open './usr/share/doc/gcc-10-base/README.Debian.arm64.gz': File exists
base-installer: error: exiting on error base-installer/debootstrap-failed
WARNING **: Configuring 'bootstrap-base' failed with error code 1


------

Might there be a bug(s) in the latest weekly release of testing iso? I don't see any issues when installing amd64 on a x86 system. Am I missing something else here?

[Akeo]

If you have a /dev/sdb then it means that you have two disks plugged in, and therefore it appears that you are deviating from the guide, as you should only ever have one disk plugged in on your Pi 4 for the whole installation (which will become the disk onto which you install Debian).

If you follow the guide, the installation media should be /dev/sda1. Can you check your dmesg to find out what is instantiated as /dev/sda on your system?

With regards to your other error, bear in mind that Debian testing is expected to be unstable (which is why I point to using weekly rather than daily builds, but even these can be unstable). So the error you get might very well be a Debian bug. But I would still like to understand why you appear to have both a /dev/sda and a /dev/sdb when there should ever be one media plugged onto your Pi 4 during installation...

[xplanefan]

I started off with just one USB stick as your guide states but started hitting these issues right away. Is the Pi4 process different than an x86 system in that regard?

2 sticks was an experiment/attempt at getting around the errors, given they seemed to be mount issues; more closely match what a desktop install would be like.

I haven't had any issues getting the Pi to boot into the installer and the second stick is always a blank, clean drive. The installer always correctly creates partitions before hitting the current fatal error and there are no unexpected warnings or behaviors in dmesg output.

I have certainly seen installer problems in weekly Testing releases in years past. No errors though in the amd64 version of this week's release (install into virtmanager on a x86 platform).