-
Notifications
You must be signed in to change notification settings - Fork 261
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Augmenting firstboot.sh with our own scripts #554
Comments
Not sure if this is functionality we should offer to the average end-user. Keep in mind that if the user finds some custom script online, attempts to use it, but the code no longer works with whatever RPI OS version is currently out, and errors out, the lines that disable running the firstboot script and booting normally will not run. There are other solution that do support integrating your own custom scripts. |
I have a similar requirement and investigated firstrun.sh. I wanted to add stuff to the new user. I am adding using a new name for the user which means /home/pi/ is renamed and becomes the base for my user. I decided to insert stuff in /home/pi. I have not worked out the equivalent for those occasions when new user is created by the other code in firstrun.sh. I create /home/pi/.config/autostart/autostart.desktop when I need something run at first login. Insert the following settings. I could not get the autostart to open a terminal window so the user could see what is happening or to leave the window open so they could read the result. autostart.sh contains the following to open install.sh. install.sh contains the actual changes. firstrun.sh may not rename /home/pi which would require a different approach. There would also be differences if you do not want the user to see the changes or you want them to run before the first login. I think the options would be something like:
An alternative for my use case might be to have directory /home/firstlogin then let us copy scripts into there with the firstrun code moving everything into the user after the user is created. An improvement to to firstrun.sh code. Firstrun has $FIRSTUSER representing pi or whatever and it, in my firstrun, renamed the user to "peter". That hard coded "peter" makes changing the code harder. If "peter" was defined as NEWUSER="peter" then used as $NEWUSER, I could add code to firstrun.sh to insert stuff into /home/$NEWUSER. That might make it easier for JonTheNiceGuy and others to insert scripts. I do not know where to insert a patch to create NEWUSER="peter". |
Sorry, but this is really outside the scope of Imager. And for multi-user setups (which you are hinting at with "of every user") you typically also want others things changed. Like centralized authentication using LDAP or similar. (Something the piserver project does offer, but that never gained any popularity). |
"of every user" "The /etc/skel directory holds copies of various initialization and other files that may be copied to the new user's home directory when the /usr/sbin/useradd program adds the new user." Thinking about it, the /etc/skel option would not be used when pi is renamed. To handle both, you would have to put first-login-for-every-user in /etc/skel then copy it to pi if pi is to be renamed. A bit complicated. I still think the code change to put the new user name in a variable would make it easier for us to modify firstrun.sh in ways that target the new user. It might not help JonTheNiceGuy with his current project. Should I make it a new issue? |
I don't think that's Imager's task.
Or if it's actually the home directory instead of username you are after:
|
Feature request rejected. @maxnet has laid out the rationale, and I agree with their position. For the OP's case, I'd strongly recommend using pi-gen or another OS image creation flow. Closing as 'Won't fix'. |
I think the firstboot.sh is saved on the boot partition, it's quite easy to modify after creating the image, even automatically with sed. Just copy your own firstboot-user.sh into boot partition and add it just before the final exit 0 in the firstboot.sh |
You might find that such a simple approach doesn't work, due to the automatic-changes that https://github.com/RPi-Distro/raspberrypi-sys-mods/blob/bookworm/initramfs-tools/scripts/local-bottom/imager_fixup makes to the |
Hi! Thanks for creating this tool, it's incredibly useful!
I've recently been trying to document how to automate the provisioning of my raspberry pi on first boot. My initial sketch of this ended up using a lot of Ansible to deploy code onto the SDCard, but while recently working on a talk for a conference, I discovered firstrun.sh.
Now, while I'd dearly love to tinker with that script, the layout of the script makes it a bit dangerous to mess with it too much HOWEVER, I don't think it would be too hard to add an additional "run your own custom scripts" blob at the end of that.
I currently manually add the following code block just before the line
rm -f /boot/firstrun.sh
:(Note that this is injected in this line of
OptionsPopup.qml
)Now, why haven't I just submitted this as a PR? Well... I don't know how to do something similar in the cloud-init, short of populating the variable
cloudinitwrite
earlier on, and I don't want to provide a patch that works for 1 variant, but not the other.So; does this seem interesting and useful? If so, I'm happy to create a PR for the
firstrun.sh
variant, and then try and figure out how to do the same thing for cloud-init, unless of course, someone wants to just write it for me? ;)For context, this is what I'm personally doing this for: https://jon.sprig.gs/blog/post/category/computers/raspberry-pi-otg-usb-gadget
The text was updated successfully, but these errors were encountered: