Opensuse 42.2 emergency mode after install

Reinstalling my system, clean install of OpenSuse 42.2, but then at boot, after passing grub and kernel selection, it logs into the emergency shell.

Fokkow instructions in shell, give root password, and look for errors from logs using systemctl -xb 

It turns out that it was not able to mount /home

Checked /etc/fstab and the filesystem type was marked as unknown.

Edited to ext4, save, reboot, and Presto!

Advertisements

Welcome back to the family, Ubuntu.

Word has come out that Ubuntu is dropping its home-bred graphical engine and interface Unity, and returning to Gnome 3 Desktop.

The experiment lasted 7 years, Unity was introduced since  version 10.10 (Maverick Meerkat) and was touted (mainly only by Canonical) as visionary, making a more efficient use of the screen (very relative), with never materialized promises of superior (gaming?) performance and stability.

Canonical is also returning to its roots,concentrating on Desktop, Server, Cloud and IoT platforms, abandoning it’s plans to further develop a Phone Operative System.

The next version of Ubuntu, running Gnome will be 18.04 (LTS)

Running BOINC on OpenSuse

Notes on how to run BOINC on Opensuse (Leap 42.2) from command line as deamon.

Install the packages from packman repository

zypper in boinc-client boinc-manager

After installation verify that user and group boinc is created

cat /etc/passwd | grep boinc

cat /etc/groups | grep boinc

Add the user boinc to the group boinc.

usermod -G boinc -a boinc (repeat with any other user if necessary)

verify that boinc-client is already running as a daemon

ps -aux | grep boinc or systemctl status -l boinc-client.service

verify that all files under /var/lib/boinc are owned boinc:boinc

change permissions of /var/lib/boinc/gui_rpc_auth.cfg 

chmod 664 /var/lib/boinc/gui_rpc_auth.cfg

Optional, create simbolic link for user account logged in while running boinc

ls -s  /var/lib/boinc/gui_rpc_auth.cfg /home/<user>/gui_rpc_auth.cfg

Now, if previously attached to a project, retrieve your key:

boinccmd –lookup_account <project url> <email> <password>

Or create an account if needed:

boinccomd –create_account <project url> <email> <password> <name>

Attach to the project

boinccmd –project_attach <project url> <key>

Voila! you should be running now as a daemon and connected to the project.

Verify by issuing:

boinccmd –get_project_status or boinccmd –get_state

OpenSuse Linux, Citrix and Certs

I needed to remote in from my personal laptop running OpenSUSE Leap 42.1 into my work’s Citrix Remote Desktop runnin on a Windows Server farm.

After logging in, install the Citrix Reciever from your Citrix server (if provided), or from Citrix directly.

My version of receiver is 11.100 for linux x86.

The Linux installation is straight forward, accept the defaults.

Now, the tricky part.

Upon logging in and launching a RDP session, I received the following error message:

You have not chosen to trust “XXXYYY”, the issuer of the server’s security certificate (SSL error 61).

Upon some googling I decided to go to my certificate provider XXX, and download their Public Root Certificate Bundle.

After opening the tar file, found the certificates of type YYY. Then copied those certificates into the path of my Citrix Reciever installation, in my case:

/usr/lib/ICAClient/keystore/cacerts

Voila!

btrfs adventures on opensuse

I am currently using OpenSuse 13.2, and started using Picard for sorting my music, around 12000 files. Later I started doing some BASH script to further clean up the names of the mp3 files.

Anyhow, all of this to say, that I have been working the file system, copying, moving and erasing (hundreds) of files around.

At the end, the system started to be very slow, and at some point, gnome started to crash, funny enough, there is no /var/log/messages to check, 13.2 implements Systemd, so there is journalctl to check the error messages, but in the console (F12) many errors for different systemd components complaining that there was no space left on device, but doesn’t says which one, and doing a “df -h” shows still free space on the hard drives.

Puzzling.

At the end, the OpenSUSE forums gave me the solution on this thread.

If you keep reading, the problem is not the file system, it the meta data of the file system.

The default file system of OpenSuse13.2 is btrfs, which implements journalling and snapshot capabilities, and if not correctly tuned and configured, can generate this kind of scenarios.

The key commands to fix my issues were:

btrfs filesystem show

btrfs filesystem df (here you can see the meta data space full)

snapper -c root list (lists snapshots of root the file system)

snapper -c delete (this will clean the snapshots of the file system that are taking space, leaving the current one (0) and the last one)

btrfs balance start (in my case / for root, the closest explanation this is similar to a defrag>

Et Voila! space magically appears, and system is usable again.

Similar case, with explainations from “The Nerdy Room“.

Heartbleed and Shellshock are a good thing.

In this article by the Huffington Post titled ¨Apple joins rush to fix Shellshock bug affecting the internet” it seems like Apple users are in panic on how to patch their beloved and “more secure” computers from something that they hardly understand. And at the same time Apple, says, keep it cool, you are not affected as bad as you think you are.

For once, the joke (or bug) is on us Linux users. For those that don’t remember, Apple OS X in any of their versions, have a common root, BSD. BSD, has always been the quirky cousin of Linux, and all are descendents from the Unix family tree. Bash (Bourne Again Shell), is one of the many implementations of a “shell” (Family Tree Here) and BSD as all of the Unix descendents use some sort of a shell implementation.

Now, what is a shell? A shell is a command interpreter, It’s what would be used before the times of retina displays, graphical user interfaces, and mice. In Windows terms, it’s the command prompt. Is the way a user interacts with a computer with text commands typed on a black screen. I am old enough to remember a Internet driven by commands in green-over-black dumb Hayes VT-400 terminals.

“Shellshock”, the bug that bring us here, it’s a 26 year old bug in the Bash implementation of a shell. One of the things you want in a shell is the ability to define variables (text strings, numeric values, names of files, or the return value from a program or process), the bug is that when defining a variable you can also pass along a command, that can do anything, from listing the defined users for a computer, to erasing the hard drives. Basically, by calling a compromised variable defined in a shell, you can unwillingly execute commands that can gather information about the computer or compromise its information. Bad enough is that it not only can be run locally on the computer, but also remotely, from anywhere, as long as the computer is connected to the internet, and (for example) a web page calls a shell routine in the background to do something.

Most of the operational systems out there, descendents of Unix, Linux, BSD, OSX are implementing or have implemented patches for their shells to fix this vulnerability, and that is the easy part. There are millions of devices out there that build the internet itself, switches, routers, firewalls, load balancers, all components that make the internet work, all of those devices run some sort of operational system, most of them, Unix  descendents, in it’s miriad of implementations. All of those networked devices that make the infrastructure that makes the internet work are vulnerable and need to be patched.

And why “Heartbleed” and “Shellshock” are a good thing? Because it levels the field, makes us aware that there are no immune operational system, all needs to be checked, verified, and corrected; because a exposed vulnerability is better than an undocumented backdoor; because open source code can be checked, verified, and fixed by anyone with the knowledge, not hidden behind the closed doors and secrecy of a corporation.

But Apple users can sleep better tonight, knowing that there is a dedicated army of system and network administrators, around the world, testing, and patching, and working when you are sleeping, to make sure that tomorrow, you can read “The Huffington Post” securely in your tablet, sipping your espresso, in your bed.