raspberrypi-sys-mods/firstboot

[TrystanLea]

The latest RaspberryPi OS Lite 32bit /boot/cmdline.txt looks like this:

console=serial0,115200 console=tty1 root=PARTUUID=b1214a26-02 rootfstype=ext4 fsck.repair=yes rootwait quiet init=/usr/lib/raspberrypi-sys-mods/firstboot

Note in particular:

init=/usr/lib/raspberrypi-sys-mods/firstboot

is different from previous call to resize only.

first boot contains the following items that appear important:

main () {
  get_variables

  if check_variables; then
    do_resize
  fi

  # Switch to dhcpcd here if Imager < v1.7.3 was used to generate firstrun.sh
  fix_wpa > /dev/null 2>&1

  whiptail --infobox "Generating SSH keys..." 20 60
  regenerate_ssh_host_keys

  if [ -f "/boot/custom.toml" ]; then
    MSG="Applying customisations from custom.toml...\n"
    whiptail --infobox "$MSG" 20 60
    apply_custom "/boot/custom.toml"
  fi

  fix_partuuid

  return 0
}

It looks like it would be worth calling everything apart from do_resize?

any thoughts @borpin @alexandrecuer ?

[TrystanLea]

Root partition created is significantly larger on this build, perhaps I built the last one on a 16GB card Im not sure:

Filesystem      Size  Used Avail Use% Mounted on
/dev/root        20G  1.4G   18G   8% /
devtmpfs        776M     0  776M   0% /dev
tmpfs           937M     0  937M   0% /dev/shm
tmpfs           375M  1.1M  374M   1% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs            30M     0   30M   0% /tmp
tmpfs           1.0M     0  1.0M   0% /var/tmp
tmpfs           1.0M     0  1.0M   0% /var/lib/php/sessions
/dev/mmcblk0p1  255M   50M  206M  20% /boot
/dev/mmcblk0p3  9.9G   14K  9.4G   1% /var/opt/emoncms
tmpfs           188M     0  188M   0% /run/user/1000

vs July21 image

Filesystem      Size  Used Avail Use% Mounted on
/dev/root       4.1G  2.1G  1.9G  53% /
devtmpfs        805M     0  805M   0% /dev
tmpfs           934M     0  934M   0% /dev/shm
tmpfs           934M   17M  917M   2% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           934M     0  934M   0% /sys/fs/cgroup
tmpfs            30M     0   30M   0% /tmp
tmpfs           1.0M     0  1.0M   0% /var/tmp
tmpfs           1.0M     0  1.0M   0% /var/lib/php/sessions
/dev/mmcblk0p3  9.9G  7.3M  9.4G   1% /var/opt/emoncms
/dev/mmcblk0p1  253M   48M  205M  19% /boot
log2ram          50M   16M   35M  31% /var/log
tmpfs           187M     0  187M   0% /run/user/1000

[alexandrecuer]

Do yu focus here on the resizing of the SD card ?

Just a comment : you can conveniently resize with gparted. And so yu can bypass the init_resize.sh plus cmdline.txt

[TrystanLea]

Yes I wonder if I should do that just use gparted to create those initial partitions for the image.. and then have init_resize extend the data partition later maybe?

[alexandrecuer]

So the raspios uses now :
https://github.com/RPi-Distro/raspberrypi-sys-mods/blob/master/usr/lib/raspberrypi-sys-mods/firstboot

And not any more the init_resize.sh :
https://github.com/RPi-Distro/raspi-config/blob/master/usr/lib/raspi-config/init_resize.sh

If i understand correctly ?

In our process, sizes were fixed :

EmonScripts/install/init_resize.sh

Line 68 in 532784d

#EmonSD Fix end of Rootfs

[borpin]

@alexandrecuer - remember the scripts allow a user to run the scripts on a fresh install.

IIRC, shrinking the rootfs was the issue (it didn't like it), hence modifying the partition on startup was the preferred method.

Yes, we fixed the size of rootfs to make the data partition as large as possible.

[alexandrecuer]

@borpin : I understand totally

anyway when a user has got a linux OS, he can adjust the size with gparted and it is ultra simple. You do not need to be an expert of anything from my point of view. Moreover, those whishing to create their own cards are not newbies...

for example, I use google tensorflow and emoncms and so I need space on the root. For me, when i burn a new sd, it is much more simple to use gparted than to rework the init_resize file

by the way, I now use the 64 bits OS on most of my field installation without a problem for more than one year

[borpin]

I understand totally

Good - just checking we weren't talking as cross purposes.

anyway when a user has got a linux OS, he can adjust the size with gparted and it is ultra simple.

And change the partition type etc to get the long life we have achieved? If it can, ideally we'd script it so it is repeatable. The other thing of course is that we are building an image that is as small as possible then expanded.

Another of the issues was the image was too big at one point.

It is much more simple to use gparted than to rework the init_resize file

Of course but that is post install. Here we provide a preinstalled image, as small as possible, that then has to expand to the card size. We did that by duping the old resize PiOS used.

I'm not saying the gparted isn't the way to go (we need to do something), just that there are other considerations and previously we found this worked.

I now use the 64 bits OS

RaspberryOS?

[borpin]

This was the thread re Linux 5.10 v 5.15

https://community.openenergymonitor.org/t/random-hangs-of-emonpi-emonsd/20802/48?u=borpin

[borpin]

Root partition created is significantly larger on this build

Lots more 'junk' included? You know me, I'm a fan of DietPi 😆

[alexandrecuer]

no, in my case it is preinstall or postinstall. You can change the partition type to ext2 if you want, if your remark is related to this. For the size, I dont remember, but it is true it is a big file, and my latest image is here :
https://dromotherm.github.io/documentation/download.html

yes, the raspiOS 64 bits 5.15.32

now I use a makefile, so I do everything with one single file of 400 lines, and no more 50 files to mantain or to browse, only one.
since that, I have zero installation problems
It is a step by step process, it creates all the required conf file by itself.

#133

for all python services I develop in order to interact with emoncms, I use a similar process based on a single makefile to install all the services.
I can make install and make uninstall, which is good because sometimes yu have to uninstall.

but that is only my experience, nor I do not say that this is the ultimate solution :-)

[borpin]

For the size, I dont remember, but it is true it is a big file

Yes that is a significant issue and one we have avoided by this approach.

The advantage of adapting the builtin resize operation, is it just works with no user interaction into a headless EmonPi for instance.

[alexandrecuer]

just watching the sizes.
mine is 1.3 Gb and the last OEM is 1.8 Gb
once uncompresses mine is 15 931 015 168 bytes whereas OEM is 15 485 370 368 bytes

it is anyway true with your method, the user do not have to interact

[borpin]

anyway when a user has got a linux OS, he can adjust the size with gparted and it is ultra simple.

I've remembered the main issue. You cannot shrink the rootfs live. You can expand it. This was the problem we faced.

[borpin]

I have raised the issue with the RPi-OS folk. Seem to be open to offering it as an option at some point. @TrystanLea

RPi-Distro/raspberrypi-sys-mods#69

[borpin]

I think for creating the SD Card, simply add a partition first in the spare space so it doesn't expand rootfs on first boot rather than edit the firstboot file.