Dear ogra:
Currently , Creating a system user is essential for us. So we must make sure that the udisk is available。
You said that we can modify the initrd for the our need. I want to know that the initrd need to be updated in future?
If the snapd will update the initrd, the system will can’t use the updated initrd(provided by ubuntu, standard ). ?..
And you said that we can use kernel plugin to build our kernel. maybe we need try to build kernel by kernel plugin instead of the pre-built image.
and I can use the kernel-initrd-modules to list we needed kernel modules. But the modules need some parameters when inserting. How can I do for this issue ?
you dont, snapd has a systemd job and udev rues that check for attached usb devices on every boot and at plug-in, just use an USB stick with a user assertion on it and it should be read.
the only valuable thing to have in the initrd is support to find your root disk (SD, mmc, USB or whatever else you have attached to run the system from) … everything else should really be handled after the rootfs is up. for that case /etc/modprobe.d is writable on the system, you can put something into it after you created the SD card in /writale/system-data/etc/modprobe.d (create that dir if needed) from a PC…
you need to make sure our system-user assertion is signed by the exact same key that was used to sign the model assertion, else the system will not accept it
Dear ogra:
what’s mean the following information:
Starting Wait until snapd is fully seeded…
Sep 13 03:34:39 localhost snap[1447]: cmd_auto_import.go:145: imported /run/snapd/auto-import/OV2_YgCy3eT8mcHK90zFkqEhVqdecr299smXNJ8DBnVyAfsE2z1UcTGPlENVyUfS.assert
Sep 13 03:34:39 localhost systemd[1]: Started Wait until snapd is fully seeded.
Sep 13 03:34:39 localhost sh[815]: sed: can’t read /run/systemd/netif/leases/*: No such file or directory
Sep 13 03:34:39 localhost snapd[1412]: api.go:2183: ignoring system-user assertion for “root@localhost”: cannot add system-user “root@localhost”: “rsb4220” not in models [“rsb4220.model”]
if MxZc2QJWIe09yxtEQ3yfFbHd56xWZ9HW is the brand-id used in the model assertion you used for building the image, then i’m out of ideas here, perhaps @pedronis can help further …
EDIT: oh, wait … (the broken formatting tricked me) … your model assertion of the device seems to be rsb4220, but your system-user assertion defines model: advantech, this cant work indeed, the name of the model needs to match.
Dear orga:
How can I add a boot start script into core image (not that by snap insatll to insatll)?
that is , when I use ubuntu-image generate a image, the scripts is in the /writeable/etc/…/.
do you mean from a snap package ? there is no interface for general disk access, a snap will only be able to access certain bits of the filesystem in context of its own sandboxing …
the list of environment variables that point to writable locations on disk is in:
in the snapcraft.yaml of your kernel snap in case you are fine to load g_serial as module and only have the serial port available once the initrd is unpacked …
one other (rather hackish) approach is to use an initrd snippet in your gadget that puts a script and systemd unit in place on first boot …
an example for a gadget that ships an initrd snippet is:
Hardware watchdog is supported by default after snapd 2.34.
You can use the “snap set” command to config the watchdog parameters[1].
Eg $ snap set core watchdog.runtime-timeout=1m
Set a timeout value in seconds (or in other time units if suffixed with “ms”, “min”, “h”, “d”, “w”). The watchdog hardware (/dev/watchdog) or the kernel option systemd.watchdog-device=) will be programmed to automatically reboot the system if it is not contacted within the specified timeout interval.
$ snap set core watchdog.shutdown-timeout=10m
It works as a safety net to ensure that the reboot takes place even if a clean reboot attempt times out. Note that the shutdown-timeout applies only to the second phase of the reboot, i.e. after all regular services are already terminated, and after the system and service manager process (PID 1) got replaced by the systemd-shutdown binary.
The backend is integrated with systemd[2], you can check the configuration in /etc/systemd/system.conf.d/10-snapd-watchdog.conf
Hi,ogra.
The initrd.img in my image generated by ubuntu-image seem to be different from core.snap. It seem to be the one in kernel.snap. And ubuntu-image do not put the one in core.snap in the image file.What is the different between the two initrd.img files?
When you build the kernel snap, snapcraft downloads the core snap and copies initrd.img-core into your kernel snap, if you added any extra kernel-initrd-modules: or kernel-initrd-firmware: in your snapcraft.yaml it will re-pack this initrd and add the required modules.
The one in core is the generic initrd containing all generic scripts and bits needed to boot. Most of the time this is simply copied directly in place from the core snap, only if your snapcraft.yaml of the kernel snap enforces the use extra firmare or modules via the above options it is modified.
The initrd used during boot is always the one coming from the kernel snap. At image build time ubuntu-image will take care that it lives in a place where your boot setup can find it via the snap_kernel= uboot.env variable.