All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Ed Bartosh <ed.bartosh@linux.intel.com>
Cc: Otavio Salvador <otavio.salvador@ossystems.com.br>,
	Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/2] wic: When using --use-uuid make sure that we update the fstab with PARTUUID
Date: Tue, 7 Nov 2017 09:54:57 -0500	[thread overview]
Message-ID: <20171107145457.GJ32663@bill-the-cat> (raw)
In-Reply-To: <20171107081135.sqfjuwqw22tz46xw@linux.intel.com>

[-- Attachment #1: Type: text/plain, Size: 4368 bytes --]

On Tue, Nov 07, 2017 at 10:11:35AM +0200, Ed Bartosh wrote:
> On Mon, Nov 06, 2017 at 07:44:23AM -0500, Tom Rini wrote:
> > On Mon, Nov 06, 2017 at 09:36:20AM -0200, Otavio Salvador wrote:
> > > On Mon, Nov 6, 2017 at 8:08 AM, Ed Bartosh <ed.bartosh@linux.intel.com> wrote:
> > > > On Fri, Nov 03, 2017 at 08:51:50AM -0400, Tom Rini wrote:
> > > >> On Fri, Oct 20, 2017 at 09:15:05AM -0400, Tom Rini wrote:
> > > >> > On Tue, Oct 10, 2017 at 05:01:49PM -0400, Tom Rini wrote:
> > > >> > > On Thu, Sep 21, 2017 at 01:46:16PM -0400, Tom Rini wrote:
> > > >> > > > When we have been told to use the UUID we should also update the fstab
> > > >> > > > to make use of PARTUUID instead of hard-coding the device in question.
> > > >> > > > This will make the resulting image much more portable.
> > > >> > > >
> > > >> > > > Signed-off-by: Tom Rini <trini@konsulko.com>
> > > >> > > > ---
> > > >> > > >  scripts/lib/wic/plugins/imager/direct.py | 9 ++++++---
> > > >> > > >  1 file changed, 6 insertions(+), 3 deletions(-)
> > > >> > >
> > > >> > > Where we did we end up with this?  Ed pointed out that you can tell wic
> > > >> > > to use a specific UUID, so reproducible images are not a problem.  And
> > > >> > > making images that are readily portable is why other distros use
> > > >> > > UUID/LABEL and not device names as much as possible.  I personally enjoy
> > > >> > > being able to put an image on uSD for minnow and have it work :)
> > > >> > > Thanks!
> > > >> >
> > > >> > ping?
> > > >>
> > > >> I was just reminded about the real problems this solves (swap isn't
> > > >> /dev/sda3, boot is being excessively slow), so, ping?
> > > >>
> > > >
> > > > I'm generally ok with the patchset. The only thing I'm thinking of is if busybox mount
> > > > supports PARTUUID syntax in fstab. Can you check this, please?
> > > 
> > > It does.
> > 
> > It doesn't, you need util-linux for a mount that figures these out (or,
> > it did when I wrote the patch set).

Let me correct myself here.  I think what threw me off for a moment
(since I hadn't picked these patches up in a while) was that busybox
mount might handle PARTUUID, but busybox swapon/off doesn't.  But that's
not quite the point, either.

> This practically means that this patch makes it impossible to use
> --use-uuid for busybox-powered images. This is quite a big regression
> from my point of view. We need to make this feature optional then.

How does it change anything at all for that case?  Today there's cases
where you would want to in some cases use PARTUUID, via --use-uuid, but
you can't.  --use-uuid is only valid for the root device as the kernel
handles parsing PARTUUID and our fstab only ever has /dev/root listed,
and all other entires in the table, even when we say --use-uuid, do not
use the UUID but instead use the device name.  Today, we only pass
--use-uuid in, in that case.

What 1/2 allows for is passing in --use-uuid for any partition and
having it be enforced.  There's no canned wks file changes made at all.

What 2/2 does is update the systemd canned wks (where you will not be
able to have busybox swapon/off, you're already forced into util-linux
for utils) to make use of --use-uuid.  I would strongly encourage this
to be applied as well as it makes systemd-based images much more useful
and does not change anything about busybox-only images.  It also allows
for external wks files to use UUIDs when they want to.

> >  That's why 2/2 only updates the
> > systemd canned wks as that _will_ have full mount.  But please note that
> > you can already make a wks file that doesn't work with busybox mount by
> > using the --use-uuid flag for non-root partitions :)
>
> What's the point of using --use-uuid for non-root partitions? I thought
> it only makes sense for root as it triggers update of kernel command
> line.

For the same reasons you want to use PARTUUID for the kernel.  You do
not know that you're going to be "sda".  You might be "vda" or "mmcblk"
or something else.  As a specific example, having "sda3" for swap in the
systemd wks file, but your actual device being something else, means
that you spend 90s during start-up for systemd trying very hard and
being mad that sda3 cannot be swapon'd (it will have swapon'd mmcblk0p3
already, automatically).

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2017-11-07 14:54 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-21 17:46 [PATCH 1/2] wic: When using --use-uuid make sure that we update the fstab with PARTUUID Tom Rini
2017-09-21 17:46 ` [PATCH 2/2] wic: Update canned-wks for systemd to use UUID everywhere Tom Rini
2017-09-21 21:15 ` [PATCH 1/2] wic: When using --use-uuid make sure that we update the fstab with PARTUUID Otavio Salvador
2017-09-21 21:19   ` Tom Rini
2017-09-21 21:20   ` Mark Hatle
2017-09-21 21:21     ` Tom Rini
2017-09-28 12:26       ` Ed Bartosh
2017-10-10 21:01 ` Tom Rini
2017-10-20 13:15   ` Tom Rini
2017-11-03 12:51     ` Tom Rini
2017-11-06 10:08       ` Ed Bartosh
2017-11-06 11:36         ` Otavio Salvador
2017-11-06 12:44           ` Tom Rini
2017-11-06 12:51             ` Otavio Salvador
2017-11-06 13:02               ` Tom Rini
2017-11-07  8:11             ` Ed Bartosh
2017-11-07 14:54               ` Tom Rini [this message]
2017-11-08 11:20                 ` Ed Bartosh
2017-11-08 15:00                   ` Tom Rini
2017-11-08 14:30                     ` Ed Bartosh
2017-11-06 12:44         ` Tom Rini
2017-11-07  8:27           ` Ed Bartosh
2017-11-07 14:55             ` Tom Rini

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=20171107145457.GJ32663@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=ed.bartosh@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=otavio.salvador@ossystems.com.br \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.