I have a Raspbian Buster working well on my Pi 3 B. How can I transfer this system to a new Pi 4? I don't want to reinstall everything, because I have a edited many system files. (It's wouldn't be as "easy" as (re-)installing 50 packages, and transferring /home. I'd also have to identify and copy the many changed system files, somehow.)

My troubleshooting

  1. I've tested the new Pi with a freshly-downloaded Raspbian Buster Lite system, and can confirm that the new Pi is working.
  2. I've tried simply moving the old card over, but the Pi won't boot. The ACT LED briefly flickers green (1–3 flickers for 1 second, then a sustained light for ~1 second), but then no light. I get no HDMI signal. (As a control, I've also tested without an SD card inserted. Here, the ACT LED flashes four times: three short and one long.)
  3. I've thought perhaps that the newer boot partition from the fresh system was essential, so I tried rsyncing root from the old card into the new card's rootfs. However this also failed as per 2 above.
  • 4
    Just put the SD Card in the Pi4 and it should work (unless you have some special setup which prevents it). I use the same card from my Pi3 in Pi4.
    – Milliways
    Sep 22 '19 at 0:48
  • @Milliways I already tried that (as per point 2)! It didn't work for me! I guess the "special setup" might be the pertinent part, but I don't know what that is.
    – Sparhawk
    Sep 22 '19 at 1:03
  • 1
    Neither do we. You need to detail what files you changed. What happens when it doesn’t boot?
    – Milliways
    Sep 22 '19 at 1:13
  • 1
    Just a thought but you could try sudo apt-get update; sudo apt-get install --reinstall raspberrypi-bootloader raspberrypi-kernel on the Pi3 which will put it back to the latest supported kernel/bootcode.
    – Milliways
    Sep 22 '19 at 7:22
  • 1
    If you have already trouble you shouldn't use rpi-update in addition. It is only for testing unstable firmware and may increase trouble.
    – Ingo
    Oct 3 '19 at 11:25

Had also the problem that my raspbian card from pi3 did not run in pi4 after upgrade to buster.

I found out that the install skript of bootloader and kernel do skip the installation of rpi4 support when there is not enough space on /boot/. My boot partition was around 100 Mb, its from the time when rpi2 was new. You can check the size of your partition with:

df -H



you can also check if the install skript says you havn't enough space by reinstalling and checking the output of:

apt-get install --reinstall raspberrypi-bootloader* raspberrypi-kernel*

if you see the following output, you have the same Problem:

You do not have enough space in /boot to install this package.
Skipping Pi 4 support

To solve this problem i used a separate computer and changed the size of the /boot partition to at least 500Mb (usual size on other Linux) by the following steps. (assuming first partition is boot, second is root, using gparted for partion manipulation)

  1. Backup whole SD

  2. shrinking root Partition to the right to have free space for boot

  3. copy content of boot partition to separate backupfolder

  4. remember boot partition flags

  5. delete and recreate boot partiton with the same filesystem in free space

  6. set the partition flag from point 4

  7. copy content of backupfolder (see point 3) into boot partion folder

  8. check your /etc/fstab is still valid to boot (more to this following)

  9. boot sdcard in rpi3 and reinstall "raspberrypi-bootloader* raspberrypi- kernel*"

  10. boot sd in rpi4

my /etc/fstab did not reference /boot by uuid, if your fstab file has a entry like:

UUID=2e45-11ea /boot                       vfat    defaults,noatime        0 2

you need to change the uuid to the new uuid of the new boot partition. You can find the uuid in gparted under information. i had no problem with my /etc/fstab, it has this entry:

/dev/mmcblk0p1  /boot           vfat    defaults,noatime  0       2
  • Thanks @Julian (+1). Unfortunately I am no longer in a position to test new solutions, but I do remember seeing others with small boots causing issues. However, I also remember my boot partition was definitely large enough, so this probably doesn't apply to me. (Also, instead of copying boot back and forth, you could probably just enlarge it in situ?)
    – Sparhawk
    Jan 3 '20 at 22:41
  • What does it mean: "shrinking root Partition to the right"? How do you do it?
    – Ingo
    Jan 5 '20 at 12:47
  • In gparted your disks are displayed from left to right ( sector 0 to end of disk) your boot partition is probaply the first then root so you need to move root to left. My boot partition was a vfat and resizing did not work for any reason, so i discribed what worked for me.
    – Julian
    Jan 8 '20 at 5:49

If you can count those "flickers" they might give you a hint as to what is going wrong. There is a sticky on the raspberry pi forums that deals with Pis that won't boot. The link is https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=58151. Note that there is a special section for RPi 4s. There's also a MagPi #60 troubleshooting guide that may help. That link is https://www.raspberrypi.org/magpi/issues/60/.

This weekend my RPi 4 wasn't booting. The ACT was blinking 4 times. According to the sticky that is a signal that the boot process couldn't find all the files on the SD card needed to boot. I hope that the sticky or the article helps you identify the problem.

  • Thanks you for the answer. I've updated my question to include the precise details of the LED's flashes. From the links, it's unclear what this means.
    – Sparhawk
    Oct 3 '19 at 9:39

I've thought perhaps that the newer boot partition from the fresh system was essential, so I tried rsyncing root from the old card into the new card's rootfs.

This is a horrible idea and while it may or may not explain why the system apparently doesn't get far boot-wise (depending on exactly how you did it), I certainly would not expect this to result in a working operating system, and if it did, I would not trust that installation.

What you should have done is copy the boot partition of the new buster install that works on the Pi 4 over (as in, replace the contents of) the one that doesn't. From the root partition then replace /lib/firmware/ and /lib/modules in the same direction (from working to non-working). This presumes the new image is really a new image created since the introduction of the Pi 4.

If that will boot on one Pi but not another, either:

  1. You did it wrong.
  2. The other Pi is busted.

So, if you can still boot the Pi with a different card, either it has a very peculiar defect, or you are stuck with door #1.

  • Thank you. I've run into some other issues, so I'll test this in a week or so and report back.
    – Sparhawk
    Sep 23 '19 at 5:47
  • To address the first part, I didn't exactly imagine this to be the long-term solution, but just a stage of troubleshooting. Having said that I'm not exactly sure what the difference between the two alternatives are (i.e. both have boot from the new working system, and root from the original, modified system). In any case, I tried copying the working boot to the old card (deleting the old files), as well as replacing the other two directories you mention. It actually progresses further than before. I get (expected) random flashes on the ACT LED, and the screen now shows! However…
    – Sparhawk
    Oct 3 '19 at 11:46
  • it now hangs for ~2 minutes before random: crng init done. I assume it is this bug (which I've come across on another system, and fixed with mashing keys at first, then installing haveged later). Even worse, the Pi hangs after that message as well, for at least half an hour. I'm not sure what the next message should be, but FWIW I tried plugging in a keyboard and randomly mashing keys, to no avail.
    – Sparhawk
    Oct 3 '19 at 11:49
  • Like I said, based on your description, I am not surprised it does not work, and I doubt you can fix it. Even if you do get it to boot, who knows what surprises are in store when it runs. The lesson here is that you need to come up with a means to 1) Back stuff up effectively, 2) (At least semi-) automate system configuration. Ending up dependent on a particular installation because you don't know how to re-create it easily is prone to ending badly and implies a lot of wasted energy. It's a question of whether you stop and do this now, or next time (or the time after that...).
    – goldilocks
    Oct 3 '19 at 12:25
  • There are plenty of tools around explicitly for these purposes. For system configuration, look into puppet or chef or ansible, etc. I'm sure you'll find Pi oriented tutorials for all of those, even chef vs. puppet: thuisapp.com/2016/06/12/using-chef-provision-raspberry-pis
    – goldilocks
    Oct 3 '19 at 12:37

It is difficult to see what may be wrong. Here are some general tries I would start with. First make a working copy of your running installation and verify that the copy is still running on the RPi 3B. Only work with the copy.

Then I would use the serial debug console in the hope the kernel will tell me some errors before getting stuck. You have to purchase a serial to TTL adapter like this one https://www.amazon.com/ADAFRUIT-Industries-954-Serial-Raspberry/dp/B00DJUHGHI. There are much cheaper adapter from china and they are as good as that from adafruit but it takes weeks to get them. With a serial terminal program on your laptop you can manage the RasPi. On Linux I suggest to use tio /dev/ttyUSB0, that's made for this. On the RasPi you have to enable the serial console with enable_uart=1 in /boot/config.txt.

Then I would chroot into the copy and perform a full-upgrade in the hope it will update the latest firmware for the RPi 4B. So insert the copied SD Card into your portable card reader and attach it to the RPi 4B. Then boot it with Raspbian Buster Lite as you already have done. Now you should find the SD Card maybe on /dev/sda. Chroot to it:

rpi ~$ sudo -Es
rpi ~# mkdir /mnt/p2
rpi ~# mkdir /mnt/p2/boot
rpi ~# mount /dev/sda2 /mnt/p2
rpi ~# mount /dev/sda1 /mnt/p2/boot
rpi ~# cd /mnt/p2
rpi ~# mount --bind /proc proc
rpi ~# mount --bind /sys sys
rpi ~# mount --bind /dev dev
rpi ~# mount --bind /dev/pts dev/pts
rpi ~# mkdir run/udev
rpi ~# mount --bind /run/udev run/udev
rpi ~# LANG=C.UTF-8 chroot /mnt/p2 /bin/bash

rpi ~# apt update
rpi ~# apt full-upgrade

rpi ~# exit   # from chroot
rpi ~# umount proc
rpi ~# umount sys
rpi ~# umount dev/pts
rpi ~# umount dev
rpi ~# umount run/udev
rpi ~# exit    # from sudo

rpi ~$ sudo poweroff

Now boot with the upgraded SD Card. Good luck :-)

If it still doesn't work you can look at a very early bootup stage what debug messages the bootloader you give with the serial to TTL adapter. A Raspberry Pi 4B has its bootloader stored in an EEPROM so you can reflash it with another config. How to do it look at Raspberry Pi 4 boot EEPROM and in man rpi-eeprom-update. Here in short the steps I have tested. Get the default configuration:

rpi ~$ rpi-eeprom-config /lib/firmware/raspberrypi/bootloader/critical/pieeprom-2019-09-10.bin --out bootconf.txt

In bootconf.txt I set BOOT_UART=1 and cleaned up spaces behind the last entry and blank lines at the end. I don't know why they are there. To make a new image with the modified configuration and flash it then do:

rpi ~$ rpi-eeprom-config /lib/firmware/raspberrypi/bootloader/critical/pieeprom-2019-09-10.bin --config bootconf.txt --out pieeprom-new.bin
rpi ~$ sudo rpi-eeprom-update -d -f ./pieeprom-new.bin

Now on reboot I get this additional output on the serial console where it should be able to see where booting get stuck:

[ 1284.473982] reboot: Restarting system

PM_RSTS: 0x00001020
RPi: BOOTLOADER release VERSION:f626c772 Sep 10 2019 10:41:52 BOOTMODE: 0x00000006 part: 0 BUILD_TIMESTAMP=1568112110
uSD voltage 1.8V

PM_RSTS: 0x00001000
RPi: BOOTLOADER release VERSION:f626c772 Sep 10 2019 10:41:52 BOOTMODE: 0x00000006 part: 0 BUILD_TIMESTAMP=1568112110
uSD voltage 3.3V
SD HOST: 200000000 CTL0: 0x00000000 BUS: 100000 Hz div: 2000 status: 0x1fff0000 delay-ticks: 1080
SD HOST: 200000000 CTL0: 0x00000f00 BUS: 100000 Hz div: 2000 status: 0x1fff0000 delay-ticks: 1080
CID: 001b534d3030303030107ce814ef00f3
CSD: 400e00325b590000775d7f800a400000
CSD: VER: 1 logical blocks: 30557 mult: 1024 rd(len: 512 partial: 0 misalign: 0) sectors: 31291392
SD: bus-width: 4 spec: 2 SCR: 0x02358003 0x00000000
SWITCH_FUNC: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000038001800180018001800180c800
SD HOST: 200000000 CTL0: 0x00000f04 BUS: 40000000 Hz div: 6 status: 0x1fff0000 delay-ticks: 2
MBR: 0x00002000,  258048 type: 0x0c
MBR: 0x00041000,31025152 type: 0x8e
MBR: 0x00000000,       0 type: 0x00
MBR: 0x00000000,       0 type: 0x00
part-offset: 8192 oem:  mkfs.fat volume:  BOOT
rsc: 32 sectors-per-fat: 1985 clusters: 254046 cluster-size: 1 root-dir: 2 root-sectors: 0
WEL: 0x00002fa2 0x00040fff
PM_RSTS: 0x00001000
Partition: 0
part-offset: 8192 oem:  mkfs.fat volume:  BOOT
rsc: 32 sectors-per-fat: 1985 clusters: 254046 cluster-size: 1 root-dir: 2 root-sectors: 0
Loading config.txt hnd: 0x0001596f
Initialising SDRAM 'Micron' 16Gb x1 total-size: 16 Gbit 3200
Loading recovery.elf hnd: 0x00000000
Failed to read recovery.elf error: 6
Loading start4.elf hnd: 0x00024d8f
Loading fixup4.dat hnd: 0x0002efda
MEM GPU: 76 ARM: 948 TOTAL: 1024
FIXUP src: 128 256 dst: 948 1024
Starting start4.elf @ 0xfec00200
  • Thank you. I've run into some other issues, so I'll test this in a week or so and report back.
    – Sparhawk
    Sep 23 '19 at 5:47
  • @Sparhawk Added setup to monitor debug messages from the bootloader. It may help to see what's the problem with booting.
    – Ingo
    Oct 3 '19 at 13:44

To migrate a working Raspbian system from a Raspberry Pi 3 to a 4:

Assuming you're running Stretch and need to upgrade to Buster:

  1. Back up your card
  2. Update and upgrade: sudo apt update && sudo apt dist-upgrade -y
  3. Edit repository sources: sudo nano /etc/apt/sources.list
    • Change "stretch" to "buster": deb http://raspbian.raspberrypi.org/raspbian stretch main contrib non-free rpi becomes deb http://raspbian.raspberrypi.org/raspbian buster main contrib non-free rpi
    • Also edit the entries in the .list files in /etc/apt/sources.list.d
  4. Update and upgrade again: sudo apt update && sudo apt dist-upgrade
    • Notice I didn't add -y; this means you will have to babysit the upgrade a bit.
  5. Clean up: sudo apt autoremove -y && sudo apt autoclean
  6. Reboot

This should do it. These are modified instructions from https://pimylifeup.com. The only snag I ran into was having to add keys for a repository. It was a lot smoother than I expected.

  • 3
    But the OP was already running Buster when they wanted to move to RPi 4. Nov 12 '19 at 13:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.