All of lore.kernel.org
 help / color / mirror / Atom feed
From: akuster808 <akuster808@gmail.com>
To: openembedded-core@lists.openembedded.org
Subject: Re: [dizzy][PATCH] base-files: Check for /run and /var/lock softlinks on upgrade
Date: Tue, 14 Apr 2015 13:44:13 -0700	[thread overview]
Message-ID: <552D7C1D.3040905@gmail.com> (raw)
In-Reply-To: <BN3PR0501MB109071C50855A918E8395B83BBE60@BN3PR0501MB1090.namprd05.prod.outlook.com>



On 04/14/2015 01:41 PM, Bryan Evenson wrote:
> All,
>
>> -----Original Message-----
>> From: Bryan Evenson
>> Sent: Tuesday, April 14, 2015 11:47 AM
>> To: Bryan Evenson; openembedded-core@lists.openembedded.org
>> Subject: RE: [oe-core][dizzy][PATCH] base-files: Check for /run and /var/lock
>> softlinks on upgrade
>>
>> All,
>>
>>> -----Original Message-----
>>> From: Bryan Evenson [mailto:bevenson@melinkcorp.com]
>>> Sent: Friday, April 10, 2015 12:44 PM
>>> To: openembedded-core@lists.openembedded.org
>>> Cc: Bryan Evenson
>>> Subject: [oe-core][dizzy][PATCH] base-files: Check for /run and
>>> /var/lock softlinks on upgrade
>>>
>>> Commit ea647cd9eebdc3e3121b84074519c4bb305adac9 moved the
>> locations of
>>> /run and /var/lock to match the FHS 3 draft specifications.
>>> However, the install doesn't remove the existing directories.
>>> As a result, upgrading a system may result in /run as a softlink to
>>> /var/run and /var/run as a softlink to /run, creating a circular link.
>>>
>>> During pre and post-install, check for the existence of the old
>>> softlinks, move the old file contents to a temporary location, remove
>>> the softlinks, and restore the directory contents after installation.
>>>
>>
>> I went about this wrong, as I forgot that items may be mounted under /run.
>> I'm working on a different solution in which the preinst step removes the
>> /run and /var/lock softlinks if they exist.  However, I still have odd issues.
>> The first reboot works fine, but then on the next reboot there is a link inside
>> /run for "run -> /var/run" and inside /var there is a link for "run ->
>> /var/volatile/run".  This doesn't match up with the files listed in the base-files
>> recipe.  I can't figure out where these links are coming from.  Has anyone else
>> had issues upgrading base-files?
>
> The root cause seems to be the initscripts package.  The script /etc/volatile.cache is generated by /etc/init.d/populate-volatile.sh.  On upgrade, this file is not removed and may not necessarily be regenerated.  As a result, on the next boot the script /etc/volatile.cache repopulates directories as it remembers them which may not be accurate.  In my case, after the reboot, the /etc/volatile.cache script deleted everything from a USB flash drive attached to my system when it attempted to remove /run.
>
> So to get this portion of the upgrade to work, I had to:
> 1. Remove the softlinks for /run and /var/lock through a preinst script in the base-files recipe
> 2. Remove /etc/volatile.cache as a postint script in the initscripts recipe
>
> Would someone like for me to submit a patch?

sure.

- armin
>
> Thanks,
> Bryan
>
>>
>> Thanks,
>> Bryan
>>
>>> Signed-off-by: Bryan Evenson <bevenson@melinkcorp.com>
>>> ---
>>>   meta/recipes-core/base-files/base-files_3.0.14.bb | 55
>>> +++++++++++++++++++++++
>>>   1 file changed, 55 insertions(+)
>>>
>>> diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb
>>> b/meta/recipes-core/base-files/base-files_3.0.14.bb
>>> index 07f5c54..71cea08 100644
>>> --- a/meta/recipes-core/base-files/base-files_3.0.14.bb
>>> +++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
>>> @@ -66,6 +66,41 @@ hostname = "openembedded"
>>>
>>>   BASEFILESISSUEINSTALL ?= "do_install_basefilesissue"
>>>
>>> +# In previous versions of base-files, /run was a softlink to /var/run
>>> +and the # directory was located in /var/volatlie/run.  Also,
>>> +/var/lock was a softlink # to /var/volatile/lock which is where the
>>> +real directory was located.  Now, # /run and /run/lock are the real
>>> +directories.  If we are upgrading, we may # need to remove the symbolic
>> links first before we create the directories.
>>> +# Otherwise the directory creation will fail and we will have
>>> +circular symbolic # links.
>>> +#
>>> +# If we do need to remove the symbolic links first, we also need to
>>> +preserve # all the contents of the directory so running programs can
>>> +find the files that # are in use in these directories.  Move the
>>> +contents to a temporary
>>> directory
>>> +# during pre-install to protect the contents pkg_preinst_${PN} () {
>>> +    #!/bin/sh -e
>>> +    if [ x"$D" = "x" ]; then
>>> +        if [ -e "/var/volatile/lock" ]; then
>>> +            # Move the contents of /var/volatile/lock to a temporary directory
>>> +            mkdir -p /run_lock_tmp
>>> +            mv /var/volatile/lock/* /run_lock_tmp/
>>> +
>>> +            # Remove the current directory
>>> +            rm -rf /var/volatile/lock
>>> +        fi
>>> +
>>> +        if [ -h "/run" ]; then
>>> +            # Move the contents of /run to a temporary directory
>>> +            mkdir -p /run_tmp
>>> +            mv /run/* /run_tmp/
>>> +
>>> +            # Remove the current directory
>>> +            rm -rf /run
>>> +        fi
>>> +    fi
>>> +}
>>> +
>>>   do_install () {
>>>   	for d in ${dirs755}; do
>>>   		install -m 0755 -d ${D}$d
>>> @@ -79,6 +114,7 @@ do_install () {
>>>   	for d in ${volatiles}; do
>>>   		ln -sf volatile/$d ${D}${localstatedir}/$d
>>>   	done
>>> +
>>>   	ln -snf ../run ${D}${localstatedir}/run
>>>   	ln -snf ../run/lock ${D}${localstatedir}/lock
>>>
>>> @@ -144,6 +180,25 @@ do_install_append_linuxstdbase() {
>>>           done
>>>   }
>>>
>>> +# If we are on the actual hardware, check if we had to move /run and
>>> /run/lock.
>>> +# If so, copy the temporary directory contents to their new locations.
>>> +pkg_postinst_${PN} () {
>>> +    #!/bin/sh -e
>>> +    if [ x"$D" = "x" ]; then
>>> +        if [ -e "/run_tmp" ]; then
>>> +            mv /run_tmp/* /run/
>>> +            rmdir /run_tmp
>>> +        fi
>>> +
>>> +        if [ -e "/run_lock_tmp/" ]; then
>>> +            mv /run_lock_tmp/* /run/lock
>>> +            rmdir /run_lock_tmp
>>> +        fi
>>> +    else
>>> +        exit 1
>>> +    fi
>>> +}
>>> +
>>>   PACKAGES = "${PN}-doc ${PN} ${PN}-dev ${PN}-dbg"
>>>   FILES_${PN} = "/"
>>>   FILES_${PN}-doc = "${docdir} ${datadir}/common-licenses"
>>> --
>>> 2.1.0
>


      reply	other threads:[~2015-04-14 20:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-10 16:44 [dizzy][PATCH] base-files: Check for /run and /var/lock softlinks on upgrade Bryan Evenson
2015-04-14 15:46 ` Bryan Evenson
2015-04-14 20:41   ` Bryan Evenson
2015-04-14 20:44     ` akuster808 [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=552D7C1D.3040905@gmail.com \
    --to=akuster808@gmail.com \
    --cc=openembedded-core@lists.openembedded.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.