From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Date: Thu, 9 May 2019 13:32:55 +0200 Sender: Ladislav Michl From: Ladislav Michl Message-ID: <20190509113255.GA23108@lenoch> References: <20190506174409.GA23081@lenoch> <20190507073128.GA649@lenoch> <20190507154902.GA30791@lenoch> <1557251975.31309.83.camel@impinj.com> <20190507203348.GA5030@lenoch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190507203348.GA5030@lenoch> Subject: Re: [RAUC] Failed to mount seed slot To: Trent Piepho Cc: "ejo@pengutronix.de" , "rauc@pengutronix.de" , "jlu@pengutronix.de" List-ID: 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: (those are passed to flash_erase) or ubi: (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...