raspberrypi-sys-mods/firstboot
TrystanLea opened this issue · 15 comments
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 ?
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
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
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?
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
@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.
@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
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?
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
Root partition created is significantly larger on this build
Lots more 'junk' included? You know me, I'm a fan of DietPi 😆
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.
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 :-)
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.
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
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.
I have raised the issue with the RPi-OS folk. Seem to be open to offering it as an option at some point. @TrystanLea
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.