On Tue, May 07, 2019 at 10:33:48PM +0200, Ladislav Michl wrote:
> On Tue, May 07, 2019 at 05:59:36PM +0000, Trent Piepho wrote:
> > On Tue, 2019-05-07 at 17:49 +0200, Ladislav Michl wrote:
> > > On Tue, May 07, 2019 at 09:31:28AM +0200, Ladislav Michl wrote:
> > > > On Mon, May 06, 2019 at 07:44:09PM +0200, Ladislav Michl wrote:
> > > > > [slot.rootfs.0]
> > > > > device=/dev/ubi0_0
> > > > > type=ubifs
> > > > > bootname=system0
> > > > >
> > > > > Now system is booted with rootfs mounted read only which makes
> > > > > mounting seed
> > > > > slot fail:
> > > > > rauc[871]: Mounting /dev/ubi0_0 to use as seed
> > > > > rauc[871]: launching subprocess: mount -t ubifs /dev/ubi0_0
> > > > > /run/rauc/rootfs.0
> > > > > rauc[871]: posix_spawn avoided (fd close requested) (child_setup
> > > > > specified)
> > > > > rauc[871]: mount: /run/rauc/rootfs.0: /dev/ubi0_0 already mounted or
> > > > > mount point busy.
> >
> > What does the kernel show in /proc/mounts in this case? If it's
> > "/dev/ubi0_0", then it should match based on the simple path compare.
>
> System is using barebox' bootchooser with boot loader specification. Here
> device is ubi0:rootfs0. And yes, device name could be changed in rauc's
> slot configuration to be ubi0:rootfs0 allowing path compare succeed.
Well, that is actually not true, with
[slot.rootfs.0]
device=ubi0:rootfs0
type=ubifs
bootname=system0
rauc will try to be smart here:
$ rauc status
Compatible: Foomatic System
Variant:
Booted from: system0
Activated: rootfs.0 (system0)
slot states:
rootfs.1: class=rootfs, device=/etc/rauc/ubi0:rootfs1, type=ubifs,
bootname=system1
state=inactive, description=, parent=(none), mountpoint=(none)
boot status=good
rootfs.0: class=rootfs, device=/etc/rauc/ubi0:rootfs0, type=ubifs,
bootname=system0
state=booted, description=, parent=(none), mountpoint=(none)
boot status=good
> But see bellow why it is worth changing code a bit.
The only way to make it work now is to use /dev/ubi0_0 and fix barebox to use
the same naming scheme.
Also, there are more problems with mtd:<name> (those are passed to flash_erase)
or
ubi:<volume> (passed to mkfs.ubifs) schemes, so some kind of normalizing device
names is required anyway. Either that or making each kind (block devices (ext4,
vfat), mtd, ubi..) of slot type to be descendants of common slot ancestor and
let them handle all those quirks on their own [*].
[patch stripped]
...and instead of my previous patch to bind mount seed slot, r_mount_slot
should be modified to do just that if ext_mount_point is assigned as
all remaining code logic suggests it is right thing to do.
Btw, it looks like development nad review is done on github using web
interface. Would that explain low volume of this very mailing list?
I would really appreciate some brief review of suggested solutions to
problems with using rauc with barebox bootchooser and ubi volumes.
They do work for me (quick hacked), but I'm new to rauc codebase
and it is easy to break somene else usecase.
Thank you,
ladis
As a side note, why does rauc depend on glib? Does not seem to be intended
to be portable and if it just for all those hash or list containers, isn't
that exactly what STL is for? Also imagine it to be OOP ;-) Common slot
object with all those specialities encapsulated on its descendants. Not
that it cannot be done in C even with glib, but...
_______________________________________________
RAUC mailing list
