M HYPE SPLASH
// general

Editing rc.local for Ubuntu Core

By Abigail Rogers

I am trying to create a startup script on Ubuntu Core to enable usb_modeswitch to change the mode of one of the devices connected to the device. I am running Ubuntu Core on the Dragonboard410c.

As in classic Ubuntu desktops, I tried editing /etc/rc.local

However, even though I do sudo vi /etc/rc.local I can't edit rc.local as it complains that it is only a read-only file.

I tried editing the file directly from the SD card (This works for configuration files on netplan), but somehow rc.local is not visible in the SD card.

How are you supposed to use apt style packages on boot on Ubuntu Core. Do I need to create a separate snap for this?

Thank you in advance

2

2 Answers

Check if your root filesystem is mounted with read-write permissions ( via /etc/mountab or /etc/fstab ). Read-only filesystem won't allow editing files on it, i.e. it may not be the file problem itself.

If it is read-only, use sudo mount -o remount,rw / command. Note that snappy core, iirc, is meant to be a read only filesystem for security reasons

5

The reason you can't write to /etc/rc.local is found in the mount command's output (truncated here).

/dev/mmcblk0p4 on /writable type ext4 (rw,relatime,data=ordered)
/dev/loop0 on / type squashfs (ro,relatime)

Ubuntu Core mounts the root filesystem as squashfs which is read-only. Parts of the filesystem are mounted as rw as you'll see in non-truncated output of the mount command, however rc.local doesn't live on one of these.

HOW TO GET AROUND THE PROBLEM:

Firstly, rc.local is a legacy sysvinit file which has been supplanted by SystemD which is now default in Ubuntu and every other distro.

So you can't execute a script by calling it from rc.local because it's ro. A better- and more granular way of raising services on boot- is to use a SystemD Timer. This has the advantage of raising services relative to other services. It's a scalpel vs sysvinit's rc.local machete.

To execute the script at a precise point in the boot use a SystemD Timer. A specimen script is shown below; tweak to your specific use-case

#!/bin/bash
cat <<EOF> /etc/systemd/system/myscript.service
[Unit]
Description=Customise Networking
Requires=network-online.target
After=snap.wifi-ap.management-service.service
[Service]
User=root
Group=root
Type=oneshot
ExecStart=/home/myuser/scripts/myscript.sh
[Install]
WantedBy=multi-user.target
EOF
chmod 644 /etc/systemd/system/myscript.service
systemctl enable myscript.service

This has been tested and proven to raise the custom service I created at the desired point in the boot and survives a reboot. HTH-

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password

Post as a guest

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy