Earlier tool live-fat-stick uses syslinux to create multiboot USB stick/hdd on a vfat parition without having to format the stick preserving existing data and copying whole ISO so the same stick can serve as demo as well as to copy ISOs for distributing. However the disadvantages are all of them that comes from using vfat.

Grub2 has come a long way and almost all major distributions now support booting from the iso image via loopback. So here is live-grub-stick script that uses grub in place of syslinux bringing in all the advantages of using grub2.

Currently live images of openSUSE, Ubuntu, Fedora and all their clones are supported. Go ahead and fork it if you would like to add support for your distribution.

The best Linux distribution for education got a whole lot better, your Li-f-e(Linux for Education) takes a “Leap” to 42.1. openSUSE Education community is proud to present this latest edition based on openSUSE 42.1 with all the features, updates and bug fixes available on it till date. This effectively makes it the only enterprise grade long term supported(LTS) distribution for Education.

As with previous releases we have bundled a ton of softwares on this live DVD/USB specially packaged for education, along with the Plasma, GNOME and Mate Desktop Environments, full multimedia experience is also provided out of the box thanks to the Packman repositories. Only x86_64 architecture is supported, if you have a lot of machines that only support x86 then read on to find out how you can extend their Li-f-e.

You can of course very easily turn Li-f-e to full-fledged LTSP server to PXE boot machines in your local network. Booting both i686 and x86_64 architectures is supported. In case you need to PXE boot machines below i686 then you would have to install this package.

Happy holidays!

Get Li-f-e from here: Direct Download | md5sum | Alternate download and mirrors

SUSE's semi-annual Hackweek was last week and I decided to work on implementing docker rebase, mainly to learn about the internal image format of Docker and see whether it was possible to improve how the updating of Docker images works in practice (either rebuilding or zypper-docker).

Update: the MFC-7460DN printer is now supported via the brlaser open source printer driver by Peter De Wachter. See this post for a much simpler way to configure this printer on Fedora (and other Linux distributions).

I’ve always been a fan of Brother, as their devices usually come with decent support for the Linux OS (at least initially). I have an MFC-7460DN Laser Printer / Scanner in my home office, that worked fine with Ubuntu Linux for the past few years. It’s hooked up to my DSL router’s ethernet switch and acts like a network printer for all of our devices.

Just to keep my mind flexible and to take a look at another Linux distribution for a change, I recently started using Fedora Workstation 23 on my Laptop (a company-issued Lenovo ThinkPad T440s). While the OS installation was painless and all main components like Video, Audio, Networking were detected and configured correctly out of the box, the post-installation of some tools and services required some more effort.

This time, the printing part of the MFC-7460DN took me quite some time to figure out. While Brother provides RPM packages of the drivers, they are 32-bit only, and the instructions hadn’t been updated since Fedora 12. The first thing I had to do was to download two driver RPM packages. I initially started with the newer versions of the drivers, brgenml1cupswrapper-3.1.0 and brgenml1lpr-3.1.0, but somehow did not get them to work at all. I then tried the older packages, mfc7460dnlpr-2.1.0 and cupswrapperMFC7460DN-2.0.4. These installed flawlessly, and a new printer was added to the CUPS configuration automatically.

However, it was configured as a local printer, so I first had to change the existing configuration to talk to the remote LPD port instead. While the printer configuration looked correct and no errors showed up, all print jobs simply disappeared into the bit bucket, without any visible error on the application side. Unfortunately the web-based CUPS administration tool was not much helpful, either – the button View Error Log simply returned a “Not found” error. There was no error log file in /var/log/cups, so I queried the status of the CUPS service via systemd next.

The command systemctl status -l cups then gave me a first hint:

sh: /opt/brother/Printers/BrGenML1//lpd/rawtobr3: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory

Since this is a 32-bit binary, it might help to actually install a 32-bit version of the GNU C library! I simply forgot this step, even though it’s documented in the installation instructions. A simple dnf install glibc.i686 got me over this hurdle.

Unfortunately the print jobs still did not reach the printer and disappeared in the void! Checking the CUPS error log again, I now saw this:

/usr/local/Brother/Printer/MFC7460DN/lpd/filterMFC7460DN: line 131: 11660 Done                    eval cat $INPUT_TEMP
11661 Broken pipe             | $PSCONV $PSCONV_OP
11662 Segmentation fault      | $BRCONV $BRCONV_OP
PID 11602 (/usr/lib/cups/filter/brlpdwrapperMFC7460DN) exited with no errors.
PID 11603 (/usr/lib/cups/backend/lpd) exited with no errors.

Hilarious. Oh well, maybe the 32-bit binary is simply too old and crashes in the new environment? Let’s take a look at the full systemd journal with journalctl! This gave me further clues:

cupsd[10951]: /usr/local/Brother/Printer/MFC7460DN/lpd/filterMFC7460DN: line 131: 11660 Done                    eval cat $INPUT_TEMP
cupsd[10951]: 11661 Broken pipe             | $PSCONV $PSCONV_OP
cupsd[10951]: 11662 Segmentation fault      | $BRCONV $BRCONV_OP
cupsd[10951]: PID 11602 (/usr/lib/cups/filter/brlpdwrapperMFC7460DN) exited with no errors.
cupsd[10951]: PID 11603 (/usr/lib/cups/backend/lpd) exited with no errors.
cupsd[10951]: time-at-completed=1449759139
cupsd[10951]: Job completed.
cupsd[10951]: Removing document files.
dbus[1190]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd'
setroubleshoot[11624]: SELinux is preventing brprintconflsr3 from using the execmem access on a process. For complete SELinux messages. run sealert -l 5d873063-1d87-4e82-b
python3[11624]: SELinux is preventing brprintconflsr3 from using the execmem access on a process.
                                                
                                *****  Plugin catchall_boolean (89.3 confidence) suggests   ******************
                           
                                If you want to allow cups to execmem
                                Then you must tell SELinux about this by enabling the 'cups_execmem' boolean.
                                                
                                Do
                                setsebool -P cups_execmem 1
                                                
                                *****  Plugin catchall (11.6 confidence) suggests   **************************
                                                
                                If you believe that brprintconflsr3 should be allowed execmem access on processes labeled cupsd_t by default.
                                Then you should report this as a bug.
                                You can generate a local policy module to allow this access.
                                Do
                                allow this access for now by executing:
                                # grep brprintconflsr3 /var/log/audit/audit.log | audit2allow -M mypol
                                # semodule -i mypol.pp

OK, so SELinux seems to be getting in the way here. I did as suggested and ran the following commands:

# setsebool -P cups_execmem 1
# grep brprintconflsr3 /var/log/audit/audit.log | audit2allow -M brothermfc7460dn
# semodule -i brothermfc7460dn.pp

An lo and behold, the printer started printing! Let’s hope it still does when I reboot the system…

Things I learned and that surprised me:

• The error handling in CUPS completely failed here. There was not a single end-user accessible hint that something went wrong, the print jobs just disappeared in the void.
• The move to systemd still has some ripple effects, e.g. the “Not found” error for the missing CUPS error log in the web UI.
• Analyzing log files with journalctl is actually quite convenient. Instead of grepping and tailing multiple logs under /var/log/, these tasks can now be performed using a single tool.
• SELinux is still a bitch, even though the hints provided by setroubleshootd were quite useful to resolve the issues at hand.

GNOME's default UI typeface Cantarell gained a new maintainer, Nikolaus Waxweiler. Nikolaus was on a holy crusade to improve the state of text rendering on Linux by improving FreeType and lobbying for changes in different projects. While he continues on those efforts, bug reports hinted (pun intended) that GNOME's font rendered worse as FreeType improved so he went on to investigate why. It turns out that Cantarell had many metric related issues and its development was quite stagnant.

The process of making fonts look good even on our crappy LoDPI screens is commonly called hinting and it requires precision. Cantarell ships as an .otf font or OpenType font with Postscript-flavor. Hinting .otf fonts works differently from hinting common TrueType or .ttf fonts. You define several horizontal snapping zones, also called blue zones, like descender, x-height, capital height, ascender height, etc. so that they match your design. That means that the outlines you are designing must as a general rule be placed precisely within these blue zones or the hinting algorithm will ignore them. Blue zones must be constructed to contain everything they should contain. The idea is that a well designed typeface is consistent and regular enough that coarse blue zones describe the design well. The hinting algorithm of the font design application will then place stem information according to those blue zones, among other considerations. For a final rendering, glyphs are snapped to those horizontal blue zones, meaning they are only snapped on the Y-axis. Think ClearType.

Cantarell was full of off-by-ones-or-twos and technical don't-do-thats, diacritics were inconsistent and Cyrillics still need a look-over. The bold face was in an even poorer state. Back in June 2013 Adobe's contributed a new high-quality OpenType/Postscript-flavor hinting engine. The problems were only magnified because the new engine actually takes hinting information seriously and will spit out garbage when the font designer isn't careful.

Nikolaus has cleaned up the fonts considerably by fixing the blue zones, outline precision to fall within them and numerous other problems. You might also notice that letters like bdfklh are a bit taller for a more harmonious look. It should display consistently at all sizes now.

Oh, by the way: FreeType 2.6.2 brings more user-visible changes. If you are on a rolling-release distribution, you might have noticed them already. If you wish to read up more on those changes, Nikolaus wrote a lengthy article about the changes and future plans on freetype.org.

For a Cantarell 0.1.0 release we plan to have all accented glyphs fixed. Nikolaus has finished a first pass at diacritics and is now looking for testers. Anyone who deals with diacritics in his/her language, especially central European people, please get the .otf fonts from the git repo and report bugs to the GNOME bug tracker.

Do note that Nikolaus didn't just dive into maintainership, but wrote most of this post. My incentives to get him set up a blog and post on Planet GNOME have been fruitless so far.

Today the KDE team released a new version of it's desktop environment Plasma. It has now reached version 5.5 with a few nice new features.

New features in Plasma 5.5

For me the most important and most visible new feature is the update of Plasma's theme Breeze. This overhaul does not only mean that existing icons have been updated and improved and a few new icons have been added, but Breeze has been released for the GTK+2 and GTK+3 toolkits as well. This way GTK-based applications are now lo...

I wrote about how to run Rails with PostgreSQL on openSUSE 12.3 before. Things have changed since then. While Rails, PostgreSQL, and openSUSE are still excellent choices, new versions have been released. This warrants an update. So here is how to get a development environment of Rails with PostgreSQL running on the latest and greatest openSUSE Leap 42.1.

Install PostgreSQL:

    sudo zypper install postgresql-server postgresql-devel

Start the database server:

    sudo systemctl start postgresql

Enable server to be started on boot:

    sudo systemctl enable postgresql

Switch to the postgres user to set up the database:

    sudo su -l postgres

Create database user:

   createuser -d USERNAME

Return to your normal user, exchange the database driver in the Gemfile from sqlite3 to pg and run

   bundle install

Change the configuration of the database driver to something like:

  default: &default
    adapter: postgresql
    username: cs

  development:
    <<: *default
    database: APPNAME_development

  test:
    <<: *default
    database: APPNAME_test

  production:
    <<: *default
    database: APPNAME_production

Create the databases:

    rake db:create
    rake db:migrate
    rake db:migrate RAILS_ENV=test

That's it.

Time to get an update for fglrx: the new release has been build for 13.1, 13.2, Leap 42.1, and tumbleweed 20151201

Tumbleweed beware : broken Xorg

It seems since the release, that a number of report of broken xorg with gdm, ssdm and so… segfaulting

You can still use the previous version hanging on the server. But I doubt it would work better

As soon, with Sebastian Siebert we have a patch for, I will republish a new build

Informations & bugreport Sebastian’s blog or lizards.o.o

The proposed drivers support kernel up to version 4.4

AMD release note available

Sebastien Siebert making script

Sebastian Siebert posts about fglrx

If you have any problems with the driver, don’t be afraid to report to Sebastian (German and English bugreports are gladly accepted).
he will try, as far as I am able to reproduce the bug. Together with the necessary system information, he will go directly to the right place at AMD to have the bug fixed in the next driver release.
Thank you very much, Sebastian.

See below what to do in case of troubles.

Or you can also ping him on irc (freespacer)

Debugging troubles

I recommend in case of trouble the use of his script which can collect the whole informations needed to help you. then you just have to issue a simple commande in console to collect all informations, you can review them, and finally transmit them.
Check the website to get the latest.

su -c 'sh makerpm-amd-15.11.sh -ur'
The system report 'amd-report.txt' was generated.                                                                                                          [ OK ]
Do you want to read the system report 'amd-report.txt' now? yes/no [y/n]: y
Are you sure to upload the above-named system report to sprunge.us? yes/no [y/n]: y

The report was uploaded to sprunge.us.
   The link is:  http://sprunge.us/eMEB

Copy paste the link in the comment zone of Sebastian post

All proudly distributed by openSUSE powered server and sponsored by Ioda-Net Sàrl

Following up from my earlier post about openSUSE LTSP on Banana Pi, Nora Lee from the manufacturer of the board got in touch with me and sent me a couple of their new boards- Banana Pi M2, runs on A31s quad-core CPU and has 1G RAM, powerful enough to run openSUSE Tumbleweed with Xfce Desktop.

Here is how you can get openSUSE running on Banana Pi M2.

* Download the image

* Extract the archive to get openSUSE-Tumbleweed-Bpi-M2-Xfce.img

* Dump openSUSE-Tumbleweed-Bpi-M2-Xfce.img on to a SD card
(dd if=/path/to/openSUSE-Tumbleweed-Bpi-M2-Xfce.img of=/dev/sdX bs=4M; sync #replace /dev/sdX with your actual SD card device)

*  In case you have a bigger SD card, use yast2 disk(partitioner) to “expand” the second partition. You can use yast’s package manager to install more software. The default password for root is linux, you may want to change that first thing after booting.

I am unable to get sound on this hardware, probably their kernel is missing sound related modules, if you figure out how to get sound working drop me a line so I can include it in next release.Everything else(wifi, hdmi out, USB ports etc) works well enough.

openEMS packages are available from Science repository and main Tumbleweed repository.

openEMS is a free and open electromagnetic field solver using the FDTD method. Matlab or Octave are used as an easy and flexible scripting interface.

It features:

• Fully 3D Cartesian and cylindrical coordinates graded mesh.
• Multi-threading, SIMD (SSE) and MPI support for high speed FDTD.

See official site to get more information – openems.de.