SIze of Pi4 /boot

It "should" be set to a reasonable (correct) size when you copy the image to the SD card (etcher, dd or similar). However, I have found the same sort of error as you. I generally format a new card with FAT partition of 1G, ext4 for the rest and then rsync the "old" card partitions to the "new" one. Yes, I know 1G FAT is overkill, but big SD cards are cheap these days. Check the values in /boot/cmdline.txt and /etc/fstab after rsync.

--

Chris Elvidge, England

Raspbian installer allocates 256Mb.

__________________________________ On an expanded 32-bit Raspbian I see /boot: 253 MB size, 53 MB used, 200 MB avail, 21% used

pi@RasPi-22:~ $ df -h Filesystem Size Used Avail Use% Mounted on /dev/root 29G 5.7G 23G 21% / devtmpfs 1.8G 0 1.8G 0% /dev tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 1.9G 9.6M 1.9G 1% /run tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup /dev/mmcblk0p1 253M 53M 200M 21% /boot tmpfs 386M 0 386M 0% /run/user/109 tmpfs 386M 0 386M 0% /run/user/1000

__________________________________ On an expanded 64-bit Raspbian I see /boot: 253 MB size, 54MB used, 199 MB avail, 22% used

pi@RasPi-23:~ $ df -h Filesystem Size Used Avail Use% Mounted on /dev/root 29G 3.2G 25G 12% / devtmpfs 1.8G 0 1.8G 0% /dev tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 1.9G 2.3M 1.9G 1% /run tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup /dev/mmcblk0p1 253M 54M 199M 22% /boot tmpfs 380M 0 380M 0% /run/user/1000

--
Cheers, 
David 
Web: http://www.satsignal.eu

Thanks to all for the responses.

I solved the complaint by moving the root partition upward by 86 megabytes, enough to get space for a

128 Mib /boot.

The size of Pi4 /boot is around 53 megabytes, so

64 megabytes should already do it.

----

Another oddity: The /boot partition is in FAT32, but the Windowses do not like FAT32 smaller than

500 Mib, so the partition has to be deleted and re-created in the desired size, of course saving and restoring the contents separately.

Maybe Pi is happy to boot from a FAT16, as well. I have not tried it yet.

--

-TV

More space may be required during updates, so don't make it just big enough. 128MB is OK currently, but 256MB gives enough room for future expansion, such as if the number of kernels supplied increases.

Who cares what Windows thinks! :)

If you have a large enough card and aren't worried about a few meg, you could use a 512MB partition. I have for the Pi which I dual boot between

32 and 64 bit OS's.

I'd don't believe the GPU has code to boot from anything other than FAT32, but I haven't tried it either.

---druck

Re: Re: SIze of Pi4 /boot By: Tauno Voipio to druck on Sun Jun 07 2020 13:33:04

TV> I'd rather see an ext2 partition accepted for the boot, but TV> FAT seems to be cast on silicon in the GPU.

are you (and others) saying that the rPi does not have a CPU (Central Processing Unit)? that everything it does is done by the GPU (Graphical Processing Unit aka Video Card/Chip)? are terminologies being mised up here?

)\/(ark

FATxx are Windows specifications. The tools available on Linux and OS X do respect the Windows desires, so there's a problem. Another thing that does not conform to Windows usage is the use of lower case letters in the partition label. If the Windows partition type must be used, it should be used correctly.

I'd rather see an ext2 partition accepted for the boot, but FAT seems to be cast on silicon in the GPU.

--

-TV

Doesn't that depend on the cluster size? For normal 512 byte clusters, the minimum fat32 partition size is 32 MB.

(I guess 512 byte isn't "normal" really, but the old standard and now minimum for fat32.) So 256 MB for 4 KB clusters, etc. So doesn't Windows adjust the cluster size depending on what size volume you request?

It has both, but the gpu controls the boot up process & activates the cpu after reading the firmware from disk. The gpu is sort of its bios.

On Sun, 07 Jun 2020 09:52:03 +1300, snipped-for-privacy@f1.n70.z4350.fidonet.org (mark lewis) declaimed the following:

The SoC used in the R-Pi uses the GPU to perform initial boot operations. It uses a Broadcom provided binary. The GPU loads that binary, and when running, the binary proceeds to load Linux into the RAM allocated to the ARM CPU, followed by releasing the ARM CPU to run with the loaded Linux image.

That Broadcom binary expects to find a device tree blob, and a core OS image, in the first partition -- which it appears to also expect will be a FAT file system.

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

On Sun, 7 Jun 2020 11:57:31 -0000 (UTC), A. Dumas declaimed the following:

Not that I can see... Granted, I'm not trying to repartition a flash memory, but the format operation on a 32GB "thumb drive" reports:

FAT32 (can be changed to NTFS or exFAT)

16kB allocation unit (can be changed to 8, 16, 32, 64kB)

Okay -- digging up the Disk Management control as a test. A 256MB partition defaults to FAT(16) with 4kB allocation size.

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

Previous Pis are happy to boot from FAT16, and I would expect the Pi 4 to be similar.

Fun fact: the ROM in a Pi 1 doesn't use FAT long filenames, so in 8.3 land your file has to be called LOADER.BIN - if it's called loader.bin it can't find it. The long filenames make that problem go away for 99% of us (the file is called LOADER.BIN as an 8.3 filename and whatever case we choose as the long name), but if your filesystem puts lower case in the short names, even if the file is uppercase in the long name, it doesn't work.

Theo

The trouble is Microsoft keeps changing the rules after everyone else followed the specs.

I remember having problems with FAT16 disks, where Windows wouldn't see the files a non Windows machine wrote, and the non Windows machine wouldn't see the files that Windows had written. Both sets of files were there though.

The reason being is that FAT16 was originally specified with a fixed size root directory following on from the FAT, but at some point Microsoft started using FAT32's variable sized root directory on FAT16. Therefor non Windows machines used the old fixed sized directory as the format specified, but Windows used a different root directory - which is right and which is wrong?

So at some point Windows will break FAT32 so Pi's can't boot, so you are safer using a Linux tool which will produce partitions which follow the spec at the time the Pi was created, and ignoring any spurious warnings from Windows.

---druck

In article (Dans l'article) , druck

In the 1980s IBM did just the same.

Barely a part of the Token Ring was standardized and the equipment was "improved" to (again) become incompatible with that available from the "partners".

--
Jean-Pierre Kuypers

There never were official published specs, it's all reverse engineering.

-- Steve O'Hara-Smith | Directable Mirror Arrays C:\>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. |

On 08/06/2020 13:54, druck wrote: []

[]

The trouble is that things on Linux keep changing in ways which are not backwards compatible, and the versions of software within distros are not kept up-to-date. Out of date examples - ntp, gpsd. Incompatible examples - gpsd, Raspberry Pi serial ports.

Backwards compatibility is something which Microsoft appears to care somewhat more about - not that I'm saying they are perfect, far from it.

--
Cheers, 
David 
Web: http://www.satsignal.eu