Home Home > Tag > installation
Sign up | Login

Posts Tagged ‘installation’

Highlights of YaST Development Sprint 68

December 4th, 2018 by
  • UDF: Share big files with other operating systems
  • Raspberry Pi: Fully customized installation with YaST

Support for UDF file system

UDF (Universal Disk Format) is a file system format widely used for DVDs and newer optical disk formats, replacing ISO 9660. But this technology is not limited to optical media only, in fact it can be perfectly used on flash devices like USB sticks and hard drives too. UDF is one of the best choices when transferring data between platforms. Mostly all modern operating system already support it, including Windows, BSD, MacOS X, Solaris, OS/2 (eComStation), BeOS (Haiku) as well as Linux kernel.

UDF offers several advantages. One of them is the support for quite very large files. With UDF you can create files of several terabytes, making really ridiculous the maximum limitation of 4 gigabytes in VFAT. And not only that, UDF also has optional built-in ability to minimize wearing-off of rewritable media with limited rewrite cycles, such as flash, CD-RW and DVD-RAM.

YaST is starting to support UDF file systems out of the box. The Expert Partitioner now offers the UDF option when formatting a device, see the following screenshot. And this is available even during the installation, so you could create a volume with UDF format and share it between your different operating systems.

Just click "next" to install (open)SUSE in a Raspberry Pi

Anybody who has not been living under a rock for the last five years knows Raspberry Pi. And anyone who has used one of those devices knows the usual way to put an operating system into it is different from what we are used to do in other computers. Instead of installing from a regular ISO, customizing all the options in the process, Raspberry Pi and similar mini-computers are usually loaded with a pre-built image of an operating system (specific for each model) downloaded from the Internet. Many of those precooked Linux systems are purpose-specific and many decisions (like the file-system type to use) are already taken by those who built the image.

But we wanted SLE 15-SP1 and openSUSE Leap 15.1 to be the first multi-purpose operating systems to support a full standard Linux experience in Raspberry Pi. No custom specific ISO to install from, no precooked image to be copied, just taking the standard unmodified SLE or openSUSE ISO image and installing like you would do in any other computer. And we wanted the process to be as easy as pressing "next", "next", "next", "install". With the installer detecting and proposing the set of default configurations that makes sense, as usual.

The main challenge in that regard was the partitioning layout. In order to boot, the Raspberry Pi needs a very specific partition containing the system firmware. So it is important for the installer to detect such a partition and preserve it no matter what, mounting it in /boot/vc to allow the operating system to perform updates of the firmware. In the following screenshot of the installation process performed trough the Raspberry Pi serial console you can see that in action.

The serial console is the method preferred by the experts to manage the Raspberry Pi locally and it works out of the box with the pre-releases of the upcoming SLE-15-SP1 and Leap 15.1. But less advanced users will likely prefer to perform a graphical installation with a keyboard and a screen attached to the device. For it to work flawlessly, the following arguments must be provided to the installer during boot.

textmode=0 modprobe.blacklist=vc4

The second argument prevents the HDMI output to be disconnected shortly after the computer has booted, something that will only happen with some monitors. It happened to us during our testing (that you can see below) and that argument certainly made the problem disappear.

Just one final note if you want to play with this: Take into account Raspberry Pi uses a different internal architecture than usual PCs. So instead of the x86 image of the installer, you will need to use the aarch64 one. The aarch64 architecture is officially fully supported by SLE and also available for openSUSE Leap and Tumbleweed as an unofficial port.

Fun things to do with driver updates

April 25th, 2017 by

Today: And what if I want to remove some files?

It’s easy and obvious to add new files with a driver update (DUD). But what if you need to remove some files? Or, related: can you replace some read-only file by a writable copy?

Let’s for this article assume you want to modify the Xorg configuration. Say,
/usr/share/X11/xorg.conf.d/10-evdev.conf troubles you.

The direct way would be to write an update.pre script than removes the file and include this into a DUD.

update.pre is run right after the DUD has updated the files in the installation system.

For example:

echo \
  rm /usr/share/X11/xorg.conf.d/10-evdev.conf \
  > update.pre
mkdud --create test1.dud --dist tw --name "remove 10-evdev.conf" update.pre

But when we try test1.dud we run into this:

Driver Update: remove 10-evdev.conf
Driver Updates added:
  remove 10-evdev.conf
[...]
rm: cannot remove '/usr/share/X11/xorg.conf.d/10-evdev.conf': Read-only file system

So, we see the catch: much of the installation system resides on a read-only file system! You can’t just go and modify things.

But how does the driver update process manage to add new files to the installation system then? It does so by restructuring the file system using symlinks. In the process all directories that need to be modified are replaced by writable copies.

In other words: if you include the file you want to remove in the DUD – you will be able to remove it. It’s actually sufficient to include the directory the file resides in to make this work.

So, let’s try this:

mkdir -p /tmp/dud/usr/share/X11/xorg.conf.d
echo \
  "rm /usr/share/X11/xorg.conf.d/10-evdev.conf" \
  > update.pre
mkdud --create test2.dud --dist tw --name "remove 10-evdev.conf" update.pre /tmp/dud

Now we don’t get any error applying test2.dud and when we login to the installation system, we see:

console:vm9732:/ # ls -l /usr/share/X11/xorg.conf.d
total 0
console:vm9732:/ # 

Tip

For easy testing a DUD, boot the machine with

startshell=1 sshd=1 password=*** dud=<URL>

startshell=1 wi ll stop the installation workflow after the installation system has been fully prepared just before YaST will be started. sshd=1 will start an SSH daemon and you’ll be able to connect to the machine and look around.

A similar trick can be used to make files writable (watch out for correct shell quoting):

mkdir -p /tmp/dud/usr/share/X11/xorg.conf.d
echo \
  cp --remove-destination '$(readlink -f /usr/share/X11/xorg.conf.d/10-evdev.conf)' \
  /usr/share/X11/xorg.conf.d/10-evdev.conf \
  > update.pre
mkdud --create test3.dud --dist tw --name "make 10-evdev.conf writable" update.pre /tmp/dud

We can verify the result:

console:vm9732:/ # ls -l /usr/share/X11/xorg.conf.d               
total 4
-rw-r--r-- 1 root root 1099 Apr 24 13:06 10-evdev.conf
console:vm9732:/ #

The file is now writable.

Fun things to do with driver updates

March 16th, 2017 by

Today: But what if I need a new kernel?

A driver update (DUD) can of course update a single driver. But if that’s not enough and you need a whole new kernel to run an installation?

There are two parts to solve:

  1. replace the kernel used during installation and
  2. get the new kernel installed

We’ll need two tools for this (both available in Tumbleweed or here: mksusecd and mkdud).

1. Replace the kernel used during installation

For this it’s important to know which kernel packages you’ll actually need. Typically it will be kernel-default and kernel-firmware. But older SUSE distributions (SLE 11 comes to mind) had the kernel packages split into kernel-default and kernel-default-base – you’ll need them both.

To make things confusing, modern SUSE distributions also have kernel-default-base – but it’s an alternative to kernel-default. In this case we don’t need it.

If unsure, check kernel-default. If it contains the actual kernel (e.g. /boot/vmlinuz) then you don’t need kernel-default-base.

On some architectures modules are also taken from xen-kmp-default. If that’s important for you, you can add this package to the kernel list as well.

In fact you can add any number of kernel packages or kmps you like.

In the past, sometimes a different kernel flavor was used. For example PowerPC had kernel-ppc64 for a while. Simply use the flavor you need.

It’s a good idea to gather all the kernel rpms into a single directory for easier use:

> mkdir k
> cp kernel-default.rpm kernel-firmware.rpm k
> cp kernel-default-base.rpm k    # only if needed
# add any kernel-related rpms you need

Then, take your SUSE installation iso and run

> mksusecd --create new.iso \
  --kernel k/* -- \
  original_dvd1.iso

Note that the --kernel option accepts a variable number of arguments, so you have to add an isolated -- to terminate the argument list properly.

The output could look like this:

> mksusecd --create new.iso \
  --kernel k/* -- \
  SLES-11-SP4-DVD-ppc64-GM-DVD1.iso
kernel version: 3.0.101-63-ppc64 --> 3.0.101-94-ppc64
CHRP bootable (ppc64)
building: 100%
calculating sha1...

The command above will actually get the list of required modules from the old installation iso. If you are missing some driver or the new kernel comes with some additional driver, the module will not be added to the new iso.

But there’s the --modules option. It will add the listed modules together with any implicitly required modules via module dependencies.

For example, let’s add the airport wifi-module to our PowerPC iso:

> mksusecd --create new.iso \
  --kernel k/* \
  --modules airport -- \
  SLES-11-SP4-DVD-ppc64-GM-DVD1.iso
kernel version: 3.0.101-63-ppc64 --> 3.0.101-94-ppc64
kernel modules added:
  airport, cfg80211, orinoco
CHRP bootable (ppc64)
building: 100%
calculating sha1...

As you can see, it automatically adds orinoco and cfg80211 as well.

2. Get the new kernel installed

This is relatively simple. A driver update can do this:

> mkdud --create foo.dud \
  --dist sle11 \
  --install repo \
  k/*

This creates a driver update for SLE 11 (which also applies to SP4) and the kernel rpms are installed via an auto-generated add-on repo (--install repo).

Now we have the driver update that installs our kernel packages. But how do we use it?

We integrate it into our iso above!

> mksusecd --create new.iso \
  --initrd foo.dud \
  --kernel k/* -- \
  SLES-11-SP4-DVD-ppc64-GM-DVD1.iso

mksusecd has an --initrd option that directly accepts driver updates and integrates them into the iso.

3. Can I have a choice?

Maybe you just want to test this new kernel or sometimes need the old one and sometimes the new one. Can you make an installation iso that lets you choose the kernel?

Oh yes! 🙂

> mksusecd --create new.iso \
  --add-entry 3.0.101-94 \
  --initrd foo.dud \
  --kernel k/* -- \
  SLES-11-SP4-DVD-ppc64-GM-DVD1.iso

This does not replace the old kernel but adds a new boot entry Installation - 3.0.101-94.

So you can install with old or the new kernel.