Yearly Archives: 2017

How to find the program interpreter that a Linux application requests 1

 in GNU/Linux  tagged cut / elf / readelf / tr by
Recently we tried to execute an application and we got the following error:
-bash: ./main: No such file or directory
This error occurred because our application was trying to use an interpreter that was not available on that machine.
We used the readelf utility that displays information about ELF files (including the interpreter information) to resolve our issue.
Specifically we used readelf -l ./main which displays the information contained in the file’s segment headers, if it has any.
(You can replace the parameter -l with --program-headers or --segments, they are the same).

From the data that was produced we only needed the following line:

[Requesting program interpreter: /lib/ld-linux-armhf.so.3]
so we used grep to filter out all other lines and then cut and tr to get the data after the : character (second column) and then remove all spaces and the ] character from the result.
The full and final command we used was:
readelf -l ./main | grep 'Requesting' | cut -d':' -f2 | tr -d ' ]';

Device has MAC address X, instead of configured address Y.

 in GNU/Linux  tagged address / eth0 / MAC by

Recently, we tried to take a network interface down on a VM, when we executed the command

ifdown eth0

we got the following error:

ERROR    : [/etc/sysconfig/network-scripts/ifdown-eth] Device  has MAC address 00:00:00:00:00:00
 00:45:4D:04:02:36
 00:45:4D:04:02:40, instead of configured address 00:45:4D:16:0B:29. Ignoring.

We used ifconfig eth0 to check the information on the network interfaces which resulted in the following data:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
 inet 10.1.20.115  netmask 255.255.255.0  broadcast 10.1.20.255
 inet6 fe80::215:5dff:fe01:236  prefixlen 64  scopeid 0x20<link>
 ether 00:45:4d:04:02:36  txqueuelen 1000  (Ethernet)
 RX packets 10103919  bytes 5474528935 (5.0 GiB)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 6541413  bytes 1190276207 (1.1 GiB)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

We saw that the value ether for eth0 was 00:45:4d:04:02:36, which was one of the addresses the warning mentioned that are valid.

Apparently, we had an error in the following configuration file:

/etc/sysconfig/network-scripts/ifcfg-eth0

The value for HWADDR was set to 00:45:4D:16:0B:29 which was wrong (most likely this file was copied here from another source), after we updated the value to 00:45:4d:04:02:36 we were able to use the device normally.

Fedora: Start a Virtual Machine using a physical hard disk

 in Virtualization  tagged physical hard disk / qemu by

Recently, we wanted to start a Virtual Machine running a Windows installation from a physical hard disk.

We could not find a way for GNOME Boxes to achieve this, so we installed qemu to do so.

We installed qemu using:


sudo dnf install qemu -y;

Configuring our command to start the Virtual Machine from the physical hard drive:

  • Our hard disk was identified on the physical machine as /dev/sda so we set the -hda parameter to that value.
  • Then we added the parameter -boot c to instruct the virtual machine to boot from the first hard disk.
  • The default guest start-up RAM size was 128 MiB, so we set the parameter -m to 4096 to give to the virtual machine 4GB of RAM.
  • Finally we added the -snapshot parameter which instructed the system to write to temporary files instead of the disk image files (all disk images are considered as read only).
    In this case, the raw disk image used are not written back. When sectors are written, they are written in a temporary file created in /tmp.
    You can however force the write back to the raw disk images by using the commit monitor command (or C-a s in the serial console).

In the end our command was as follows:


sudo qemu-kvm -snapshot -m 4096 -boot c -hda /dev/sda;

Start CLion as root on Fedora 1

 in GNU/Linux  tagged clion / linux / root / x-server / xhost by

Solution

Execute the following as a normal user


xhost +si:localuser:root;
sudo ./clion.sh;

Background Story and More Information

Recently we needed to start CLion as root on Fedora to allow the application we were developing to bind the DHCP service of the system.
When we tried to start CLion as root we got the following error:

java.awt.AWTError: Can't connect to X11 window server using ':0' as the value of the DISPLAY variable.

Specifically, the whole error log was as follows:

[george@bytefreaks bin]$ sudo ./clion.sh 
[sudo] password for george: 
No protocol specified

Start Failed: Failed to initialize graphics environment

java.awt.AWTError: Can't connect to X11 window server using ':0' as the value of the DISPLAY variable.
    at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
    at sun.awt.X11GraphicsEnvironment.access$200(X11GraphicsEnvironment.java:65)
    at sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:115)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.awt.X11GraphicsEnvironment.<clinit>(X11GraphicsEnvironment.java:74)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:264)
    at java.awt.GraphicsEnvironment.createGE(GraphicsEnvironment.java:103)
    at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:82)
    at sun.awt.X11.XToolkit.<clinit>(XToolkit.java:126)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:264)
    at java.awt.Toolkit$2.run(Toolkit.java:860)
    at java.awt.Toolkit$2.run(Toolkit.java:855)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:854)
    at java.awt.Toolkit.getEventQueue(Toolkit.java:1734)
    at java.awt.EventQueue.isDispatchThread(EventQueue.java:1043)
    at javax.swing.SwingUtilities.isEventDispatchThread(SwingUtilities.java:1361)
    at javax.swing.text.StyleContext.reclaim(StyleContext.java:454)
    at javax.swing.text.StyleContext.addAttribute(StyleContext.java:311)
    at javax.swing.text.html.StyleSheet.addAttribute(StyleSheet.java:578)
    at javax.swing.text.StyleContext$NamedStyle.addAttribute(StyleContext.java:1501)
    at javax.swing.text.StyleContext$NamedStyle.setName(StyleContext.java:1312)
    at javax.swing.text.StyleContext$NamedStyle.<init>(StyleContext.java:1259)
    at javax.swing.text.StyleContext.addStyle(StyleContext.java:107)
    at javax.swing.text.StyleContext.<init>(StyleContext.java:87)
    at javax.swing.text.html.StyleSheet.<init>(StyleSheet.java:166)
    at javax.swing.text.html.HTMLEditorKit.getStyleSheet(HTMLEditorKit.java:391)
    at com.intellij.util.ui.UIUtil.<clinit>(UIUtil.java:102)
    at com.intellij.ide.plugins.PluginManager.start(PluginManager.java:73)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at com.intellij.ide.Bootstrap.main(Bootstrap.java:39)
    at com.intellij.idea.Main.main(Main.java:81)

This error occurred because the default configuration of the X server permissions did not allow the root to connect to it.
To verify this, we used xhost X server access control program to check the permissions.
Executing xhost with no command line arguments gave us a message indicating whether or not access control was currently enabled, followed by the list of those users allowed to connect.
For example in our case the output was as follows:


[george@bytefreaks bin]$ xhost
access control enabled, only authorized clients can connect
SI:localuser:george

To add root to the list of users that was allowed to start an X application we executed the following command:


[george@bytefreaks bin]$ xhost +si:localuser:root
localuser:root being added to access control list

Executing xhost again, we got the updated list which included the root


[george@bytefreaks bin]$ xhost
access control enabled, only authorized clients can connect
SI:localuser:root
SI:localuser:george

After this, we were able to start CLion using sudo with no problems.


[george@bytefreaks bin]$ sudo ./clion.sh

Note: This patch is not permanent, we actually execute it once at every restart of the machine.