Hi,
I have a customized Ubuntu Core based on core18 for amd64.
The image disk has an additional partition that I have to mount in a specific position in the rootfs.
I want to adopt a solution that is consistent with the rest of the system, i.e. I want to implement the mount of the partition in the same way (if possible) that is used to mount the boot partition (/dev/sda2 in my case) under /boot/efi/ and /boot/grub/.
Can someone show me where this mount is done? I can’t find it.
you could just add another volume to your gadget snap, but i’m not sure we have a way to extend fstab or to add a systemd mount unit without actually hacking the image …
you could try using a snap with udisks2 to mount the partition here is an example that i use for external disks:
Thank you for the reply.
I’ve already created a new volume in the gadget snap.
Hacking the image is not a problem because I’m already building the image using a customized version of core18, pc-gadget-amd64 and pc-kernel snaps.
I can’t edit /etc/fstab directly because it is auto-generated by writable-paths (as you know for sure), and I can’t find who is adding /dev/sda2 to /etc/fstab:
dev@localhost:~$ cat /etc/fstab
# Auto-generated by /init
# DO NOT EDIT THIS FILE BY HAND - YOUR CHANGES WILL BE OVERWRITTEN
# (See writable-paths(5) for details)
/dev/root / rootfs defaults,ro 0 0
LABEL=writable /writable auto defaults 0 0
...CUT...
/dev/sda2 /boot/efi auto defaults 0 2
/boot/efi/EFI/ubuntu/ /boot/grub none bind 0 0
For what I can see /dev/sda2 doesn’t come from /etc/system-image/writable-paths, but I’m not able to find who is mounting it.
pretty please dont do that, it will most likely break snaps you install if the wrong bits have been changed, the core snap is a guaranteed execution environment that every snap can 100% rely on. if you change any of its contents without potentially adapting the way snaps get executed this is not supportable …
what exactly did you change ? there are huge amounts of core users out there that manage to do everything via their configuration snaps without having to hack the core snap itself.
this is the boot code in the initrd, nothing you could or should easily change without breaking other aspects of the system, i’d really recommend using a snap to do the auto-mounting into /media and then consume data from there via the removable-media interface from your application snap …
The udisks2 snap is no longer in the store. Is there some underlying reason neither of these snaps are in the store? This seems like pretty useful functionality.
well, maintaining them takes time and effort, they are non-trivial and provide way to valuable system level functionality to leave them in a bad state in the store …
the source is available so people can re-use it and perhaps someone from the community would like to permanently maintain a snap in the store for them
