Posted on

#StackBounty: #ubuntu #systemd #docker Install srvadmin-hapi package on Ubuntu 18.04 docker container is not working

Bounty: 100

As per Dell Documentation https://linux.dell.com/repo/community/openmanage/ I am trying to install Dell OpenManage tools in Ubuntu 18.04 container .

sudo echo 'deb http://linux.dell.com/repo/community/openmanage/940/bionic bionic main' | sudo tee -a /etc/apt/sources.list.d/linux.dell.com.sources.list
sudo wget https://linux.dell.com/repo/pgp_pubkeys/0x1285491434D8786F.asc
sudo apt-key add 0x1285491434D8786F.asc
sudo apt-get update
sudo apt-get install -y srvadmin-idracadm8

But I am getting below error

Setting up srvadmin-hapi (9.4.0) ...
System has not been booted with systemd as init system (PID 1). Can't operate.
dpkg: error processing package srvadmin-hapi (--configure):
 installed srvadmin-hapi package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 srvadmin-hapi
E: Sub-process /usr/bin/dpkg returned an error code (1)

I looked into the solution Install srvadmin-hapi package on docker container . But used command gpg --keyserver pool.sks-keyservers.net --recv-key 1285491434D8786F is not working getting gpg: keyserver receive failed: no name .

As per https://linux.dell.com/repo/community/openmanage/ we should use sudo wget https://linux.dell.com/repo/pgp_pubkeys/0x1285491434D8786F.asc to add repository key.

Get this bounty!!!

Posted on

#StackBounty: #18.04 #systemd #preseed #ansible rsyslog.service not found by Ansible during preseed late_command

Bounty: 50

I continually find that certain things "just don’t work" when run as preseed/late_command in an Ubuntu Bionic preseed file. (The same applies to autoinstall for Ubuntu Focal.) In this particular case, I’m attempting to run an Ansible Role (specifically, the Canonical Ubuntu 18.04 LTS for Ansible STIG) against the target as a late_command:

d-i    preseed/late_command    string 
    in-target /usr/bin/curl -fsSL -o /opt/stig.zip {{ di_preseed.stig_role_url }}; 
    in-target /usr/bin/unzip -qq /opt/stig.zip -d /opt; 
    in-target /usr/bin/unzip -qq /opt/ubuntu1804STIG-ansible.zip -d /opt; 
    in-target /bin/sh -c -- 'cd /opt && ANSIBLE_LOG_PATH=/var/log/ansible.log /bin/sh enforce.sh'

Here enforce.sh is just a wrapper around ansible-playbook.

This install from ISO on Virtualbox fails with:

Failed to run preseeded command ... <command> finished with exit code 2

I am still able to log in to the box as ubuntu and become root. I see that Ansible was successfully installed (it is originally specified in pkgsel/include).

I then open up /var/log/installer/syslog on the target and find that ansible-playbook failed when it could not find rsyslog.service:

enter image description here

This is confusing as rsyslog.service is most certainly enabled and active after the install, which I can confirm with systemctl (status|is-active) rsyslog.

So what I’m seeking to understand here is:

  • Why is Ansible unable to find rsyslog.service during install even though it appears to be enabled?
  • What factors are different about the installation that result in things seeming to commonly break or not be available?
  • Would I be better of running this as an onboot script under init.rc, then last line it removes itself after done?

Related: Certain commands (e.g. modprobe or usermod) fail as late-commands in Ubuntu autoinstall

Get this bounty!!!

Posted on

#StackBounty: #systemd #systemd-journald systemd-journald[356]: Failed to open system journal: Operation not supported

Bounty: 400

My /var/log/syslog and dmesg is being filled with errors from systemd. Searching the internet for: systemd-journald "operation not supported", gives no valuable results.

Here is a sample of my syslog

Jul 16 03:03:20 gaming kernel: [12187.062877] systemd-journald[356]: Failed to open system journal: Operation not supported
Jul 16 03:03:20 gaming kernel: [12187.072868] systemd-journald[356]: Failed to open system journal: Operation not supported
Jul 16 03:03:20 gaming kernel: [12187.310756] systemd-journald[356]: Failed to open system journal: Operation not supported
Jul 16 03:03:20 gaming kernel: [12187.321562] systemd-journald[356]: Failed to open system journal: Operation not supported
Jul 16 03:03:20 gaming kernel: [12187.332766] systemd-journald[356]: Failed to open system journal: Operation not supported
Jul 16 03:03:20 gaming kernel: [12187.342772] systemd-journald[356]: Failed to open system journal: Operation not supported
Jul 16 03:03:23 gaming systemd[1]: Started Session c1192 of user pinker.
Jul 16 03:03:24 gaming kernel: [12191.020723] systemd-journald[356]: Failed to open system journal: Operation not supported
Jul 16 03:03:24 gaming kernel: [12191.030607] systemd-journald[356]: Failed to open system journal: Operation not supported
Jul 16 03:03:24 gaming kernel: [12191.129098] systemd-journald[356]: Failed to open system journal: Operation not supported
Jul 16 03:03:24 gaming kernel: [12191.138991] systemd-journald[356]: Failed to open system journal: Operation not supported
Jul 16 03:03:24 gaming kernel: [12191.303171] systemd-journald[356]: Failed to open system journal: Operation not supported
Jul 16 03:03:24 gaming kernel: [12191.313662] systemd-journald[356]: Failed to open system journal: Operation not supported
Jul 16 03:03:24 gaming kernel: [12191.324551] systemd-journald[356]: Failed to open system journal: Operation not supported
Jul 16 03:03:24 gaming kernel: [12191.334600] systemd-journald[356]: Failed to open system journal: Operation not supported
Jul 16 03:03:24 gaming kernel: [12191.434910] systemd-journald[356]: Failed to open system journal: Operation not supported
Jul 16 03:03:24 gaming kernel: [12191.444927] systemd-journald[356]: Failed to open system journal: Operation not supported

OS: Ubuntu 18.04 using Overlayfs root. I’ve been running this setup for years without problem, but recently I added a btrfs raid1 to the system for extra storage. I suspect my issue may be related to the new storage.

I’m not sure what other information to provide.

Get this bounty!!!

Posted on

#StackBounty: #18.04 #bash #python #systemd Configuring systemd to manage a service on boot

Bounty: 50

I have a script that downloads an image from a web page and sets it as my desktop wallpaper. The code works fine but I am having trouble getting it to run on boot.

I am trying to do this by configuring systemd to manage a service. (crontab didn’t work for me when rebooting but that’s another issue).

I made a file /etc/systemd/system/apod.service:

[Unit]
Description=Set APOD as Desktop

[Install]
WantedBy=multi-user.target

[Unit]
Wants=network-online.target
After=network-online.target

[Service]
ExecStart=/bin/bash /home/me/apod.sh
Type=simple
User=me
Group=me
WorkingDirectory=/home/me
Restart=on-failure

But when I boot it doesn’t seem to work. If I check systemctl status apod, I see:

Jun 04 20:55:55 me-XPS-15-9500 systemd[1]: Started Set APOD as Desktop.
Jun 04 20:55:57 me-XPS-15-9500 gsettings[1598]: failed to commit changes to dconf: Could not connect: No such file or directory

Yet if I just manually run /bin/bash /home/me/apod.sh then it works perfectly.

Any suggestions welcome. I’m running 18.04.

For completeness:

The bash script:

#!/bin/sh                                                                                                 

export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$(id -u)/bus"

python /home/me/apod.py

/usr/bin/gsettings set org.gnome.desktop.background picture-uri "file:///home/me/Downloads/apod.jpg"

The python script it calls:

from bs4 import BeautifulSoup as BSHTML
import requests
import subprocess
import urllib2
page = urllib2.urlopen('https://apod.nasa.gov/apod/astropix.html')
soup = BSHTML(page,features="html.parser")
images = soup.findAll('img')

url = 'https://apod.nasa.gov/apod/'+images[0]['src']
r = requests.get(url, allow_redirects=True)
with open('/home/me/Downloads/apod.jpg',"w") as f:
            f.write(r.content)

Get this bounty!!!

Posted on

#StackBounty: #boot #server #systemd systemd-boot-messages are shortened on small display and thus unreadable

Bounty: 50

I’m using a small display with a resolution of 480×800 pixel. When I boot my raspberry-pi-system, using Ubuntu server 20.04.2 LTS, the systemd-boot-messages are shortened and thus unreadable on my small display .

What I’ve also observed is the fact that the systemd-boot-messages are only written in one single line. Meaning, if the message is longer, no new-line is used. Another thing is, the systemd-boot-messages don’t use the entire space of my display, even if they could do so.

My question, is it possible to enable some kind of verbose mode? So that the entire message is displayed, even with use of new-lines?

Here a picture:
https://i.postimg.cc/9QNd9Hkw/20210421-114747.jpg

Get this bounty!!!

Posted on

#StackBounty: #systemd systemd service "installer" which reinstalls other subsequent services which do not start up in this c…

Bounty: 50

What could be the reason, why could it not work and how to solve the problem?

I have an "installer" and several other "firmware" services which are registered to systemd and normally start on Linux booting. Usually the "installer" service has nothing to do in its script.

installer service:

[Unit]
Description=INSTALLER
Before=network-pre.target

[Service]
ExecStart=/opt/product/sbin/do-installer.sh
StandardOutput=journal+console
Type=oneshot

[Install]
WantedBy=multi-user.target

typical firmware service:

[Unit]
Description=Firmware
Wants=network.target multi-user.target systemd-hostnamed.service connman.service installer.service
After=network.target multi-user.target systemd-hostnamed.service connman.service installer.service

[Service]
ExecStart=/opt/product/sbin/firmware.sh
StandardOutput=journal+console

[Install]
WantedBy=multi-user.target

The firmware update mechanism works in the way that during booting the "installer" service sometimes detects there’s something to do, and then it immediately calls its firmware update script which is executed and finishes before the network comes up. Firmware update means to deinstall and to install the firmware service.

I have the problem that after such reinstallation the firmware service does not start. I always have to reboot again to get the newly installed firmware start up. I don’t understand the reason.

Get this bounty!!!

Posted on

#StackBounty: #systemd #services #chroot Running a systemd service with RootDirectory= and access /bin binaries

Bounty: 50

I’m trying to utilize some of the systemd helpers to chroot(2) the process using RootDirectory=. It’s a rudimentary Python script that lives under /srv/http that hosts a web server. It has a shebang #!/usr/bin/python (and I’ve also tried different combinations)

The service file is also quite simple:

[Unit]
Wants=network-online.target
After=network-online.target

AssertPathExists=/srv/http

[Service]
Type=simple
Restart=always
RestartSec=10

RootDirectory=/srv/http
PrivateTmp=true

ExecStart=/server.py
PIDFile=/run/miniweb.pid

[Install]
WantedBy=multi-user.target

The log clearly says it can’t find the executable:

Mar 11 19:23:49 bigrigv2 systemd[13213]: testweb.service: Failed to execute /server.py: No such file or directory
Mar 11 19:23:49 bigrigv2 systemd[13213]: testweb.service: Failed at step EXEC spawning /server.py: No such file or directory

It’s marked as executable:

-rwxr-xr-x 1 anton anton  650 Mar 11 19:06 server.py

I also tried ExecStart=/bin/python /srv/http/server.py and other variations.
I’m not entirely sure I even understand the concept of RootDirectory and how to properly execute for instance Python or other binaries from a chrooted service script. My assumption is that before executing the service, it chroot:s in to /srv/http after which the service won’t be able to back out and execute Python in this case. Which would make sense, but then I don’t quite get why /server.py isn’t found. And how would you execute things that are dependent on other binaries? Most solutions mention utilizing the language (C for instance) chroot and control it from the application, but then I don’t understand the point of offering chroot in the service script for other things than very limited bash scripts or standalone binaries.

Probably an extremely easy problem, but I’m quite lost and any help would be appreciated!

Get this bounty!!!

Posted on

#StackBounty: #systemd #tracker tracker service running every minute

Bounty: 50

I have the following lines repeating every minute in my /var/log/syslog file.

Oct  9 19:19:42 my_machine dbus-daemon[2138]: [session uid=1000 pid=2138] Activating via systemd: service name='org.freedesktop.Tracker1.Miner.Extract' unit='tracker-extract.service' requested by ':1.66' (uid=1000 pid=2555 comm="/usr/lib/tracker/tracker-miner-fs " label="unconfined")
Oct  9 19:19:42 my_machine systemd[2118]: Starting Tracker metadata extractor...
Oct  9 19:19:42 my_machine dbus-daemon[2138]: [session uid=1000 pid=2138] Successfully activated service 'org.freedesktop.Tracker1.Miner.Extract'
Oct  9 19:19:42 my_machine systemd[2118]: Started Tracker metadata extractor.
Oct  9 19:19:53 my_machine systemd[2118]: tracker-extract.service: Succeeded.

Can somebody explain what is going on.

My system is Ubuntu 19.04 with latest updates. This problem seems to have started around April 21st. Probably after upgrading 18.10 to 19.04.

How can I change the period from 1 minute to (say) 1 hour?

Get this bounty!!!

Posted on

#StackBounty: #20.04 #keyboard #systemd #udev #microsoft-keyboard Can't remap keys on a Microsoft Keyboard with HWDB

Bounty: 50

I’m trying to remap LCtrl and CapsLock on my Microsoft Wired Keyboard 600 with HWDB but for whatever reason the system does not see the changes that I make.

This is how my hwdb rule looks like:

evdev:input:b*v045Ep07F8*
 KEYBOARD_KEY_3a=leftctrl
 KEYBOARD_KEY_1d=capslock

The vendor and the model codes come from lsusb and were reconfirmed in /sys/devices/pci0000:00/*

After copying the config file to /etc/udev/hwdb.d, running systemd-hwdb update and issuing udevadm trigger no changes in the keyboard config are present.

I’ve also tried:

  • Rebooting — didn’t help.
  • Specifying the bus explicitly as 0003 — didn’t help.
  • Confirming with evtest that the key codes I’m using are correct for my keyboard — yep, those are the correct keycodes.
  • Confirming the applied rules are listed in sudo udevadm info /sys/class/input/eventX — yes, the new rules are listed, which should mean they were applied successfully? Yet the keys behave the same way they did before.
E: KEYBOARD_KEY_1d=capslock
E: KEYBOARD_KEY_3a=leftctrl
E: ID_USB_DRIVER=usbhid

When I use evdev:atkbd:dmi:* as the device identifier instead the change is correctly applied to my laptop keyboard so I know the rule and the process I’m using to remap the keys should be correct, it’s got to be an issue with the wrong identifier (though I’ve quintuple checked it).

Any help will be appreciated.

Get this bounty!!!