Latest source build does not install init.d nor systemd scripts

[Tim Jones]

Hi Folks,

I've just tried updating a system that we've moved from RHEL4 to CentOS 7 and have discovered that neither the systemd nor init.d scripts are getting installed in the "make install" passes from the current source.

I am working with the sources from github that are as recent as this morning.

All of the proper tools and modules are being built and install (and work), but I'm not sure which scripts I should be adding where.

Pointers appreciated.

Tim

[Tim Jones]

Found the notes in the docs folder concerning the removal of the init.d scripts.  Not a fan of systemd, but it will work.

Has anyone developed a full step guide for implementation?  I've enabled the mhvtl.target and systemctl says that it's active and enabled, but the kernel module isn't loading and I have to manually launch the vtltape and vtllibrary user daemons.

[Mark Harvey]

Thanks for the bug report.

If you build the RPM - and install from there, it works.
$ make tar
$ mv ../mhvtl<tar-file-name-built> mhvtl-2019.-3-28.tgz (spec file is looking for this filename)
$ rpmbuild -tb mhvtl-2019-03-28.tgz

I'll deploy a fresh OS and see what/why the build from src won't work..

I'm currently assuming my setup worked during testing as the leftover from an RPM install/build..

[Tim Jones]

I have a number of other patches in the works.

IBM's dropped the TDx in favor of the more representative LTOx.

The LTO-8 drive won't access LTO-6 media, just 7 and 8 but both are RW.

HP is now officially HPE.

Overland now owns the Tandberg Data and Exabyte names.

Overland, Spectra and a few others are no longer masking the BDT INQUIRY on libraries with their own vendor IDs.

To solve the init stuff, I simply added the init lines to my rc.local:

modprobe mhvtl
vtllibrary -q 10
vtltape -q 11

I've set the device to mimic a 1x8 and I'm working on a group of presets to mimic the major current libraries from HPE, Overland, IBM, Generic BDT, and a few others.

Do you have guidance beyond duplicating the INQUIRY response information when generating new library and tape drive pm.c files?

[Mark Harvey]

Tim Jones wrote

I have a number of other patches in the works.

Cool - love to see anything. I've been rather distracted for last 12+ months and haven't found much spare time to do much.

Tim Jones wrote

Do you have guidance beyond duplicating the INQUIRY response information when generating new library and tape drive pm.c files?

Setup starting address mappings for libraries:
Most libraries use the same mode pages - but the init_<>_smc() is also where the mode & log pages are setup.

I've tended to spend most time on STK L180/L700 and IBM LTO emulations..
Note: They *all* could do with more work to make them more true-to-life.

void init_scalar_smc(struct  lu_phy_attr *lu)
{
        smc_pm.name = "mhVTL - Scalar emulation";
        smc_pm.library_has_map = TRUE;
        smc_pm.library_has_barcode_reader = TRUE;
        smc_pm.library_has_playground = FALSE;
        smc_pm.dvcid_serial_only = FALSE;

        smc_pm.start_picker     = 0x0001;
        smc_pm.start_map        = 0x0010;
        smc_pm.start_drive      = 0x0100;
        smc_pm.start_storage    = 0x1000;

Note: I'm always after updated vendor documentation (typically they name the docs as SCSI Programmers Guide) - Feel free in sending any pointers to updated docs..

[Mark Harvey]

Tim Jones wrote

Found the notes in the docs folder concerning the removal of the init.d scripts.  Not a fan of systemd, but it will work.

Ditto, however almost all distro have gone this way.

Tim Jones wrote

Has anyone developed a full step guide for implementation?  I've enabled the mhvtl.target and systemctl says that it's active and enabled, but the kernel module isn't loading and I have to manually launch the vtltape and vtllibrary user daemons.

Problems are two fold:
Following a fresh OS install:
mhvtl> sudo make install

$ ldd /usr/bin/vtltape
	linux-vdso.so.1 =>  (0x00007fffff4f3000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f7ca1995000)
	libvtlcart.so => not found
	libvtlscsi.so => not found
	libc.so.6 => /lib64/libc.so.6 (0x00007f7ca15c8000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f7ca1bab000)

Fix:
$ sudo ldconfig

From the systemd side of things: (assume you went into mhvtl/kernel and make && sudo make install)

$ sudo systemctl daemon-reload
$ sudo systemctl start mhvtl-load-modules
$ sudo systemctl start mhvtl.target
$ lsscsi -g
[1:0:0:0]    cd/dvd  VBOX     CD-ROM           1.0   /dev/sr0   /dev/sg1 
[2:0:0:0]    disk    VBOX     HARDDISK         1.0   /dev/sda   /dev/sg0 
[3:0:0:0]    mediumx STK      L700             0106  /dev/sch0  /dev/sg3 
[3:0:1:0]    tape    IBM      ULT3580-TD5      0106  /dev/st6   /dev/sg9 
[3:0:2:0]    tape    IBM      ULT3580-TD5      0106  /dev/st0   /dev/sg2 
[3:0:3:0]    tape    IBM      ULT3580-TD4      0106  /dev/st4   /dev/sg7 
[3:0:4:0]    tape    IBM      ULT3580-TD4      0106  /dev/st2   /dev/sg5 
[3:0:8:0]    mediumx STK      L80              0106  /dev/sch1  /dev/sg11
[3:0:9:0]    tape    STK      T10000B          0106  /dev/st3   /dev/sg6 
[3:0:10:0]   tape    STK      T10000B          0106  /dev/st7   /dev/sg10
[3:0:11:0]   tape    STK      T10000B          0106  /dev/st1   /dev/sg4 
[3:0:12:0]   tape    STK      T10000B          0106  /dev/st5   /dev/sg8 

Looks like RPM installer handles the ldconfig / systemd refresh pieces. Adding to the 'make install' Makefile target.

Thanks once again for the bug report.

[Tim Jones]

Hmmm, the load_modules fails.  Unfortunately, the error is simply "RETURN".

...

Found it - modprobe is in /sbin instead of /usr/sbin on this system.  Again, probably my fault for running custom tool chains.  I just create a symlink to /sbin/modprobe and we're off and running.

Now that I've sorted that, can you think of a reason that would cause vtltape and vtllibrary to not load automatically?  I'm sure I've missed a step ...

BTW - we're swapping Summers - I'm in Phoenix, AZ.  Really looking forward to July! (NOT).

[Mark Harvey]

Hmm.. Come to think of it - I'm not sure that the system mhvtl.target is set to 'enabled'

e.g.

$ sudo systemctl enable mhvtl.target
Created symlink from /etc/systemd/system/multi-user.target.wants/mhvtl.target to /usr/lib/systemd/system/mhvtl.target.

$ sudo reboot

$ ssh markh@192.168.128.102
markh@192.168.128.102's password: 
Last login: Mon Apr  1 15:37:05 2019 from 192.168.128.1
[markh@tempcentos ~]$ lsscsi -g
[1:0:0:0]    cd/dvd  VBOX     CD-ROM           1.0   /dev/sr0   /dev/sg1 
[2:0:0:0]    disk    VBOX     HARDDISK         1.0   /dev/sda   /dev/sg0 
[3:0:0:0]    mediumx STK      L700             0106  /dev/sch0  /dev/sg10
[3:0:1:0]    tape    IBM      ULT3580-TD5      0106  /dev/st7   /dev/sg9 
[3:0:2:0]    tape    IBM      ULT3580-TD5      0106  /dev/st4   /dev/sg6 
[3:0:3:0]    tape    IBM      ULT3580-TD4      0106  /dev/st6   /dev/sg8 
[3:0:4:0]    tape    IBM      ULT3580-TD4      0106  /dev/st3   /dev/sg5 
[3:0:8:0]    mediumx STK      L80              0106  /dev/sch1  /dev/sg11
[3:0:9:0]    tape    STK      T10000B          0106  /dev/st2   /dev/sg4 
[3:0:10:0]   tape    STK      T10000B          0106  /dev/st1   /dev/sg3 
[3:0:11:0]   tape    STK      T10000B          0106  /dev/st5   /dev/sg7 
[3:0:12:0]   tape    STK      T10000B          0106  /dev/st0   /dev/sg2 

[Tim Jones]

One step closer - the XXXXXXXXX@.service files are not being copied to their proper location.

Should they go into mhtl.target.wants in /etc/systemd/system/?

[Tim Jones]

They were in /usr/lib/systemd/system, but there weren't symlinks to /etc/systemd/system/.  Added those, but no change.  The module loads and the mhvtl.target reports as enabled and running, but I have to manually kick off the user daemons.

[Mark Harvey]

Something to try:

Remove all mhvtl.target.wants directories:

root@tempcentos systemd]# find / -name mhvtl\*wants -print

/run/systemd/generator/mhvtl.target.wants

root@tempcentos systemd]# \rm -r /run/systemd/generator/mhvtl.target.wants

Confirm there are all gone ;)

root@tempcentos systemd]# find / -name mhvtl\*wants -print

Reload systemd daemon

[root@tempcentos systemd]# systemctl daemon-reload

Confirm the generator was called and was able to create the requested service files:

[root@tempcentos systemd]# find / -name mhvtl\*wants -print

/run/systemd/generator/mhvtl.target.wants

[root@tempcentos systemd]# ls -l /run/systemd/generator/mhvtl.target.wants

total 0

lrwxrwxrwx. 1 root root 43 Apr  2 07:32 [hidden email] -> /usr/lib/systemd/system/vtllibrary@.service

lrwxrwxrwx. 1 root root 43 Apr  2 07:32 [hidden email] -> /usr/lib/systemd/system/vtllibrary@.service

lrwxrwxrwx. 1 root root 40 Apr  2 07:32 [hidden email] -> /usr/lib/systemd/system/vtltape@.service

lrwxrwxrwx. 1 root root 40 Apr  2 07:32 [hidden email] -> /usr/lib/systemd/system/vtltape@.service

lrwxrwxrwx. 1 root root 40 Apr  2 07:32 [hidden email] -> /usr/lib/systemd/system/vtltape@.service

lrwxrwxrwx. 1 root root 40 Apr  2 07:32 [hidden email] -> /usr/lib/systemd/system/vtltape@.service

lrwxrwxrwx. 1 root root 40 Apr  2 07:32 [hidden email] -> /usr/lib/systemd/system/vtltape@.service

lrwxrwxrwx. 1 root root 40 Apr  2 07:32 [hidden email] -> /usr/lib/systemd/system/vtltape@.service

lrwxrwxrwx. 1 root root 40 Apr  2 07:32 [hidden email] -> /usr/lib/systemd/system/vtltape@.service

lrwxrwxrwx. 1 root root 40 Apr  2 07:32 [hidden email] -> /usr/lib/systemd/system/vtltape@.service

*If* all goes according to plan - the daemons should automagically start

[root@tempcentos systemd]# systemctl start mhvtl.target

[root@tempcentos systemd]# lsscsi -g

[1:0:0:0]    cd/dvd  VBOX     CD-ROM           1.0   /dev/sr0   /dev/sg1 

[2:0:0:0]    disk    VBOX     HARDDISK         1.0   /dev/sda   /dev/sg0 

[3:0:0:0]    mediumx STK      L700             0106  /dev/sch1  /dev/sg6 

[3:0:1:0]    tape    IBM      ULT3580-TD5      0106  /dev/st1   /dev/sg3 

[3:0:2:0]    tape    IBM      ULT3580-TD5      0106  /dev/st5   /dev/sg9 

[3:0:3:0]    tape    IBM      ULT3580-TD4      0106  /dev/st0   /dev/sg2 

[3:0:4:0]    tape    IBM      ULT3580-TD4      0106  /dev/st7   /dev/sg11

[3:0:8:0]    mediumx STK      L80              0106  /dev/sch0  /dev/sg4 

[3:0:9:0]    tape    STK      T10000B          0106  /dev/st2   /dev/sg5 

[3:0:10:0]   tape    STK      T10000B          0106  /dev/st3   /dev/sg7 

[3:0:11:0]   tape    STK      T10000B          0106  /dev/st4   /dev/sg8 

[3:0:12:0]   tape    STK      T10000B          0106  /dev/st6   /dev/sg10

[root@tempcentos systemd]# 

If not - perhaps a “journalctl -xr” (reverse date order) to see if there are any hints there..

On 1 Apr 2019, at 4:18 pm, Tim Jones [via mhVTL - A Linux Virtual Tape Library] <[hidden email]> wrote:

They were in /usr/lib/systemd/system, but there weren't symlinks to /etc/systemd/system/.  Added those, but no change.  The module loads and the mhvtl.target reports as enabled and running, but I have to manually kick off the user daemons.

---

If you reply to this email, your message will be added to the discussion below:

http://mhvtl-a-linux-virtual-tape-library.966029.n3.nabble.com/Latest-source-build-does-not-install-init-d-nor-systemd-scripts-tp4026208p4026218.html

To start a new topic under mhVTL - A Linux Virtual Tape Library, [hidden email]
To unsubscribe from mhVTL - A Linux Virtual Tape Library, click here.
NAML

[Tim Jones]

I deleted everything and did a daemon-reload, but the mhvtl target wasn't enabled, so the service wasn't configured.  I then enabled mhvtl.target and here's what happened:

● mhvtl.target - mhvtl service allowing to start/stop all vtltape@.service and vtllibrary@.service instances at once
   Loaded: loaded (/usr/lib/systemd/system/mhvtl.target; enabled; vendor preset: enabled)
   Active: inactive (dead) since Mon 2019-04-01 15:34:58 MST; 4min 21s ago
     Docs: man:man:vtltape(1)
           man:man:vtllibrary(1)

Mar 31 22:24:22 linserv64 systemd[1]: Reached target mhvtl service allowing to start/stop all vtltape@.service and vtllibrary@.service instances at once.
Apr 01 09:59:30 linserv64 systemd[1]: mhvtl.target: Wants dependency dropin /etc/systemd/system/mhvtl.target.wants/vtllibrary.service target /usr/lib/systemd/system/vtllibrary@.service has different name
Apr 01 09:59:30 linserv64 systemd[1]: mhvtl.target: Wants dependency dropin /etc/systemd/system/mhvtl.target.wants/vtltape.service target /usr/lib/systemd/system/vtltape@.service has different name
Apr 01 09:59:32 linserv64 systemd[1]: mhvtl.target: Wants dependency dropin /etc/systemd/system/mhvtl.target.wants/vtllibrary.service target /usr/lib/systemd/system/vtllibrary@.service has different name
Apr 01 09:59:32 linserv64 systemd[1]: mhvtl.target: Wants dependency dropin /etc/systemd/system/mhvtl.target.wants/vtltape.service target /usr/lib/systemd/system/vtltape@.service has different name
Apr 01 15:34:58 linserv64 systemd[1]: Stopped target mhvtl service allowing to start/stop all vtltape@.service and vtllibrary@.service instances at once.

Here's what I found in /usr/lib/systemd/system:

mhvtl-load-modules.service  mhvtl.target  vtllibrary@.service  vtltape@.service

This system is easy to reconfigure, so blowing it away and restarting this with no broken bits left around  might be the best idea?

[Tim Jones]

Update on 3 OSes -

Unmodified CentOS 7.1804 -
make
make install
systemctl enable
systemctl daemon-reload
reboot
Works!

My modified custom toolchain CentOS 7.1805 -
As above, but the automatic launch and shutdown of the vtllibrary and vtltape daemons does not occur
Adding calls to the rc.local solved that

Ubuntu Server 18.04
Total manual process - Debian has a different layout from RH/Cent/Fedora and a number of commands are in different locations.
Got things working with some symlink magic between what is there and what your scripts expect.

Since I have a pretty good handle on the pitfalls of a non-standard RPM environment, I'll document as time permits.

[Mark Harvey]

Sounds good & thanks for the update.

I'm just about to spin it up on Raspberry Pi 2B (Why ? Because it's there.).. Any tips/traps most welcome :)

[Tim Jones]

I'll do the same.  I've a number of Raspberry and Pi-alikes here.  In fact, I have a RockPRO 64 that's dying to become a private cloud backup server.  It even has a real PCIe 2.0 x4 slot built in :).

I already have our full BRU Server environment running on the Pi families.

Tim

On Apr 1, 2019, at 6:00 PM, Mark Harvey [via mhVTL - A Linux Virtual Tape Library] <[hidden email]> wrote:

Sounds good & thanks for the update.

I'm just about to spin it up on Raspberry Pi 2B (Why ? Because it's there.).. Any tips/traps most welcome :)

---

If you reply to this email, your message will be added to the discussion below:

http://mhvtl-a-linux-virtual-tape-library.966029.n3.nabble.com/Latest-source-build-does-not-install-init-d-nor-systemd-scripts-tp4026208p4026222.html

To unsubscribe from Latest source build does not install init.d nor systemd scripts, click here.
NAML