Announcement

Collapse
No announcement yet.

Systemd 212 Brings Remote Journals, Other New Features

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    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

    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.

    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:

    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.
    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.

    Comment


    • #12
      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.

      Comment


      • #13
        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'.

        Comment


        • #14
          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.

          Comment


          • #15
            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.

            Comment

            Working...
            X