mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Robert Karszniewicz <r.karszniewicz@phytec.de>
To: barebox@lists.infradead.org
Subject: Re: Using bootspec with RAUC and redundant partitions
Date: Wed, 30 Sep 2020 12:50:42 +0200	[thread overview]
Message-ID: <05d1fc13-9491-bf89-9aec-ecb0c9e051ec@phytec.de> (raw)
In-Reply-To: <c88ecdbe8296e1e05b546115b2e3d21e@protonic.nl>

Hello, Robin.

On 9/30/20 11:19 AM, robin wrote:
> Hi Enrico, Sascha,
> 
> On 2020-09-30 10:09, Enrico Jörns wrote:
>> Hi Robin,
>>
>> Am Mittwoch, den 30.09.2020, 09:39 +0200 schrieb Sascha Hauer:
>>> > Is there a door number 3 or am I missing something here?
>>>
>>> What's the reason for additional kernel partitions? Things would be
>>> easier if you put the kernel images into the rootfs partitions along
>>> with the bootspec entries.
>>
>> the road to success here is to not encode any slot-/partition-specific
>> information in the bootspec entries.
> 
> I see.
> 
>> Why this would work anyway is because barebox extends the kernel
>> commandline with the root= entries required to boot the kernel from
>> that specific partition where it did read the entry from.
>>
>> This way it should work having an A+B setup with only two rootfs
>> partitions that include the kernel, the (generic) bootspec entry and
>> the rootfs itself (as Sascha already pointed out).
> 
> We've decided to separate the kernel from the OS a long time ago because,
> back then, we wanted to keep the bootloader simple, minimal and solid and
> including ext4 support didn't quite fit into that picture. Also, our
> customer used to create their own rootfs, and we'd build them a kernel
> and back then we didn't bundle releases (like rauc does now).

I don't know if it helps in your case, but we had a similar problem 
(wanted rootfs and kernel separate, but couldn't predict the rootfs 
partition device number in kernel). We ended up with a patch to barebox 
that allows specifying the rootfs device, which barebox then converts to 
"root=PARTUUID=".

The patch is currently on 'master':
d39a98718154 ("bootm: add global.bootm.root_dev env var for booting via 
PARTUUID")

Maybe it helps.

Regards.

> 
> Since things changed in the meantime I'll re-open that discussion
> and go from there. Thanks for pointing me in this direction.
> 
> Best regards,
> Robin van der Gracht

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2020-09-30 10:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-29 13:02 robin
2020-09-30  7:39 ` Sascha Hauer
2020-09-30  8:09   ` Enrico Jörns
2020-09-30  9:19     ` robin
2020-09-30 10:50       ` Robert Karszniewicz [this message]
2020-09-30 11:26       ` robin
2020-09-30 11:48         ` Enrico Jörns
2020-09-30 13:18           ` robin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=05d1fc13-9491-bf89-9aec-ecb0c9e051ec@phytec.de \
    --to=r.karszniewicz@phytec.de \
    --cc=barebox@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox