From: Dan O'Donovan <dan@emutex.com>
To: Oleksandr Poznyak <oleksandr.poznyak@gmail.com>
Cc: yocto@yoctoproject.org
Subject: Re: rootfs mounted read-only on Live USB (x86-64)
Date: Fri, 3 Jun 2016 15:15:59 +0100 [thread overview]
Message-ID: <5751911F.8010107@emutex.com> (raw)
In-Reply-To: <CAEeWub+31SEF90HY9JC-+7PtGxHZjjz+S1Sm9mS99dDxUFCKCQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2584 bytes --]
On 06/03/2016 10:54 AM, Oleksandr Poznyak wrote:
> Hi,
Hi Oleksandr
> Check if "read-only-rootfs" feature is added to any of these variables either in your local.conf or your image bitbake recipe:
>
> Something like that:
>
> IMAGE_FEATURES = "read-only-rootfs"
>
> EXTRA_IMAGE_FEATURES += "read-only-rootfs"
Thanks for your suggestion. I didn't find "read-only-rootfs" specified in the IMAGE_FEATURES in local.conf or elsewhere. I suspect it might be a different issue because it only affects the live-boot of the .iso image. If I install the .hddimage directly to the storage device instead, then it boots fine and the rootfs is read/write.
[update]
It looks like the problem was indeed the lack of aufs.
I added this in conf/local.conf
DISTRO_FEATURES_append = " aufs"
and this in the kernel recipe
KERNEL_FEATURES_append += "${@bb.utils.contains('DISTRO_FEATURES', 'aufs', ' features/aufs/aufs-enable.scc', '', d)}"
and now the live USB image boots correctly with a read-write filesystem.
Considering that the default images built for a generic x86-64 machine include a live-boot image (.iso) which is effectively broken, I assume the aufs feature (or another solution for the live-boot use case) should really be added by default for those builds as well.
>
> Thanks,
> Oleksandr Poznyak!
>
> On Fri, Jun 3, 2016 at 12:06 PM, Dan O'Donovan <dan@emutex.com <mailto:dan@emutex.com>> wrote:
>
> Hi all
>
> Has anyone else noticed that the root file-system appears to be mounted read-only when booting a Live USB image from Yocto 2.1.
>
> This is on a sato build from the krogoth branch of poky and meta-intel, for a generic x86-64 machine (4.4 kernel).
>
> I'm transferring the resulting .iso image to a usb stick using 'dd', and then picking the 'boot' option at startup.
>
> As well as a bunch of errors about the read-only filesystem (e.g. failing to create files in /var and other locations), the desktop UI fails to load.
>
> This worked fine with Yocto 2.0.
>
> I have a hunch that it might be caused by a lack of aufs support. Is it possible that aufs patches were omitted from the x86 kernels in Yocto 2.1?
>
> Thanks,
> -Dan
>
> P.S. It works fine if I just install it directly, or if I use the .hddimg, instead of trying to boot the live image from the .iso.
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
> https://lists.yoctoproject.org/listinfo/yocto
>
>
[-- Attachment #2: Type: text/html, Size: 4961 bytes --]
next prev parent reply other threads:[~2016-06-03 14:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-03 9:06 rootfs mounted read-only on Live USB (x86-64) Dan O'Donovan
2016-06-03 9:54 ` Oleksandr Poznyak
2016-06-03 14:15 ` Dan O'Donovan [this message]
2016-06-03 15:33 ` Bruce Ashfield
2016-06-03 15:34 ` Bruce Ashfield
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=5751911F.8010107@emutex.com \
--to=dan@emutex.com \
--cc=oleksandr.poznyak@gmail.com \
--cc=yocto@yoctoproject.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 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.