Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: reconciling uuid's in fstab and crypttab

  1. #1

    Default reconciling uuid's in fstab and crypttab

    I am recovering from a system messed up by autoinstallation of updates.


    Specifically, I'm trying to coordinate fstab and inittab to enable me safely to reboot.


    etc/fstab:
    UUID=888cf11a-74bb-4f38-bae6-6b14a4d3a1bb swap swap defaults 0 0
    UUID=558762e9-ffe6-4113-89d8-91e07a5451bd / ext4 acl,user_xattr 0 1
    UUID=b74fd7e9-4485-4f4d-a676-25e74a27d813 /home ext4 data=ordered,acl,user_xattr 0 2
    UUID=D127-A1BA /boot/efi vfat defaults 0 0
    /dev/mapper/cr_sdc5 /p5 ext4 data=ordered,acl,user_xattr 0 2
    UUID=9e89e3ee-f948-4c5c-9b57-ac8361a9da20 /p7 ext4 defaults 0 2
    UUID=e2d02e46-6113-47a9-b6c0-499dd3cdc0c1 /pass ext4 defaults 0 2


    Data partitions mounted on /p5 /p7 and /pass are encrypted, and the latter two
    were manually mounted (viz. cryptsetup ...) during this session.


    etc/crypttab:
    cr_sdc5 UUID=21b342c3-4baf-4872-acc4-0377197a5978
    cr_nvme0n1p3 UUID=0e622986-55a2-48e5-915f-5a1597964c29
    cr_usb-SanDisk_Cruzer_4C530001321103107162-0:0-part1 UUID=fc79fcea-adeb-4a1f-a84e-89365746cd29
    cr_ata-WDC_WD6401AALS-00E3A0_WD-WCATR2835356-part1 UUID=a0b561bb-3349-4abf-aa41-421ca9f8503d
    cr_ata-WDC_WD4005FZBX-00K5WB0_V6GDHSDR-part1 UUID=45154544-9ff8-4f64-8946-ecb5ea834109
    cr_ata-WDC_WD4005FZBX-00K5WB0_V6GDNUUR-part1 UUID=46743ab9-ca1b-4603-b125-cef91c9877d1
    cr_usb-WD_My_Passport_2603_57583531453438415754485A-0:0-part1 UUID=706d3679-fd50-4ee8-a8c9-ac2107db48e7


    Note that uuid's for /p7 and /pass don't match.


    blkid:
    /dev/nvme0n1p1: SEC_TYPE="msdos" UUID="D127-A1BA" TYPE="vfat" PARTUUID="2f391e97-9f1e-4cfb-918d-0bb9a65e1f6c"
    /dev/nvme0n1p2: UUID="558762e9-ffe6-4113-89d8-91e07a5451bd" TYPE="ext4" PARTUUID="c91afe05-034b-4278-9cb9-f42c89c2774d"
    /dev/nvme0n1p3: UUID="0e622986-55a2-48e5-915f-5a1597964c29" TYPE="crypto_LUKS" PARTUUID="8bf99240-8b91-4dbb-adc9-582b43b78c78"
    /dev/sda1: LABEL="SYSTEM" UUID="A68C-BB39" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="fb177685-0882-4f4e-be17-76e05b5fc97d"
    /dev/sda3: UUID="6EFEA499FEA45ADB" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="978c8fec-b0a3-40e8-9d42-01548718dca4"
    /dev/sda4: LABEL="Windows RE tools" UUID="9A348E6D348E4C67" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="51581d09-5d5d-40ae-a6b4-51ed71f87604"
    /dev/sdb1: UUID="b74fd7e9-4485-4f4d-a676-25e74a27d813" TYPE="ext4" PARTUUID="d1136a15-a28c-478f-982f-34856aeb5260"
    /dev/sdc1: LABEL="EFI1" UUID="D828-6756" TYPE="vfat" PARTLABEL="primary" PARTUUID="625463e8-59ff-48c2-93a4-301e70f1cc32"
    /dev/sdc2: UUID="7751e6b6-1b42-4e23-9f9b-9d4b3afefc84" TYPE="swap" PARTLABEL="primary" PARTUUID="1f429b70-ad2c-461f-a2a6-98f4ddf3b370"
    /dev/sdc3: UUID="fdd41dd2-4ae4-47b8-b905-96fd4cbe3ce6" TYPE="ext4" PARTLABEL="primary" PARTUUID="d02d8411-8134-4bb6-ae33-e18477f5cbb0"
    /dev/sdc4: UUID="dd27bdc0-d1b9-4a9d-9731-df61b1d67899" TYPE="ext4" PARTLABEL="primary" PARTUUID="bfea01b6-9787-42a6-a24c-dc4dcf84a91f"
    /dev/sdc5: UUID="21b342c3-4baf-4872-acc4-0377197a5978" TYPE="crypto_LUKS" PARTLABEL="primary" PARTUUID="cd25eb68-beaa-413a-8e2a-bfa7ba7013c6"
    /dev/sdc6: UUID="888cf11a-74bb-4f38-bae6-6b14a4d3a1bb" TYPE="swap" PARTUUID="8ac5d61e-2431-4fff-b9ee-e4b6eea191c4"
    /dev/sdd1: UUID="706d3679-fd50-4ee8-a8c9-ac2107db48e7" TYPE="crypto_LUKS" PARTLABEL="My Passport" PARTUUID="1044a9d6-fa8c-4571-a34d-55d4021f1076"
    /dev/mapper/aaa: UUID="d84bc98f-ca7f-4b72-9390-1533c29339bb" TYPE="ext4"
    /dev/mapper/bbb: UUID="9e89e3ee-f948-4c5c-9b57-ac8361a9da20" TYPE="ext4"
    /dev/mapper/eee: UUID="e2d02e46-6113-47a9-b6c0-499dd3cdc0c1" TYPE="ext4"
    /dev/nvme0n1: PTUUID="99bc34a5-cf81-48f8-ad24-cfde93e0fef8" PTTYPE="gpt"
    /dev/sda2: PARTLABEL="Microsoft reserved partition" PARTUUID="f73ba631-51cf-41a8-989d-7a9f69d5cef5"


    Re uuid's:
    The partition mounted on /pass: blkid and crypttab match, fstab does not.
    The partition mounted on /p7: ditto
    The partition mounted on /p5 (dev/sdc5): ditto.


    So ...


    1. Should I manually edit fstab to conform?
    If so, how can I test a subsequent boot, without booting?
    2. If I boot with the files as they are, what will happen? (I suppose that the unused lines in inittab
    (eg. San Disk Cruzer) will cause a delay, but not harm things.)


    Might be useful, here's df:


    localhost /root# df
    Filesystem 1K-blocks Used Available Use% Mounted on
    devtmpfs 12279600 8 12279592 1% /dev
    tmpfs 12287860 26484 12261376 1% /dev/shm
    tmpfs 12287860 1816 12286044 1% /run
    tmpfs 12287860 0 12287860 0% /sys/fs/cgroup
    /dev/sdc3 41156156 9625668 30465452 25% /
    /dev/nvme0n1p1 511720 5072 506648 1% /boot/efi
    /dev/sdb1 479669932 39316508 415917764 9% /home
    /dev/mapper/aaa 4138625120 912225864 3016098432 24% /p5
    tmpfs 2457572 24 2457548 1% /run/user/1000
    /dev/nvme0n1p2 71724152 13202420 54835332 20% /p3
    /dev/mapper/bbb 406915796 321755916 64419940 84% /p7
    /dev/mapper/eee 3844605944 1284633268 2364607252 36% /pass
    localhost /root# swapon
    NAME TYPE SIZE USED PRIO
    /dev/sdc2 partition 2G 0B -1




    Thanks in advance, jim

  2. #2
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    12,608
    Blog Entries
    3

    Default Re: reconciling uuid's in fstab and crypttab

    It is complicated. I'm not quite sure whether I have enough information to tell you what to do.

    Let me illustrate from my current desktop:
    Code:
    # blkid /dev/sdc3
    /dev/sdc3: UUID="2fea3dff-1cfc-4da6-a7af-d49a173b7528" TYPE="crypto_LUKS" PARTLABEL="Linux filesystem" PARTUUID="50d3ae5c-485f-4044-b8a1-caf578181cfe"
    
    # grep shared /etc/crypttab
    cr_shared UUID=2fea3dff-1cfc-4da6-a7af-d49a173b7528     none    none
    
    # grep shared /etc/fstab
    UUID=745aa422-3796-4e13-8dbf-ccc085ef57d5  /shared    ext4  data=ordered,acl,user_xattr  0  2
    As I hope you can see, the UUID information from "blkid" and "cryptab" match. But the information from "fstab" is different. And everything is working here.

    What's happening is this: The partition (in this case "/dev/sdc3" is using LUKS encryption. So there's a LUKS header and there's UUID from the LUKS header. That's what "blkid" sees. And that's what goes in "crypttab" to identify the partition for "cryptsetup" (or whatever "systemd" script manages that).

    Following that LUKS header, there is encrypted space, which becomes a virtual drive (or mapped drive) after "cryptsetup" has opened it. The device file for that is, in this case, "/dev/mapper/cr_shared". And that virtual or mapped drive is formatted as "ext4", so that gets its own UUID separate from the one in "crypttab". And "fstab" uses that UUID for the device file.

    I can separately check that UUID with:
    Code:
    # blkid /dev/mapper/cr_shared
    /dev/mapper/cr_shared: LABEL="homebase" UUID="745aa422-3796-4e13-8dbf-ccc085ef57d5" TYPE="ext4"
    and that matches what is in "fstab".

    It's a bit hard for me to see what is going on from your output, because I don't know all of the mappings being used.

    I hope this explanation helps.
    openSUSE Leap 15.1; KDE Plasma 5;
    testing Leap 15.2Alpha

  3. #3
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    25,124

    Default Re: reconciling uuid's in fstab and crypttab

    FWIIW (I do not use encryption), it might be enlightening to look at
    Code:
    /dev/disk/by-uuid/
    Because there you can see which UUIDs are linked to which device file. And the device file is in the end the thing we "know of".

    Alll the UUID, etc. identifications might be important for a system to see what is what, but it is not easyer for human beings.
    Henk van Velden

  4. #4

    Default Re: reconciling uuid's in fstab and crypttab

    [QUOTE=0jbennett;2902127]I am recovering from a system messed up by autoinstallation of updates.


    Specifically, I'm trying to coordinate fstab and inittab to enable me safely to reboot.

    Aha! Thanks, nrickert. I think I understand (better) now. At worst, rebooting should fail for sdc5 -> mount /p5. We'll
    see if I'm asked for just one passkey.

    And thanks hcvv: /dev/disk/by-uuid/ gives nicer output than blkid.

    jim

  5. #5
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    12,608
    Blog Entries
    3

    Default Re: reconciling uuid's in fstab and crypttab

    Quote Originally Posted by 0jbennett View Post
    I think I understand (better) now.
    I'm glad to hear that.

    Here's another way of describing the situation that might easier to think about:

    There's a UUID on the outside (outside the encryption), and there's another UUID on the inside.

    The parts of the system that manage the crypto (such as "/etc/crypttab") need to use the outside UUID. And the parts of the system that deal with the real unencrypted data (such as "/etc/fstab") need to use the inside UUID.
    openSUSE Leap 15.1; KDE Plasma 5;
    testing Leap 15.2Alpha

  6. #6

    Default Re: reconciling uuid's in fstab and crypttab -- no joy thus far

    Aha! Look at blkid -f: it seems to offer uuid's for both raw disk andencrypted (luks)l disks:


    localhost /p15# lsblk -f
    NAME FSTYPE LABEL UUID MOUNTPOINT
    sda
    ├─sda1 vfat SYSTEM A68C-BB39
    ├─sda2
    ├─sda3 ntfs 6EFEA499FEA45ADB
    └─sda4 ntfs Windows RE tools 9A348E6D348E4C67
    sdb
    └─sdb1 ext4 b74fd7e9-4485-4f4d-a676-25e74a27d813 /home
    sdc
    ├─sdc1 vfat EFI1 D828-6756
    ├─sdc2 swap 7751e6b6-1b42-4e23-9f9b-9d4b3afefc84 [SWAP]
    ├─sdc3 ext4 fdd41dd2-4ae4-47b8-b905-96fd4cbe3ce6 /
    ├─sdc4 ext4 dd27bdc0-d1b9-4a9d-9731-df61b1d67899
    ├─sdc5 crypto_LUKS 21b342c3-4baf-4872-acc4-0377197a5978
    │ └─bbb ext4 d84bc98f-ca7f-4b72-9390-1533c29339bb /p5
    └─sdc6 swap 888cf11a-74bb-4f38-bae6-6b14a4d3a1bb
    sdd
    └─sdd1 crypto_LUKS 706d3679-fd50-4ee8-a8c9-ac2107db48e7
    └─ccc ext4 e2d02e46-6113-47a9-b6c0-499dd3cdc0c1 /pass
    sr0
    nvme0n1
    ├─nvme0n1p1 vfat D127-A1BA /boot/efi
    ├─nvme0n1p2 ext4 558762e9-ffe6-4113-89d8-91e07a5451bd /p15
    └─nvme0n1p3 crypto_LUKS 0e622986-55a2-48e5-915f-5a1597964c29
    └─aaa ext4 9e89e3ee-f948-4c5c-9b57-ac8361a9da20 /p7


    So we write fstab and crypttab accordingly:


    localhost /p15# cat /etc/fstab /etc/crypttab
    UUID=7751e6b6-1b42-4e23-9f9b-9d4b3afefc84 swap swap defaults 0 0
    UUID=fdd41dd2-4ae4-47b8-b905-96fd4cbe3ce6 / ext4 acl,user_xattr 1 1
    UUID=D127-A1BA /boot/efi vfat defaults 0 0
    UUID=b74fd7e9-4485-4f4d-a676-25e74a27d813 /home ext4 data=ordered,acl,user_xattr 0 2
    UUID=558762e9-ffe6-4113-89d8-91e07a5451bd /p15 ext4 defaults 0 2
    UUID=9e89e3ee-f948-4c5c-9b57-ac8361a9da20 /p7 ext4 data=ordered,acl,user_xattr 0 2
    UUID=d84bc98f-ca7f-4b72-9390-1533c29339bb /p5 ext4 data=ordered,acl,user_xattr 0 2
    UUID=e2d02e46-6113-47a9-b6c0-499dd3cdc0c1 /pass ext4 data=ordered,acl,user_xattr 0 2




    /dev/sdc5 21b342c3-4baf-4872-acc4-0377197a5978 none luks
    /dev/nvme0n1p3 0e622986-55a2-48e5-915f-5a1597964c29 none luks
    /dev/sdd1 706d3679-fd50-4ee8-a8c9-ac2107db48e7 none luks




    BUT I did the luks mounting manually afters the system was running. So have
    to test this:
    _____________________________________________________________________________
    Reboot: Same error: cannot accomplish Cryptography Setup.
    Removing lines from /etc/fstab gives the same message (above), but system does
    boot into init5 (but long time watching the light bulb on the spash screens to
    level 5).


    journalctl -xb shows that boot is trying to mount /dev/sdd1, even though that
    is not in fstab:
    May 14 12:11:28 localhost kernel: scsi 5:0:0:0: Direct-Access WD My Passport 2603 1014 PQ: 0 ANSI: 6
    May 14 12:11:28 localhost kernel: sd 5:0:0:0: Attached scsi generic sg4 type 0
    May 14 12:11:28 localhost kernel: sd 5:0:0:0: [sdd] Very big device. Trying to use READ CAPACITY(16).
    May 14 12:11:28 localhost kernel: sd 5:0:0:0: [sdd] 7813969920 512-byte logical blocks: (4.00 TB/3.64 TiB)
    May 14 12:11:28 localhost kernel: sd 5:0:0:0: [sdd] 4096-byte physical blocks
    May 14 12:11:28 localhost kernel: sd 5:0:0:0: [sdd] Write Protect is off
    May 14 12:11:28 localhost kernel: sd 5:0:0:0: [sdd] Mode Sense: 47 00 10 08
    May 14 12:11:28 localhost kernel: sd 5:0:0:0: [sdd] No Caching mode page found
    May 14 12:11:28 localhost kernel: sd 5:0:0:0: [sdd] Assuming drive cache: write through
    May 14 12:11:28 localhost kernel: sd 5:0:0:0: [sdd] Very big device. Trying to use READ CAPACITY(16).
    May 14 12:11:28 localhost kernel: sdd: sdd1
    May 14 12:11:28 localhost kernel: sd 5:0:0:0: [sdd] Very big device. Trying to use READ CAPACITY(16).
    May 14 12:11:28 localhost kernel: sd 5:0:0:0: [sdd] Attached SCSI disk


    Then we hit:


    May 14 12:11:28 localhost systemd[1]: /run/systemd/generator/systemd-cryptsetup@-dev-sdd1.service:12: Failed to add required mount "706d3679-fd50-4ee8-a8c9-ac2107db48e7", ignoring: Invalid argument
    May 14 12:11:28 localhost systemd[1]: /run/systemd/generator/systemd-cryptsetup@-dev-sdc5.service:12: Failed to add required mount "21b342c3-4baf-4872-acc4-0377197a5978", ignoring: Invalid argument
    May 14 12:11:28 localhost systemd[1]:
    /run/systemd/generator/systemd-cryptsetup@-dev-nvme0n1p3.service:12: Failed to
    add required mount "0e622986-55a2-48e5-915f-5a1597964c29", ignoring: Invalid argument


    These are taken from /etc/crypttab, but why is that even examined, since the
    "corresponding" logical drives are not found in fstab. Put differently, there
    is no attempt to mount the MS drives, so why these linux drives?

    I don't understand (1) when in the boot process and why (by which module) crypttab is evaluated, or (2) how to set up a working crypttab with the blkid's for encrypted disks.

    Help is appreciated

  7. #7
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    12,608
    Blog Entries
    3

    Default Re: reconciling uuid's in fstab and crypttab -- no joy thus far

    Quote Originally Posted by 0jbennett View Post
    Aha! Look at blkid -f: it seems to offer uuid's for both raw disk andencrypted (luks)l disks:
    Yes, it does.

    Code:
    /dev/sdc5      21b342c3-4baf-4872-acc4-0377197a5978 none luks
    /dev/nvme0n1p3 0e622986-55a2-48e5-915f-5a1597964c29 none luks
    /dev/sdd1      706d3679-fd50-4ee8-a8c9-ac2107db48e7 none luks
    I think that's supposed to be "/etc/crypttab". And it is wrong.

    Let's look at that first entry:
    Code:
    /dev/sdc5      21b342c3-4baf-4872-acc4-0377197a5978 none luks
    It should be something more like:
    Code:
    cr_sdc5  UUID=21b342c3-4baf-4872-acc4-0377197a5978  none luks
    The first column is a symbolic name (will be used as "/dev/mapper/symbolic-name"). It mostly needs to be unique -- that is, to not conflict with anything else.

    The second column needs to identify the device. You cannot just use a raw UUID. You have to either use:
    Code:
    UUID=the-raw-uuid
    or
    Code:
    /dev/disk/by-uuid/the-raw-uuid
    As to when it all happens -- the early part of booting is done from the "initrd", and from the copy of "crypttab" that goes into the "initrd". So you might need to do
    Code:
    mkinitrd
    after changing "crypttab". For the later part of booting, "systemd" reads "crypttab" and sets up disks accordingly. But if the root file system is encrypted, that has to be done via the "initrd" because the root partition isn't readable until the crypto is handled there.
    openSUSE Leap 15.1; KDE Plasma 5;
    testing Leap 15.2Alpha

  8. #8

    Default Re: reconciling uuid's in fstab and crypttab -- no joy thus far

    Thanks -- I corrected crypttab:

    /cr_sdc5 UUID=21b342c3-4baf-4872-acc4-0377197a5978 none luks/cr_nvme0n1p3 UUID=0e622986-55a2-48e5-915f-5a1597964c29 none luks
    /cr_sdd1 UUID=706d3679-fd50-4ee8-a8c9-ac2107db48e7 none luks

    using the same fstab:

    UUID=7751e6b6-1b42-4e23-9f9b-9d4b3afefc84 swap swap defaults 0 0
    UUID=fdd41dd2-4ae4-47b8-b905-96fd4cbe3ce6 / ext4 acl,user_xattr 1 1
    UUID=D127-A1BA /boot/efi vfat defaults 0 0
    UUID=b74fd7e9-4485-4f4d-a676-25e74a27d813 /home ext4 data=ordered,acl,user_xattr 0 2
    UUID=558762e9-ffe6-4113-89d8-91e07a5451bd /p15 ext4 defaults 0 2
    UUID=9e89e3ee-f948-4c5c-9b57-ac8361a9da20 /p7 ext4 data=ordered,acl,user_xattr 0 2
    UUID=d84bc98f-ca7f-4b72-9390-1533c29339bb /p5 ext4 data=ordered,acl,user_xattr 0 2
    UUID=e2d02e46-6113-47a9-b6c0-499dd3cdc0c1 /pass ext4 data=ordered,acl,user_xattr 0 2

    then I did mkinitrd (which complained only about missing fonts).

    Then rebooted. But result was exactly the same, can't set up encryption. E.g.,
    May 14 15:47:44 localhost systemd[1]: systemd-cryptsetup@-cr_sdd1.service: Main process exited, code=dumped, status=6/ABRT
    May 14 15:47:44 localhost systemd[1]: Failed to start Cryptography Setup for /cr_sdd1.
    -- Subject: Unit systemd-cryptsetup@-cr_sdd1.service has failed



    If I edit fstab to remove the final 3 lines (encrypted partitions), and remove crypttab, it boots fine. Then
    of course I can use cryptsetup to manually mount all 3 encrypted volumes. But as the passkeys are long,
    this is arduous.

    I've stared at this long enough not to see the bad syntax somewhere

  9. #9
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    12,608
    Blog Entries
    3

    Default Re: reconciling uuid's in fstab and crypttab -- no joy thus far

    Quote Originally Posted by 0jbennett View Post
    Thanks -- I corrected crypttab:
    Code:
    /cr_sdc5           UUID=21b342c3-4baf-4872-acc4-0377197a5978 none luks
    /cr_nvme0n1p3 UUID=0e622986-55a2-48e5-915f-5a1597964c29 none luks
    /cr_sdd1             UUID=706d3679-fd50-4ee8-a8c9-ac2107db48e7 none luks
    Remove the leading "/". That would make it:
    Code:
    cr_sdc5           UUID=21b342c3-4baf-4872-acc4-0377197a5978 none luks
    cr_nvme0n1p3 UUID=0e622986-55a2-48e5-915f-5a1597964c29 none luks
    cr_sdd1             UUID=706d3679-fd50-4ee8-a8c9-ac2107db48e7 none luks
    And please use CODE tags when quoting computer text. It is easier to read. I added tags to the part of you post that is quoted.
    openSUSE Leap 15.1; KDE Plasma 5;
    testing Leap 15.2Alpha

  10. #10

    Default Re: reconciling uuid's in fstab and crypttab

    Yep, that did it. I should have noticed that
    Code:
    /
    doesn't start a name.
    Thanks much, jim

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •