Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Ed Bartosh <ed.bartosh@linux.intel.com>
To: Tom Rini <trini@konsulko.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCHv2 0/4] wic: Further enhance UUID / fstab support
Date: Wed, 22 Nov 2017 10:39:06 +0200	[thread overview]
Message-ID: <20171122083906.gph76do4d7meusfe@linux.intel.com> (raw)
In-Reply-To: <1510934900-22044-1-git-send-email-trini@konsulko.com>

Hi Tom,

Thank you for the great patchset!

+1

On Fri, Nov 17, 2017 at 11:08:16AM -0500, Tom Rini wrote:
> Hey all,
> 
> So, per Ed's feedback on my first series, I went and spent some time
> trying to figure out how to have wic know what the UUID would be when
> updating the fstab.  It turns out the easiest answer here is to have WIC
> make the UUID.  Per Otavio's concern last time, I also make sure that
> the filesystem UUID can be passed in, for reproducibility.  One thing to
> keep in mind here is that FAT filesystem UUIDs are a bit funny to deal
> with as mkfs.vfat / mkdosfs / etc want to be given a 32bit hexadecimal
> value.  But when we talk mount, it must be split and it must be in
> uppercase.  To make the rest of the code easier I'm encoding the '0x'
> portion into part.fsuuid rather than doing "-i 0x%s" in a bunch of
> places.
> 
> While preparing all of this, I found a few minor things such as we did
> not test for squashfs and --use-uuid (not supported) and an incorrect
> comment around the btrfs support.
> 
> Since v1, I've added a testcase into wic.Wic.test_qemu for a UUID mount
> and the UUID that we've given. I think this is cleaner than adding a
> python function to make a wks file just for this task.
> 
> --
> Tom

-- 
--
Regards,
Ed


      parent reply	other threads:[~2017-11-22  9:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-17 16:08 [PATCHv2 0/4] wic: Further enhance UUID / fstab support Tom Rini
2017-11-17 16:08 ` [PATCHv2 1/4] wic: kparser.py: Check for SquashFS and use-uuid Tom Rini
2017-11-17 16:08 ` [PATCHv2 2/4] wic: partition.py: Update comments slightly Tom Rini
2017-11-17 16:08 ` [PATCHv2 3/4] wic: Introduce --fsuuid and have --use-uuid make use of UUID too Tom Rini
2017-11-17 16:08 ` [PATCHv2 4/4] meta-selftest: wic: Add test for --use-uuid / --fsuuid Tom Rini
2017-11-24 15:28   ` Burton, Ross
2017-11-24 15:36     ` Tom Rini
2017-11-28 15:55       ` Tom Rini
2017-12-13 14:40         ` Burton, Ross
2017-12-14  1:22           ` Tom Rini
2017-12-14  2:45           ` Tom Rini
2017-12-14  3:15             ` Tom Rini
2018-01-23 22:05               ` Khem Raj
2017-11-22  8:39 ` Ed Bartosh [this message]

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=20171122083906.gph76do4d7meusfe@linux.intel.com \
    --to=ed.bartosh@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=trini@konsulko.com \
    /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