1

On Archlinux I could just setup a device mapper to the main hard drive /dev/sda. On Fedora it won't let me and says "device-mapper: reload ioctl on ... failed, device or resource busy". journalctl gives this - device-mapper: table: xx:xx: linear: Device lookup failed (-EBUSY) and then device-mapper: ioctl: error adding target to table I looked and I am seeing nothing is using /dev/sda. I tried lsof and fuser. How do I find what's causing this error?

The goal state is simple: to have /dev/sda parent hard drive available for ad hoc ephemeral device mappings (that may even overlap existing partition layout and exist on top). This works when the entire /dev/sda is not partitioned at all and is just directly device mapped to some encrypted partitions (plain dm-crypt root fs with detached /boot).

3
  • lsof and fuser will only report about userspace uses of a device, not about in-kernel uses. Check dmsetup ls --tree -o blkdevname to see if sda is already used by another mapping.
    – telcoM
    Jan 26, 2023 at 16:12
  • That shows that only /dev/sda1 is used by luks for the root fs. No /dev/sda is used by another mapping.
    – user145453
    Jan 27, 2023 at 6:54
  • journalctl gives this - "device-mapper: table: xx:xx: linear: Device lookup failed (-EBUSY)" and then "device-mapper: ioctl: error adding target to table"
    – user145453
    Jan 27, 2023 at 7:04

1 Answer 1

1

Based on your comments:

Partition sda1 is part of disk sda, so if your LUKS-encrypted root filesystem is on sda1, you won't be able to map the whole of sda because LUKS has already claimed exclusive access to a specific part of it (i.e. the partition sda1). You could map other unmounted partitions, though.

You seem to be trying to add a linear mapping. That might mean you could be trying to construct a JBOD out of sda and some other disk. In order not to invalidate the partitions on sda, it would have to be the first device in the linear mapping, and you would have to establish the mapping in initramfs before the root filesystem's LUKS encryption layer is activated. You might have to use kpartx or similar to create individual mappings on top of the JBOD for partitions existing on it, so that LUKS would have a chance to find the partition containing your encrypted root filesystem. Is this what you are trying to do?

(Instead of using comments to provide more information when asked, you should edit your question to add that information in. Comments will eventually expire, and if essential information to understand the situation is only in comments, the question and any answers it has received will become useless to others in the future.)

You might want to describe your desired goal state: how would you want your device mappings (including your root filesystem) be laid out when you're done? Then we could provide answers on how to best make that happen in Fedora.

Because the installation process of Arch inherently includes manual operations within chroot, it may well be more flexible to accept configurations that would be considered unusual for Fedora.

6
  • Thanks! I did not use LUKS on Arch so it may be the culprit. But what is it about LUKS that makes it claim the entire parent hard drive /dev/sda when it's only dealing with one partition /dev/sda1?? And as a sequitur, will detaching LUKS header alleviate this condition?
    – user145453
    Jan 27, 2023 at 16:51
  • Your second mapping is trying to claim the entire drive but cannot do that because part of it is already mapped by a crypt-type mapping by LUKS. As far as I know, device-mapper does not allow two mappings to have overlapping source sides like that. Detaching the header won't have any effect on that: the end result is still a crypt mapping over sda1, and only cryptsetup close or equivalent dmsetup remove would get rid of it... and to do that, you would have to unmount your root filesystem first.
    – telcoM
    Jan 27, 2023 at 18:02
  • The kind of linear mapping of the entire sda you're planning would, if allowed, enable you to easily corrupt your root filesystem by mistake. Because of the encryption, you wouldn't be able to read anything useful from the area occupied by sda1 either. But if you don't plan to do any writing, try making your linear mapping explicitly read-only when creating it: while conflicting writeable mappings are not allowed, read-only mappings might be.
    – telcoM
    Jan 27, 2023 at 18:08
  • It's weird you write this because I WAS able to do linear mapping of nonoverlapping small parts of /dev/sda when my root filesystem was also linearly mapped to /dev/sda. Isn't that the whole point of dmsetup linear? So it must be the LUKS issue, and it feels like something is wrong if LUKS would somehow prevent linear device mapping to non-used parts of /dev/sda?
    – user145453
    Jan 28, 2023 at 11:14
  • Hmm. Perhaps it could be an interaction between partitioning and the device mapper... or perhaps you've miscalculated something and it's actually stopping you from making a bad mistake? Would you like to add to your question the fdisk -l output of your partitioning, the dmsetup table of your existing mappings, and the exact description of the mapping you're trying to add but failing, please? Perhaps having more pairs of eyes seeing the actual hard data might resolve the mystery.
    – telcoM
    Jan 28, 2023 at 16:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .