How can I prevent root to expand at first boot?

[ybizeul]

This is a weird one, I read everywhere that Raspbian uses a 2G or so root partition by default and you have to explicitely expand it if you need the space.

I don't want to expand root, I want to create a separate FAT filesystem on remaining space.

Right after first boot I get the following partitions :

Code: Select all

Filesystem      Size  Used Avail Use% Mounted on
/dev/root        15G  3.3G   11G  24% /
devtmpfs        459M     0  459M   0% /dev
tmpfs           463M     0  463M   0% /dev/shm
tmpfs           463M  6.3M  457M   2% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           463M     0  463M   0% /sys/fs/cgroup
/dev/mmcblk0p1   63M   21M   43M  33% /boot
tmpfs            93M     0   93M   0% /run/user/1000

As you can see, it's using all the 15G remaining on that 16G card.

Now, I'm headless so I don't see what is going on at first boot, maybe there is a default validation I need to interrupt but I don't have a keyboard.

[HawaiianPi]

Did you install Raspbian with Noobs?

[kusti8]

The new OS expands automatically. You can easily reverse this by shrinking the partition in fdisk and using redize2fs. I don't know what process resizes it automatically and if you can disable that with a Linux computer manually. But why do you want a separate FAT partition?

[scruss]

... I want to create a separate FAT filesystem on remaining space.

I'm sure you have the best reasons for doing this, but second and subsequent partitions won't be readable under Windows.

[klricks]

This is a weird one, I read everywhere that Raspbian uses a 2G or so root partition by default and you have to explicitely expand it if you need the space.

It's about 4G and everyone needs the extra space. There is very little room left in the default partition so in many cases, if not expanded, the user will run out of disk space and trash the OS, even on the very first update / upgrade, depending on what is upgraded or installed.

...... I don't want to expand root, I want to create a separate FAT filesystem on remaining space.

I can't think of any reason to add a FAT partition. Linux will be more efficient with a ext format and Windows will be unable to access the 2nd FAT partition anyway. Windows can only access the first partition on any removable media and with the RPi, the first partition is the small 60M boot partition.

..
Now, I'm headless so I don't see what is going on at first boot, maybe there is a default validation I need to interrupt but I don't have a keyboard.

The expanding is automatic without user intervention.

[ybizeul]

So, I ended up creating my separate "media" partition right after writing the card.

I use a mac, but here are the steps basically :

• Use fdisk to grow partition 2 because it'll be too small in the current state to support more packages, also create an additional partition with type 7 for ExFat.
• Format that partition with mkfs (or diskutil eraseVolume on the mac) I used ExFAT filesystem
• At first boot, Raspbian complains, just restart.
• use resize2fs to grow the root partition and restart

Sorry I don't have more details I forgot to capture the terminal.

It's definitely weird though that Raspbian grows the filesystem by default.

[kusti8]

It's not weird. It makes sense. If you know enough to make a FAT partition, you know enough to shrink and existing one. But this helps beginners by making it a more easy use and get them easier started. I can't tell you how many posts Ive seen where someone hasn't expanded the filesystem.

[ybizeul]

Did you install Raspbian with Noobs?

No, I installed the latest Raspbian installer only. NOOB would require me to deal with a keyboard on the TV I think, not a fan. I know it's only for the installation but the raw installer just seemed simpler to me

[ybizeul]

It's not weird. It makes sense. If you know enough to make a FAT partition, you know enough to shrink and existing one. But this helps beginners by making it a more easy use and get them easier started. I can't tell you how many posts Ive seen where someone hasn't expanded the filesystem.

Yes I saw all the posts with "Where is my space !!!", that's why I thought Raspbian wasn't supposed to do it. Is it something that changed recently?

You can't shrink ext3/4 live. without copying everything over. To do this you need another hard drive it's a real PITA.

[ybizeul]

The new OS expands automatically. You can easily reverse this by shrinking the partition in fdisk and using redize2fs. I don't know what process resizes it automatically and if you can disable that with a Linux computer manually. But why do you want a separate FAT partition?

I want a separate ExFAT partition to be able to stick the SD card in a computer to copy media files directly without going through the network. The mac won't read ext4 by default, ExFAT is much more convenient

[ybizeul]

This is a weird one, I read everywhere that Raspbian uses a 2G or so root partition by default and you have to explicitely expand it if you need the space.

It's about 4G and everyone needs the extra space. There is very little room left in the default partition so in many cases, if not expanded, the user will run out of disk space and trash the OS, even on the very first update / upgrade, depending on what is upgraded or installed.

It makes sense when you know it, what's confusing is I saw everyone needing to use raspi-config to grow root, so I thought it would work out for me

...... I don't want to expand root, I want to create a separate FAT filesystem on remaining space.

I can't think of any reason to add a FAT partition. Linux will be more efficient with a ext format and Windows will be unable to access the 2nd FAT partition anyway. Windows can only access the first partition on any removable media and with the RPi, the first partition is the small 60M boot partition.

Yes, root always need some space, but I intent to put a much bigger card, and I need something that the mac will be able to write to (the mac will mount any recognized filesystem) and that would support big media file : ExFAT seemed like a natural choice.

..
Now, I'm headless so I don't see what is going on at first boot, maybe there is a default validation I need to interrupt but I don't have a keyboard.

The expanding is automatic without user intervention.

Yes that's what I noticed, it creates a disposable init script that grows root, I just found it weird that there is no way to customize this.

Thanks for the help!

[DirkS]

Yes I saw all the posts with "Where is my space !!!", .

That was actually more of a nuisance, rather than the main problem.
The real problem was that it caused all kinds of weird behaviour (black screen instead of GUI on boot), filesystem corruption, etc.
IIRC the new behaviour was announced about 1 or 2 months ago and I think it was eagerly anticipated by regular 'responders' (certainly by me).
The auto-resize was actually introduced with the images released yesterday.

In the distant past Raspbian would start to the CLI and the first thing users would see was the raspi-config menu. Most users would expand the filesystem, because it was the first item in the menu.
Later (last year I think) the default was changed to boot to GUI and the config utility wasn't started automatically anymore.

TBH I expected that some users wouldn't like this new behaviour, but I think it was the right thing to do.

[Saamir]

Has the OP question been answered? I see a lot of discussion about why you don't need to disable it, but what if there is one reason for disabling it that I consider valid? /rant

If someone can tell me where the expansion is taking place, I can figure out how to customize it and post that back here. But I've searched /lib/systemd, /etc/init.d, /etc/init for expand|resize|extend etc., and I've found nothing. I've looked through the output of "systemd-analyze dump" and that led nowhere, I deleted raspi-config and that didn't make it go away.

If someone can tell me who the developer(s) are, where detailed release notes can be found, where the source repository is, anything that would lead me in a direction, I'll be forever in your debt!

[B.Goode]

Has the OP question been answered? I see a lot of discussion about why you don't need to disable it, but what if there is one reason for disabling it that I consider valid? /rant

If someone can tell me where the expansion is taking place, I can figure out how to customize it and post that back here. But I've searched /lib/systemd, /etc/init.d, /etc/init for expand|resize|extend etc., and I've found nothing. I've looked through the output of "systemd-analyze dump" and that led nowhere, I deleted raspi-config and that didn't make it go away.

If someone can tell me who the developer(s) are, where detailed release notes can be found, where the source repository is, anything that would lead me in a direction, I'll be forever in your debt!

See viewtopic.php?f=66&t=148492&hilit=expand - I think there is a pointer provided there? Possibly from a developer, or someone very close to the developers.

[PeterO]

See viewtopic.php?f=66&t=148492&hilit=expand - I think there is a pointer provided there? Possibly from a developer, or someone very close to the developers.

That's not to do with preventing it happening on sdcards. It was to do with making sure it doesn't do anything silly if the root file system isn't on an sdcard.
PeterO

[asandford]

If someone can tell me where the expansion is taking place, I can figure out how to customize it and post that back here. But I've searched /lib/systemd, /etc/init.d, /etc/init for expand|resize|extend etc., and I've found nothing. I've looked through the output of "systemd-analyze dump" and that led nowhere, I deleted raspi-config and that didn't make it go away.

The OP said they found a 'disposable script' - so, I reckon it deletes itself when first run - hence you can't find it.

[Saamir]

If someone can tell me where the expansion is taking place, I can figure out how to customize it and post that back here. But I've searched /lib/systemd, /etc/init.d, /etc/init for expand|resize|extend etc., and I've found nothing. I've looked through the output of "systemd-analyze dump" and that led nowhere, I deleted raspi-config and that didn't make it go away.

The OP said they found a 'disposable script' - so, I reckon it deletes itself when first run - hence you can't find it.

Actually I'm searching on an SD image before booting, so it should be pristine. But yeah, I had to think about that.

[Saamir]

See viewtopic.php?f=66&t=148492&hilit=expand - I think there is a pointer provided there? Possibly from a developer, or someone very close to the developers.

Thanks @BGoode! That was it. I didn't even think of looking on the /boot partition. But it makes sense to do it before mounting the root partition.

To disable automatically expanding the root partition on first power-up, I:

• Used losetup to create a loop device from the raspbian distribution image, and mounted the first partition.
• Edited the cmdline.txt file removing the "quiet" and "init=..".
• Then mounted the second partition, and removed the /etc/rc3.d/S01resize2fs_once symlink.
• Unmounted the partitions and deleted the loop device.
• Burned the image file to an SD card, and booted it.

Now I can resize the partition/fs at my leisure.

[rvfh]

In case you have not found yet, there is a service that destroys itself after execution: resize2fs_once. It does the FS resize, but I have not found out what does the partition resize yet...

I guess you could just remove the file from its location (/etc/init.d), though it's not very clean.

[rvfh]

OK got it: the partition is resized as part of apply_noobs_os_config, same location.

[peterlite]

Another idea. When you restore the Raspbian image, allocate the FAT partition after the Ext4 partition. The Ext4 partition should not expand into allocated space.

You can also delete about 2 GB out of the 4 GB Raspbian partition: https://petermoulding.com/raspberry-pi/ ... d_software

[sandvoss]

This is not so weird a problem. I'd like to configure a new Raspbian image and then read it back so that I can write the configured image on other SD cards or back on the original card when I want to start over. So here is what you do:

Code: Select all

sudo dd if=raspbian-stretch-lite.img of=/dev/sde

(or whatever your card device is)
Mount both partitions of the SD card, let's say as /media/x/boot and /media/x/rootfs.

Code: Select all

sudo touch /media/x/boot/ssh
sudo nano /media/x/rootfs/etc/init.d/resize2fs_once

In the script resize2fs_once, write a new line "exit 0" directly below the # lines so that it will be the first line that's executed. Save the file.

Depending on your network setup, you might also want to copy a working conf to /media/x/rootfs/etc/wpa_supplicant/wpa_supplicant.conf if you use wifi to connect to your RaspberryPi.

Umount, place SD card in the RaspberryPi and boot it up. You can then ssh to it and log in as pi/raspberry to configure it.
Be aware that that's only possible in a local network. To be able to connect from the outside via ssh, you need to edit /etc/ssh/sshd_config after you have changed your password.

Anyway, use "sudo raspi-config" to configure your RaspberryPi and possibly generate new host keys for ssh.
If you want to have the image resized the next time the Raspberry boots, take the exit 0 line out of /etc/init.d/resize2fs_once. If not, leave it in.

Now it's time to read the image back to save it for later. The original image is 1862270976 bytes big. That's exactly 1776 MB.

Code: Select all

sudo umount /dev/sde?
sudo dd if=/dev/sde of=raspbian-date-configured.img bs=1048576 count=1776

[radilly]

Thanks @sandvoss! This is very close to what I have in mind. I'm using Stretch Lite, but I have a few common packages I always add and want to create a starting image that includes them, and perhaps a README with some notes.

Wondered if you, or someone else could help me generalize the construction of this command a little:

Code: Select all

sudo dd if=/dev/sde of=raspbian-date-configured.img bs=1048576 count=1776

I want to make sure I (and maybe others) understand the bs= and count= numbers.

This is a Stretch-Lite image before any mods as an example. Looking at it via fdisk...

Code: Select all

$ sudo fdisk -l /dev/sdc
Disk /dev/sdc: 3.8 GiB, 4026531840 bytes, 7864320 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5906b8f2

Device     Boot Start     End Sectors  Size Id Type
/dev/sdc1        8192   93486   85295 41.7M  c W95 FAT32 (LBA)
/dev/sdc2       94208 2548186 2453979  1.2G 83 Linux

If I literally wanted to use what fdisk is telling me (and do no math), I think I would use the following. Here, bs comes from the sector size, and count is the largest number on the End column:

Code: Select all

sudo dd if=/dev/sdc of=raspbian-date-configured.img bs=512 count=2548186

I believe a bigger bs value can speed things up, however it looks to me like it could only be doubled (and still remain a power of 2).

Can anyone confirm this is correct?

Cheers, and Thanks!

Ref: http://man7.org/linux/man-pages/man1/dd.1.html

[scruss]

if you leave off count, dd will read all the blocks it can. This will typically be the full size of the filesystem.

bs harks back to tapes that really cared about the physical record size. Modern filesystems are less picky, and larger bs values generally result in faster transfers. The RPF Installing operating system images on Linux guide suggests trying bs=4M (= 4 × 1024 × 1024 bytes) but with the caveat “Please note that block size set to 4M will work most of the time. If not, try 1M, although this will take considerably longer.”

[jahboater]

guide suggests trying bs=4M (= 4 × 1024 × 1024 bytes) but with the caveat “Please note that block size set to 4M will work most of the time. If not, try 1M, although this will take considerably longer.”

The "cp" command uses 128KB block size and it was slightly faster than dd when I last measured it.
(It does also call fadvise(...POSIX_FADV_SEQUENTIAL) to increase the readahead).
cp is obviously much simpler to use as well.

If I went back to using dd, I'd just stick with 1M - I have had it fail with 4M, as noted above.