Page 2 of 2 FirstFirst 12
Results 11 to 15 of 15

Thread: Systemd 212 Brings Remote Journals, Other New Features

  1. #11
    Join Date
    Dec 2012
    Posts
    459

    Default

    Quote Originally Posted by haplo602 View Post
    One very simple reason: SINGLE POINT OF FAILURE !!!!

    The classic Unix approach eliminates SPOFs and gives you a wide choice of tools to use. Systemd is the exact opposite (I'd call it the Microsoft way of doing things).
    +1

    Quote Originally Posted by haplo602 View Post
    Anyway, personal experience: I installed systemd on my Gentoo box to get back consolekit functionality. I tried to use it as init system, but once it mounted my LVM devices as /dev/dm-X it was quickly reduced to just udev/logind provider.
    SystemD is not a first class init in Gentoo.

    Quote Originally Posted by haplo602 View Post
    I don't care who is responsible for the mess (systemd devs or gentoo maintainers). Such idiocies have no place in a modern system (why the hell does LVM have a vg/lv naming option if nto for clarity ? /dev/dm-X is not clear at all).
    I have 13-dm-disk.rules in udev's rules.d which does something like this:

    Code:
    [gebruiker@delta rules.d]$ find /dev/disk
    /dev/disk
    /dev/disk/by-path
    /dev/disk/by-path/pci-0000:00:10.3-usb-0:5:1.0-scsi-0:0:0:3
    /dev/disk/by-path/pci-0000:00:10.3-usb-0:5:1.0-scsi-0:0:0:2
    /dev/disk/by-path/pci-0000:00:10.3-usb-0:5:1.0-scsi-0:0:0:1
    /dev/disk/by-path/pci-0000:00:10.3-usb-0:5:1.0-scsi-0:0:0:0
    /dev/disk/by-uuid
    /dev/disk/by-uuid/9f405c34-354a-4be4-8075-ff23bd04915e
    /dev/disk/by-uuid/ac570999-667e-498c-93d1-410bf87f09be
    /dev/disk/by-uuid/d2b6004b-3195-4923-a803-67cac80e7d91
    /dev/disk/by-uuid/04bca290-b4c2-4af6-bbf0-3738a066f501
    /dev/disk/by-uuid/ec88f772-09cc-4fd7-8220-51e8fcab8152
    /dev/disk/by-uuid/bc20c5fa-8463-487f-ba81-aefa0a97f06d
    /dev/disk/by-uuid/6cc7990a-8185-441a-b90d-c73a25f7d4cc
    /dev/disk/by-uuid/a681d6e9-ba0b-473f-80df-5f355f155272
    /dev/disk/by-id
    /dev/disk/by-id/usb-_USB_2.0_Reader_1936120000D9-0:3
    /dev/disk/by-id/usb-_USB_2.0_Reader_1936120000D9-0:2
    /dev/disk/by-id/usb-_USB_2.0_Reader_1936120000D9-0:1
    /dev/disk/by-id/usb-_USB_2.0_Reader_1936120000D9-0:0
    /dev/disk/by-id/dm-uuid-LVM-Wy8pjpX6RWUI2GdTbSrc2UIMtPkUAYDkIWLSk8BehahDfcoSTbtXW8eNIZGtGq1o
    /dev/disk/by-id/dm-name-main-swap
    /dev/disk/by-id/dm-uuid-LVM-Wy8pjpX6RWUI2GdTbSrc2UIMtPkUAYDkWUCHMRwC2pV88D50ntqFodI6nePy8ba4
    /dev/disk/by-id/dm-name-main-home
    /dev/disk/by-id/dm-uuid-LVM-Wy8pjpX6RWUI2GdTbSrc2UIMtPkUAYDkk53pzq4IRrxYD114GQOBJeTvBxEVw3br
    /dev/disk/by-id/dm-name-main-linux--src
    /dev/disk/by-id/dm-uuid-LVM-Wy8pjpX6RWUI2GdTbSrc2UIMtPkUAYDkApMkELF1wFMhFyd2Irr1u916JXgjMhVM
    /dev/disk/by-id/dm-name-main-opt
    /dev/disk/by-id/dm-uuid-LVM-Wy8pjpX6RWUI2GdTbSrc2UIMtPkUAYDktIgtT0Fhft2tYl7cJmKBO5Xm6rV0efdr
    /dev/disk/by-id/dm-name-main-etc
    /dev/disk/by-id/dm-uuid-LVM-Wy8pjpX6RWUI2GdTbSrc2UIMtPkUAYDkaUDjXh317t3AVfLZxkmktuVw8YZYXPiZ
    /dev/disk/by-id/dm-name-main-usr
    /dev/disk/by-id/dm-uuid-LVM-Wy8pjpX6RWUI2GdTbSrc2UIMtPkUAYDks1awxSE20rxvSNNv8RQZY1NWLBFwfNLa
    /dev/disk/by-id/dm-name-main-boot
    /dev/disk/by-id/dm-uuid-LVM-Wy8pjpX6RWUI2GdTbSrc2UIMtPkUAYDkSrDfoUpX3EyLQJHQuI1GnlVc0C45Etjw
    /dev/disk/by-id/dm-name-main-var
    /dev/disk/by-id/ata-WDC_WD800BB-00DKA0_WD-WCAHL2411610-part1
    /dev/disk/by-id/ata-WDC_WD800BB-00DKA0_WD-WCAHL2411610-part3
    /dev/disk/by-id/ata-WDC_WD800BB-00DKA0_WD-WCAHL2411610-part2
    /dev/disk/by-id/ata-WDC_WD800BB-00DKA0_WD-WCAHL2411610
    /dev/disk/by-id/ata-PHILIPS_CDRWDVD3210_AH510308012818
    And it's ./10-dm.rules which creates the /dev/dm-* nodes:

    Quote Originally Posted by 10-dm.rules
    # Udev rules for device-mapper devices.
    #
    # These rules create a DM control node in /dev/mapper directory.
    # The rules also create nodes named dm-x (x is a number) in /dev
    # directory and symlinks to these nodes with names given by
    # the actual DM names.
    Quote Originally Posted by terminal
    [gebruiker@delta rules.d]$ pacman -Q -o ./13-dm-disk.rules
    ./13-dm-disk.rules is owned by device-mapper 2.02.105-2
    [gebruiker@delta rules.d]$ pacman -Q -o ./10-dm.rules
    ./10-dm.rules is owned by device-mapper 2.02.105-2
    In Arch, these are part of the device-mapper package. In Gentoo, these are part of the lvm2 ebuild. Inside the lvm2 tarball they are located under the udev directory.

    So, it's not a systemd thing. You can probably get rid of this behaviour by emerging lvm2 without the udev useflag.

  2. #12
    Join Date
    Aug 2009
    Posts
    94

    Default

    Quote Originally Posted by Rexilion View Post
    +1

    So, it's not a systemd thing. You can probably get rid of this behaviour by emerging lvm2 without the udev useflag.
    Thanks for the tip, but it is a systemd thing. When I boot the exact same system with OpenRC, I get proper LVM names. I simply change the int/real_init parameter between systemd and OpenRC and the device names changed. Nothing else changed.

    Also once I mounted something manually (i.e. mount /boot) after login, the device name was correct. So the service that mounts fstab at startup does some extra processing bullshit that should not be there.

  3. #13
    Join Date
    Dec 2012
    Posts
    459

    Default

    Quote Originally Posted by haplo602 View Post
    Thanks for the tip, but it is a systemd thing. When I boot the exact same system with OpenRC, I get proper LVM names. I simply change the int/real_init parameter between systemd and OpenRC and the device names changed. Nothing else changed.

    Also once I mounted something manually (i.e. mount /boot) after login, the device name was correct. So the service that mounts fstab at startup does some extra processing bullshit that should not be there.
    My guess would be that the seperate udev for openrc is using different rulesets than the systemd installation. But that would be a guess, I'm not sure.

    It's odd though, you can configure this with the files in rules.d. Your observations are contradicting my statement, but are indeed 'remarkable'.

  4. #14
    Join Date
    Sep 2009
    Posts
    22

    Default

    Quote Originally Posted by haplo602 View Post
    Anyway, personal experience: I installed systemd on my Gentoo box to get back consolekit functionality. I tried to use it as init system, but once it mounted my LVM devices as /dev/dm-X it was quickly reduced to just udev/logind provider. I don't care who is responsible for the mess (systemd devs or gentoo maintainers). Such idiocies have no place in a modern system (why the hell does LVM have a vg/lv naming option if nto for clarity ? /dev/dm-X is not clear at all).
    The /dev/dm-X is for consistant device nameing. You should still have a /dev/vgX/lvX that are soft link pointing back to dev/dm-X. Similar to how hard drives are mapped to /dev/sdX and all the items under /dev/disk are soft links back to the /dev/sdX nodes. If that is not happening, then I suspect the udev rules are incorrect, or something isn't installed correctly.

  5. #15
    Join Date
    Dec 2012
    Posts
    459

    Default

    Quote Originally Posted by FishB8 View Post
    The /dev/dm-X is for consistant device nameing. You should still have a /dev/vgX/lvX that are soft link pointing back to dev/dm-X. Similar to how hard drives are mapped to /dev/sdX and all the items under /dev/disk are soft links back to the /dev/sdX nodes. If that is not happening, then I suspect the udev rules are incorrect, or something isn't installed correctly.
    Yeah, I think it has something to do with systemD not being a first class init in Gentoo.

Posting Permissions

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