systemd-gpt-auto-generator: Failed to dissect: Input/output error (boot/rpmb context) #5806
Comments
|
I also see from the kernel side but at different timestamp than "Failed to dissect", so it might be a different issue: Using systemd.gpt_auto=0 the problem doesn't appears anymore. So I guess there is a need to blacklist the rpmb partition that isn't relevant for systemd-gpt-auto-generator as this is a secure locked partition. |
|
@kwizart hmm, is there a nice way to detect these kind of partitions? Are they specially marked in some way in sysfs? If possible, I'd prefer to do a better check than just ignore block devices ending in "rpmb". |
|
I only see this to differentiate them, but reading include/linux/genhd.h it's still unclear what it can mean |
|
Well the capability doesn't really report "rpmb" as your output shows... I figure we have to match this by name then. Yuck. I figure we can filter everything starting with "mmcblk" and ending with "rpmb"... |
For now, let's just special-case this in the sources. If more partition types like this show up we should probably find some other solution. Fixes: systemd#5806
|
Fix waiting in #6165. |
|
Hello, i am still getting this issue. I have been getting it for a while i just didn't report it. DistributionArchlinux KernelLinux 4.9.70-1-lts x86_64 Boot MessagePartition Table |
|
Still getting this here too! |
|
what does What does blkid -p report on all the relevant block devices above? My educated guess its that the "boot0", "boot1" pseudo partitions confuse the dissection logic. Not sure how to fix that though. Also, as we lack the relevant hw, I figure we need a patch for this contributed externally... |
what does /usr/lib/systemd/systemd-dissect /dev/mmcblk0 report?What does blkid -p report on all the relevant block devices above? |
|
I seem to have the same error as the original poster. First error appearing in Hardware: what does /usr/lib/systemd/systemd-dissect /dev/mmcblk0 report? What does blkid -p report on all the relevant block devices above? |
|
Same here with some more debug info pointing to a confused line 285 in dissect-image.c: dmesg: With debug info: /dev/: blkid: Distribution: Kernel: Hope that helps |
|
So my educated guess is that we need something like 7be1420 that also handles these "boot" partitions properly. But I don#t understand the semantics of those, what they even are, and can't test that, so somebody knowledgeable needsto investigate this, prep a patch and test it and submit it... |
|
I found https://www.kernel.org/doc/Documentation/mmc/mmc-dev-parts.txt but it doesn't clarify much...
|
/dev/mmcblk0boot0 is a partition found in eMMC This is not relevant for mounting This complement the previous fix as reported in systemd#5806 Signed-off-by: Nicolas Chauvet <kwizart@gmail.com>
|
ok, while trying to test #7982 I found the following clues (writing down mainly for my own memory)
I did a quick strace of systemd-dissect and it seems that the error comes from the first call to read() on the partition. That partition can't be read before eeding it some kind of crypto key. In a way, reporting an IO error is the correct behaviour |
/dev/mmcblk0boot0 is a partition found in eMMC This is not relevant for mounting This complement the previous fix as reported in #5806 Signed-off-by: Nicolas Chauvet <kwizart@gmail.com>
|
I am getting this as well. I am not sure if it is the cause of my random freezes. Journalctl:
/dev/:
lsblk:
Distribution:Arch Linux Linux Kernel:4.15.2-2-ARCH Let me know if you need anything else. |
|
I'm also experiencing the same issue. blkid
journalctl
systemd-dissect /dev/mmcblk0boot*
systemd-dissect /dev/mmcblk0rpmb
distributionManjaro kernel4.14.19-1-MANJARO x86_64 |
|
I can reproduce the issue using I am quite desperate, since this causes NixOS to not be able to update the boot-loader to boot into new cofigurations. Any workaround is welcome. blkidlsblk |
systemctl --version |
|
Can you try "/lib/systemd/systemd-dissect /dev/mmcblk0" I suspect it will also return an I/O error... if it does, can you strace that function ? or even better use gdb to backtrace what system call exactly returns an IO error ? I tried reproducing at home, but didn't manage to... |
[root@sphinx3 ~]# /lib/systemd/systemd-dissect /dev/mmcblk0
Failed to dissect image: Input/output errorI have neither gdb nor strace on the “prod” machine where this error happens, and I cannot install it right now. I will however keep this bug in mind in case an opportunity comes to install one of these tools… |
|
@arximboldi I just helped someone else work around this issue with nixos — changing your hardware-configuration.nix to refer to devices by paths like I also suggested |
|
That is awesome Linus, thanks!
I also tried installin NixOS Unstable from scratch and it seems to work
there: the boot loader is correctly updated on `switch`, even though the
error is still shown on the terminal.
Linus Heckemann <notifications@github.com> writes:
… @arximboldi I just helped someone else work around this issue with nixos — changing your hardware-configuration.nix to refer to devices by paths like `/dev/mmcblk0p1`, `/dev/sda` etc, so the UUID scan doesn't need to run, makes it work.
I also suggested `boot.initrd.postDeviceCommands = "rm /dev/mmcblk0rpmb";` which they didn't try, but I suspect that should also make it work.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#5806 (comment)
--
∿∿∿ https://sinusoid.al
∿∿∿ https://sinusoid.es
|
Filter-out RPMB partitions and boot partitions from MMC devices when comparing the size of the kernel and blkid partition lists. This complement the previous fix to the problem reported in systemd/systemd#5806 https://phabricator.endlessm.com/T21744
Filter-out RPMB partitions and boot partitions from MMC devices when counting partitions enumerated by the kernel. This complement the previous fixes to the problem reported in systemd/systemd#5806 https://phabricator.endlessm.com/T21744
Filter-out RPMB partitions and boot partitions from MMC devices when counting partitions enumerated by the kernel. This complement the previous fixes to the problem reported in systemd#5806
|
I'm still seeing this problem on eMMC systems with systemd v237, and I believe the cause is not filtering-out RPMB and boot partitions when counting the partitions enumerated by the kernel, so the following check fails (with a little extra debug on my system I see The commit on #8609 fixes the problem for me. |
Filter-out RPMB partitions and boot partitions from MMC devices when counting partitions enumerated by the kernel. Also factor out the now duplicated code into a separate function. This complement the previous fixes to the problem reported in systemd#5806
Filter-out RPMB partitions and boot partitions from MMC devices when counting partitions enumerated by the kernel. Also factor out the now duplicated code into a separate function. This complement the previous fixes to the problem reported in systemd/systemd#5806 https://phabricator.endlessm.com/T21744
Filter-out RPMB partitions and boot partitions from MMC devices when counting partitions enumerated by the kernel. Also factor out the now duplicated code into a separate function. This complement the previous fixes to the problem reported in #5806
|
I'm still getting it uname blkid fdisk |
|
The same happens to me with the same configuration as Axeltherabbit. |
|
@tallero this is supposed to be fixed in newer systemd... with what version did you test ? |
|
Hi, I am facing this issue as well. It was fixed in systemd 237? I have that version in Ubuntu 18.04 and still I can see that error:
My hardware is a SBC, Rock64 (Rpi like): https://www.pine64.org/?page_id=7147 |
I confirm, it's been fixed |
Submission type
systemd version the issue has been seen with
systemd-233-3.fc26.armv7hl
Used distribution
Fedora 26 armv7hl
In case of bug report: Unexpected behaviour you saw
systemd-gpt-auto-generator[1765]: Failed to dissect: Input/output error
In case of bug report: Steps to reproduce the problem
I'm using a GPT partition layout on the Toshiba AC100 ARM device. It use a NVIDIA tegra20 SOC and the rootfs is located on a 16G eMMC. In this case the bootloader (upstream uboot) is located in the boot area of the eMMC. (/dev/mmcblk1boot1 and /dev/mmcblk1boot2).
I expect this might be the problem for the failure to dissect the partition layout.
The other candidate for the failure is also the availability of /dev/mmcblk1rpmb
(see https://lwn.net/Articles/682276/ )
LANG=C fdisk -l -o "Device,Start,End,Sectors,Size,Type,Type-UUID,Attrs,Name,UUID"
Disk /dev/mmcblk1: 15 GiB, 16055795712 bytes, 31358976 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: 3A26EA3C-EAB6-4124-853C-E7AADD7948E2
Device Start End Sectors Size Type Type-UUID Attrs Name UUID
/dev/mmcblk1p1 2048 1026047 1024000 500M Linux filesystem 0FC63DAF-8483-4772-8E79-3D69D8477DE4 3E410973-BADE-46FD-9255-3EEB76EEDFD8
/dev/mmcblk1p2 1026048 15706111 14680064 7G Linux filesystem 0FC63DAF-8483-4772-8E79-3D69D8477DE4 A065B4FD-AD31-422B-A61E-6A5214A4A95C
/dev/mmcblk1p3 15706112 16730111 1024000 500M Linux filesystem 0FC63DAF-8483-4772-8E79-3D69D8477DE4 0EB211F3-64CC-4FCE-95D5-92644A8A1DFB
/dev/mmcblk1p4 16730112 31358942 14628831 7G Linux filesystem 0FC63DAF-8483-4772-8E79-3D69D8477DE4 531DBE8A-F643-4C3A-8F08-3C3851069815
Disk /dev/mmcblk1boot1: 2 MiB, 2097152 bytes, 4096 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/mmcblk1boot0: 2 MiB, 2097152 bytes, 4096 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
The text was updated successfully, but these errors were encountered: