Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Normalize device names to find mounted slots #406

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

xyzzy42
Copy link

@xyzzy42 xyzzy42 commented Feb 8, 2019

This way a mounted slot can be found it the path used to mount the
device is not the same as the path in the rauc configuration file.
E.g., the configuration file uses a link like
/dev/disk/by-partlabel/rootfs0 while the kernel's list of mounted
devices uses a name like /dev/mmcblk1p2.

Not being able to detect that the current rootfs is already mounted
causes rauc to try to mount the slot, which will fail.

Fixes #388.

Signed-off-by: Trent Piepho [email protected]

@ejoerns ejoerns added the enhancement Adds new functionality or enhanced handling to RAUC label Feb 9, 2019
@ejoerns
Copy link
Member

ejoerns commented Feb 11, 2019

👍 Thanks for your submission!
@xyzzy42 please let uncrustify run on your code and fix the errors mentioned by Travis so we can have this PR ready for review.

@xyzzy42
Copy link
Author

xyzzy42 commented Feb 11, 2019

There's an issue getting the tests to work.

find_slot_by_device/find_config_slot_by_device are used twice in rauc's code, both times on a running target system where we want to know if a real device corresponds to a slot.

It's also used over a dozen times in the test code. This use doesn't work as intended because the devices, both the one used to look up a slot and the device named in the slot, do not exist. On a target, we couldn't say if they are the same or not. So the lookup fails. In actual use this behavior seems to me like it would be correct. The "is mounted?" and "was booted from?" checks should return false given a device that does not exist.

It looks to me like find_config_slot_by_device() was being used simply as away to get a handle to slot, lacking any other way. It wasn't intended to test the by device lookup code. Maybe a better way would be to create a find_slot_by_name() function and use that in the test code?

@xyzzy42 xyzzy42 force-pushed the slot-mounted-fix branch 2 times, most recently from 03c1130 to 43c1888 Compare February 11, 2019 23:46
src/config_file.c Outdated Show resolved Hide resolved
src/config_file.c Outdated Show resolved Hide resolved
src/config_file.c Outdated Show resolved Hide resolved
src/config_file.c Outdated Show resolved Hide resolved
@xyzzy42 xyzzy42 force-pushed the slot-mounted-fix branch 2 times, most recently from 6a0ae0d to ef102e1 Compare February 25, 2019 19:22
@xyzzy42
Copy link
Author

xyzzy42 commented Feb 25, 2019

Believe I have addressed all comments.

I changed it to do the pathname compare first, device based compare second. The path string compare is much cheaper (no syscalls), and if the paths are the same, then the device comparison must the same too (excluding races!). So this is a faster way to get the same result as device compare first, path compare second.

@xyzzy42
Copy link
Author

xyzzy42 commented Mar 20, 2019

Is there anything else left here? I believe I've made all requested changes.

src/install.c Outdated Show resolved Hide resolved
@ejoerns ejoerns added this to the Release v1.1 milestone Mar 21, 2019
@xyzzy42 xyzzy42 force-pushed the slot-mounted-fix branch 2 times, most recently from adac6a3 to a235dee Compare March 21, 2019 22:27
ejoerns
ejoerns previously approved these changes Mar 26, 2019
@ejoerns ejoerns requested a review from jluebbe April 15, 2019 10:46
@ejoerns ejoerns removed this from the Release v1.1 milestone Jun 4, 2019
@jluebbe jluebbe added this to the Release v1.2 milestone Jun 14, 2019
@ejoerns ejoerns removed this from the Release v1.2 milestone Oct 27, 2019
@obbardc
Copy link
Contributor

obbardc commented Jan 30, 2020

Hi @ejoerns what is the status of this pull request, please?

@ejoerns
Copy link
Member

ejoerns commented Jan 30, 2020

@obbardc the 'funny' thing is that it just hit me, too in a project today. There I still use a different method for solving the same issue and iirc we had a 3rd one somewhere around, too.

We definitely need to face and fix this. This PR should not have been open for so long

@obbardc Did you already test these patches?

@obbardc
Copy link
Contributor

obbardc commented Jan 30, 2020

@obbardc the 'funny' thing is that it just hit me, too in a project today. There I still use a different method for solving the same issue and iirc we had a 3rd one somewhere around, too.
We definitely need to face and fix this. This PR should not have been open for so long
@obbardc Did you already test these patches?

Hardcoded device names is not great, but for now what I have works.
Not tested the patches yet; it's on my list very early next week :-)

@jluebbe
Copy link
Member

jluebbe commented Feb 10, 2020

@ejoerns I've rebased this onto the current master, which had moved some functions to src/slot.c.

@codecov
Copy link

codecov bot commented Feb 10, 2020

Codecov Report

❗ No coverage uploaded for pull request base (master@889602b). Click here to learn what that means.
The diff coverage is 75.67%.

Impacted file tree graph

@@            Coverage Diff            @@
##             master     #406   +/-   ##
=========================================
  Coverage          ?   66.34%           
=========================================
  Files             ?       24           
  Lines             ?     6516           
  Branches          ?        0           
=========================================
  Hits              ?     4323           
  Misses            ?     2193           
  Partials          ?        0           
Impacted Files Coverage Δ
include/config_file.h 100.00% <ø> (ø)
include/slot.h 0.00% <ø> (ø)
src/slot.c 90.37% <68.00%> (ø)
src/install.c 80.43% <91.66%> (ø)
src/config_file.c 82.36% <0.00%> (ø)
src/emmc.c 0.00% <0.00%> (ø)
src/bundle.c 65.13% <0.00%> (ø)
src/network.c 77.21% <0.00%> (ø)
src/manifest.c 80.24% <0.00%> (ø)
... and 18 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 889602b...8b758bf. Read the comment docs.

* etc. which we want to ignore rather than try to follow some
* random symlink named "tmpfs" in the CWD.
*/
if (g_unix_mount_get_device_path(m)[0] != '/')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this is correct for ubifs, which has device names such as ubi0:data.

if (g_stat(devicepath, &st) == -1) {
/* Virtual filesystems like devpts trigger case */
g_debug("Can't stat '%s', assuming unmountable: %s", devicepath, g_strerror(errno));
return NULL;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will break support for UBIFS.


g_return_val_if_fail(slots, NULL);
g_return_val_if_fail(device, NULL);

obj = normalize_mountable_object(device);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How should we handle NULL here?

@jluebbe
Copy link
Member

jluebbe commented Feb 10, 2020

I think we can merge the first two commits as they are, though.

@jluebbe jluebbe requested a review from ejoerns February 10, 2020 11:57
This way a mounted slot can be found if the path used to mount the
device is not the same as the path in the rauc configuration file.
E.g., the configuration file uses a link like
/dev/disk/by-partlabel/rootfs0 while the kernel's list of mounted
devices uses a name like /dev/mmcblk1p2.

This is a fallback after simply comparing the paths, as if the paths
are the same then the devices must the same too.  This avoids changing
behavior in cases there the devices do not exist, for instance if rauc
status before a device is online.

Not being able to detect that the current rootfs is already mounted
causes rauc to try to mount the slot, which will fail.

Fixes rauc#388.

Signed-off-by: Trent Piepho <[email protected]>
@jluebbe
Copy link
Member

jluebbe commented Apr 21, 2020

I've merged the first two commits and rebased this PR.

@jluebbe
Copy link
Member

jluebbe commented Apr 21, 2020

The open comments need to be solved, but the general approach seems fine.

@jluebbe jluebbe added this to the Release v1.4 milestone Apr 21, 2020
@ejoerns ejoerns modified the milestones: Release v1.4, Release v1.5 Jul 16, 2020
@ejoerns ejoerns modified the milestones: Release v1.5, Release 1.6 Jan 4, 2021
@jluebbe
Copy link
Member

jluebbe commented Jan 27, 2022

The open points still need to be resolved and we'd need test-cases to cover the new alternatives. Moving to the next release.

@jluebbe jluebbe modified the milestones: Release v1.6, Release v1.7 Jan 27, 2022
@jluebbe jluebbe modified the milestones: Release v1.7, Release v1.8 Jun 3, 2022
@ejoerns ejoerns modified the milestones: Release v1.8, Release v1.9 Sep 30, 2022
@ejoerns ejoerns modified the milestones: Release v1.9, Unplanned Mar 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Adds new functionality or enhanced handling to RAUC needs rework
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Slot already mounted detection fails with symlinks
4 participants