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

storage: Exclude eMMC "boot" non-partitions from multipath logic #20329

Merged

Conversation

mvollmer
Copy link
Member

@mvollmer mvollmer commented Apr 17, 2024

eMMC devices can have "boot" sub-devices which should be excluded from multipath considerations, just like partitions.

Fixes #20250

@mvollmer mvollmer force-pushed the storage-recognize-mmcblk-boot-devices branch from 8a14c96 to 3cf24bc Compare April 17, 2024 06:50
@mvollmer
Copy link
Member Author

I have no idea how to test this... We might have to be content with not breaking anything that we can test, and getting feedback from the reporter of #20250.

@martinpitt
Copy link
Member

Agreed - that's why we have packit COPRs, for easy user testing 😁

@jelly
Copy link
Member

jelly commented Apr 23, 2024

I can reproduce this on my Surface:

It has an interesting bug with the empty card
Screenshot from 2024-04-23 15-28-25

With the patch:

No changes, let me re-check if I patched it correctly.

FYI:

[jelle@surfacego Screenshots]$ sudo fdisk -l
Disk /dev/mmcblk1: 58.24 GiB, 62537072640 bytes, 122142720 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 7ABE7759-96F6-4B48-A2B6-32192D562E22

Device           Start       End   Sectors  Size Type
/dev/mmcblk1p1    2048   1026047   1024000  500M EFI System
/dev/mmcblk1p2 1026048 122140671 121114624 57.8G Linux filesystem


Disk /dev/mmcblk1boot0: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mmcblk1boot1: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

// to the main Drive. We identify them by their name, just like
// UDisks2.

if (utils.decode_filename(block.Device).match(/^mmcblk[0-9]boot[0-9]$/))
Copy link
Member

Choose a reason for hiding this comment

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

This won't work, the devices have a /dev/ prefix

Copy link
Member

Choose a reason for hiding this comment

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

-    if (utils.decode_filename(block.Device).match(/^mmcblk[0-9]boot[0-9]$/))
+    if (utils.decode_filename(block.Device).match(/\/dev\/mmcblk[0-9]boot[0-9]$/))

This works.

Copy link
Member

Choose a reason for hiding this comment

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

Also our add_disk code does this:

 559   │         if not serial:
 560   │             serial = f"DISK{index}"
 561   │         dev = 'sd' + string.ascii_lowercase[index]
 562   │         extra = "<boot order='1'/>" if boot_disk else ""
 563   │         disk_desc = TEST_DISK_XML % {
 564   │             'file': image,
 565   │             'serial': serial,
 566   │             'unit': index,
 567   │             'dev': dev,
 568   │             'type': image_type,
 569   │             'extra': extra,
 570   │         }

So the device name seems user controlled, we could add a test for that? Or maybe via the ram_disk route?

Copy link
Member Author

Choose a reason for hiding this comment

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

So the device name seems user controlled

Not really... I think the dev = 'sd' + index is just a good guess at what the device will be called in the guest. It doesn't control it.

Copy link
Member Author

@mvollmer mvollmer Apr 24, 2024

Choose a reason for hiding this comment

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

This won't work, the devices have a /dev/ prefix

Ouch, that's why we test, I guess. :-) Thanks!

@jelly jelly added the release-blocker Targetted for next release label Apr 24, 2024
eMMC devices can have "boot" sub-devices which should be excluded from
multipath considerations, just like partitions.

Fixes cockpit-project#20250
@mvollmer mvollmer force-pushed the storage-recognize-mmcblk-boot-devices branch from 3cf24bc to a3f1f0a Compare April 24, 2024 07:31
@mvollmer mvollmer requested a review from jelly April 24, 2024 07:32
@mvollmer
Copy link
Member Author

@jelly, can you please test again?

Copy link
Member

@jelly jelly left a comment

Choose a reason for hiding this comment

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

Works!

// UDisks2.

if (utils.decode_filename(block.Device).match(/\/dev\/mmcblk[0-9]boot[0-9]$/))
return false;
Copy link
Contributor

Choose a reason for hiding this comment

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

This added line is not executed by any test.

@jelly jelly merged commit bd8e987 into cockpit-project:main Apr 24, 2024
82 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release-blocker Targetted for next release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cannot control mmc device
4 participants