Insert a DVD or a bootable USB stick containing the installation image for openSUSE Leap, then reboot the computer to start the installation program. On machines with a traditional BIOS you will see the graphical boot screen shown below. On machines equipped with UEFI, a slightly different boot screen is used. Secure boot on UEFI machines is supported.

On BIOS machines, use F2 to change the language for the installer. A corresponding keyboard layout is chosen automatically. See Section 2.2.1, “The boot screen on machines equipped with traditional BIOS” or Section 2.2.2, “The boot screen on machines equipped with UEFI” for more information about changing boot parameters. On UEFI machines adjust the language and keyboard settings in the next step.

Select Installation on the boot screen, then press Enter. This boots the system and loads the openSUSE Leap installer.

On systems with a traditional BIOS the Language and Keyboard Layout settings are initialized with the language you chose at the boot screen. If you did not change the default, or are using a UEFI machine it will be English (US). Change the settings here, if necessary. Use the Keyboard Test text box to test the layout.

Read the License Agreement. It is presented in the language you have chosen. Other License Translations are available. Proceed with Next.

If the network can not be configured automatically, the Network Settings dialog opens. Choose a network interface from the list and configure it with Edit. Alternatively, Add an interface manually. See Section 3.4, “Network settings” and Book “Reference”, Chapter 13 “Basic networking”, Section 13.4 “Configuring a network connection with YaST” for more information. If you prefer to do an installation without network access, skip this step without making any changes and proceed with Next.

A system analysis is performed, where the installer probes for storage devices, and tries to find other installed systems. If a network connection with Internet access is available, you will be asked to activate the online repositories. Answer with Yes to proceed. In case you do not have Internet access, this step will be skipped.

The online repositories are official openSUSE package sources. They not only offer additional packages not included on the installation media, but also the update repositories containing security and bug fixes. Using the default selection is recommended. Add at least the Main Update Repository, because it makes sure the system is installed with the latest security patches.

You have the following choices:

Confirm your selection with Next. Depending on your choice, you need to confirm one or more license agreements. Do so by choosing Next until you proceed to the System Role screen. Now choose Next to proceed.

Choose a general software and system configuration with this step by selecting a desktop or server configuration.

For a desktop installation, choose between Desktop with KDE Plasma, Desktop with GNOME, Desktop with Xfce or Generic Desktop. KDE and Xfce are somewhat similar to Windows. GNOME offers an alternative, innovative environment. If you prefer an alternative to the KDE, GNOME, or Xfce desktops, choose Generic Desktop. You will be able to choose between the LXDE, MATE and others later in the installation process by selecting Software in the Installation Settings dialog.

If you are setting up a server, you probably do not need a graphical user interface. Choose Server (Text Mode) in this case. Alternatively, set up a server system with a read-only root partition and transactional updates by choosing Transactional Server. This selection also is a prerequisite for setting up openSUSE Kubic. See https://kubic.opensuse.org/blog/2018-04-04-transactionalupdates/ for more information on transactional updates.

You can also manually choose the software configuration for your system. Select Custom and then Next to get to the Software Selection and System Tasks dialog. Choose one or more patterns for installation. By clicking Details, you can select individual packages.

Tip: Release notes

From this point on, the Release Notes can be viewed from any screen during the installation process by selecting Release Notes.

Define a partition setup for openSUSE Leap in this step. Review the partition setup proposed by the system. If necessary, change it. You have the following options:

Note: Separate home partition

The default proposal no longer suggests to create a separate partition for /home. The /home directory contains the user's data and personal configuration files. Placing it on a separate directory makes it easier to rebuild the system in the future, or allows to share it with different Linux installations on the same machine.

In case you want to change the proposal to create a separate partition for /home, choose Guided Setup and click Next until you reach the Filesystem Options screen. Check Propose Separate Home Partition. By default it will be formatted with XFS, but you can choose to use a different file system. Close the dialog by clicking Next again.

To accept the proposed setup without any changes, choose Next to proceed.

Select the clock and time zone to use in your system. To manually adjust the time or to configure an NTP server for time synchronization, choose Other Settings. See Section 3.8, “Clock and time zone” for detailed information. Proceed with Next.

To create a local user, type the first and last name in the User’s Full Name field, the login name in the Username field, and the password in the Password field.

The password should be at least eight characters long and should contain both uppercase and lowercase letters and numbers. The maximum length for passwords is 72 characters, and passwords are case-sensitive.

For security reasons it is also strongly recommended not to enable the Automatic Login. You should also not Use this Password for the System Administrator but rather provide a separate root password in the next installation step.

If you install on a system where a previous Linux installation was found, you may Import User Data from a Previous Installation. Click Choose User for a list of available user accounts. Select one or more user.

In an environment where users are centrally managed (for example by NIS or LDAP) you may want to skip the creation of local users. Select Skip User Creation in this case.

Proceed with Next.

Provide a password for the system administrator account (called the root user).

You should never forget the root password! After you entered it here, the password cannot be retrieved. See Section 3.10, “Authentication for the system administrator root” for more information. Proceed with Next.

Tip: Passwords and keyboard layout

It is recommended to only use US ASCII characters. In case of a system error or when you need to start your system in rescue mode, the keyboard may not be localized.

In case you would like to enable password-less authentication via SSH login, you can import a key via Import Public SSH Key. If you want to completely disable root login via password, upload a key only and do not provide a root password. A login as system administrator will only be possible via SSH using the respective keyin this case.

Use the Installation Settings screen to review and—if necessary—change several proposed installation settings. The current configuration is listed for each setting. To change it, click the headline. Some settings, such as firewall or SSH can directly be changed by clicking the respective links.

Important: Remote access

Changes you can make here, can also be made later at any time from the installed system. However, if you need remote access directly after the installation, you have to adjust the Security settings.

After you have finalized the system configuration on the Installation Settings screen, click Install. Depending on your software selection you may need to agree to license agreements before the installation confirmation screen pops up. Up to this point no changes have been made to your system. After you click Install a second time, the installation process starts.

During the installation, the progress is shown in detail on the Details tab. The openSUSE Leap Release Notes tab shows important information; reading them is recommended.

After the installation routine has finished, the computer is rebooted into the installed system. Log in and start YaST to fine-tune the system. If you are not using a graphical desktop or are working from remote, refer to Book “Reference”, Chapter 1 “YaST in text mode” for information on using YaST from a terminal.

The boot screen displays several options for the installation procedure. Boot from Hard Disk boots the installed system and is selected by default, because the CD is often left in the drive. Select one of the other options with the arrow keys and press Enter to boot it. The relevant options are:

Figure 2.1: The boot screen on machines with a traditional BIOS #

  

Use the function keys shown at the bottom of the screen to change the language, screen resolution, installation source or to add an additional driver from your hardware vendor:

UEFI (Unified Extensible Firmware Interface) is a new industry standard which replaces and extends the traditional BIOS. The latest UEFI implementations contain the “Secure Boot” extension, which prevents booting malicious code by only allowing signed boot loaders to be executed.

The boot manager GRUB 2, used to boot machines with a traditional BIOS, does not support UEFI, therefore GRUB 2 is replaced with GRUB 2 for EFI. If Secure Boot is enabled, YaST will automatically select GRUB 2 for EFI for installation. From an administrative and user perspective, both boot manager implementations behave the same and are called GRUB 2 in the following.

Tip: Using additional drivers with Secure Boot

When installing with Secure Boot enabled, you cannot load drivers that are not shipped with openSUSE Leap. This is also true of drivers shipped via SolidDriver, because their signing key is not trusted by default.

To load drivers not shipped with openSUSE Leap, do either of the following:

• Before the installation, add the needed keys to the firmware database via firmware/system management tools.

• Use a bootable ISO that will enroll the needed keys in the MOK list on the first boot.

The boot screen displays several options for the installation procedure. Change the selected option with the arrow keys and press Enter to boot it. The relevant options are:

Figure 2.2: The boot screen on machines with UEFI #

  

GRUB 2 for EFI on openSUSE Leap does not support a boot prompt or function keys for adding boot parameters. By default, the installation will be started with American English and the boot media as the installation source. A DHCP lookup will be performed to configure the network. To change these defaults or to add boot parameters you need to edit the respective boot entry. Highlight it using the arrow keys and press E. See the on-screen help for editing hints (note that only an English keyboard is available now). The Installation entry will look similar to the following:

setparams 'Installation'

   set gfxpayload=keep
   echo 'Loading kernel ...'
   linuxefi /boot/x86_64/loader/linux splash=silent
   echo 'Loading initial ramdisk ...'
   initrdefi /boot/x86_64/loader/initrd

Add space-separated parameters to the end of the line starting with linuxefi. To boot the edited entry, press F10. If you access the machine via serial console, press Esc–0. A complete list of parameters is available at https://en.opensuse.org/Linuxrc.

Important: Configuring the network interface

The settings discussed in this section apply only to the network interface used during installation.

The network will only be configured if it is required during the installation. To force the network to be configured, use the netsetup or ifcfg parameters.

If you are not using DVD or USB flash drive for installation, specify an alternative installation source.

Only one of the different remote control methods should be specified at a time. The different methods are: SSH, VNC, remote X server.

By default you can only assign IPv4 network addresses to your machine. To enable IPv6 during installation, enter one of the following parameters at the boot prompt:

In networks enforcing the usage of a proxy server for accessing remote web sites, registration during installation is only possible when configuring a proxy server.

On systems with traditional BIOS, press F4 on the boot screen and set the required parameters in the HTTP Proxy dialog.

On Systems with UEFI BIOS, provide the boot parameter proxy at the boot prompt:

Enabling SELinux upon installation start-up enables you to configure it after the installation has been finished without having to reboot. Use the following parameters:

security=selinux selinux=1

During installation and upgrade, YaST can update itself as described in Section 3.2, “Installer self-update” to solve potential bugs discovered after release. The self_update parameter can be used to modify the behavior of this feature.

To enable the installer self-update, set the parameter to 1:

self_update=1

To use a user-defined repository, specify a URL:

self_update=https://updates.example.com/

If your screen uses a very high DPI, use the boot parameter QT_AUTO_SCREEN_SCALE_FACTOR. This scales font and user interface elements to the screen DPI.

QT_AUTO_SCREEN_SCALE_FACTOR=1

The boot parameter mitigations lets you control mitigation options for side-channel attacks on affected CPUs. Its possible values are:

auto.  Enables all mitigations required for your CPU model, but does not protect against cross-CPU thread attacks. This setting may impact performance to some degree, depending on the workload.

nosmt.  Provides the full set of available security mitigations. Enables all mitigations required for your CPU model. In addition, it disables Simultaneous Multithreading (SMT) to avoid side-channel attacks across multiple CPU threads. This setting may further impact performance, depending on the workload.

off.  Disables all mitigations. Side-channel attacks against your CPU are possible, depending on the CPU model. This setting has no impact on performance.

Each value comes with a set of specific parameters, depending on the CPU architecture, the kernel version, and on the vulnerabilities that need to be mitigated. Refer to the kernel documentation for details.

The process can be broken down into two different parts:

3.2.1.1 Determining the update repository location #

  

Installer Self-Updates are distributed as regular RPM packages via a dedicated repository, so the first step is to find out the repository URL.

Important: Installer self-update repository only

No matter which of the following options you use, only the installer self-update repository URL is expected, for example:

self_update=https://www.example.com/my_installer_updates/

Do not supply any other repository URL—for example the URL of the software update repository.

YaST will try the following sources of information:

1. The self_update boot parameter. (For more details, see Section 2.4.4, “Enabling the installer self-update”.) If you specify a URL, it will take precedence over any other method.

2. The /general/self_update_url profile element in case you are using AutoYaST.

3. If none of the previous attempts worked, the fallback URL (defined in the installation media) will be used.

3.2.1.2 Downloading and applying the updates #

  

When the updates repository is determined, YaST will check whether an update is available. If so, all the updates will be downloaded and applied to the installation system.

Finally, YaST will be restarted to load the new version and the welcome screen will be shown. If no updates were available, the installation will continue without restarting YaST.

Note: Update integrity

Update signatures will be checked to ensure integrity and authorship. If a signature is missing or invalid, you will be asked whether you want to apply the update.

YaST can use a user-defined repository instead of the official repository by specifying a URL through the self_update boot parameter.

Note: Only one repository

Currently, it is not possible to use more than one repository as source for installer self-updates.

Define a partition setup for openSUSE Leap in this step.

Figure 3.4: Suggested partitioning #

  

The installer creates a proposal for one of the available disks containing a root partition formatted with Btrfs and a swap partition. If one or more swap partitions have been detected on the available hard disks, these partitions will be used. You have several options to proceed:

Warning: Disk space units

Note that for partitioning purposes, disk space is measured in binary units, rather than in decimal units. For example, if you enter sizes of 1GB, 1GiB or 1G, they all signify 1 GiB (Gibibyte), as opposed to 1 GB (Gigabyte).

Binary

1 GiB = 1 073 741 824 bytes.

Decimal

1 GB = 1 000 000 000 bytes.

Difference

1 GiB ≈ 1.07 GB.

openSUSE Leap contains several software patterns for various application purposes. The available choice of patterns and packages depends on your selection of modules and extensions.

Click Software to open the Software Selection and System Tasks screen where you can modify the pattern selection according to your needs. Select a pattern from the list and see a description in the right-hand part of the window.

Each pattern contains several software packages needed for specific functions (for example Multimedia or Office software). If you chose Generic Desktop in the System Role dialog choose a desktop environment from the list of available Graphical Environments. For a more detailed selection based on software packages to install, select Details to switch to the YaST Software Manager.

Figure 3.9: Software selection and system tasks #

  

You can also install additional software packages or remove software packages from your system at any later time with the YaST Software Manager. For more information, refer to Chapter 9, Installing or removing software.

By default, openSUSE Leap uses the Wayland display server protocol.

Tip: Adding secondary languages

The language you selected with the first step of the installation will be used as the primary (default) language for the system. You can add secondary languages from within the Software dialog by choosing Details › View › Languages.

The installer proposes a boot configuration for your system. Other operating systems found on your computer, such as Microsoft Windows or other Linux installations, will automatically be detected and added to the boot loader. However, openSUSE Leap will be booted by default. Normally, you can leave these settings unchanged. If you need a custom setup, modify the proposal according to your needs. For information, see Book “Reference”, Chapter 12 “The boot loader GRUB 2”, Section 12.3 “Configuring the boot loader with YaST”.

Important: Software RAID 1

Booting a configuration where /boot resides on a software RAID 1 device is supported, but it requires to install the boot loader into the MBR (Boot Loader Location › Boot from Master Boot Record). Having /boot on software RAID devices with a level other than RAID 1 is not supported.

The CPU Mitigations refer to kernel boot command line parameters for software mitigations that have been deployed to prevent CPU side-channel attacks. Click the selected entry to choose a different option. For details, see Book “Reference”, Chapter 12 “The boot loader GRUB 2” CPU Mitigations.

By default, the Firewall is enabled on all configured network interfaces. To completely disable firewalld, click disable (not recommended).

Note: Firewall settings

When the firewall is activated, all interfaces are assigned to the public zone, where all ports are closed by default, ensuring maximum security. The only port you can open during the installation is port 22 (SSH), to allow remote access. Other services requiring network access (such as FTP, Samba, Web server, etc.) will only work after having adjusted the firewall settings. Refer to Book “Security and Hardening Guide”, Chapter 23 “Masquerading and firewalls” for configuration details.

The SSH service is enabled by default, but its port (22) is closed in the firewall. Click open to open the port or disable to disable the service. Note that if SSH is disabled, remote logins will not be possible. Refer to Book “Security and Hardening Guide”, Chapter 22 “Securing network operations with OpenSSH” for more information.

Tip: Existing SSH host keys

If you install openSUSE Leap on a machine with existing Linux installations, the installation routine imports an SSH host key. It chooses the host key with the most recent access time by default.

If you are performing a remote administration over VNC, you can also specify whether the machine should be accessible via VNC after the installation. Note that enabling VNC also requires you to set the Default systemd Target to graphical.

The default Major Linux Security Module is AppAmpor. To disable it, selese None as module in the Security settings. This allows you to deselect the AppAmor pattern in the Software settings (Section 3.11.1, “Software”).

This category displays the current network settings, as automatically configured after booting into the installation (see Section 3.4) or as manually configured from the Registration or Add-On Product dialog during the respective steps of the installation process. If you want to check or adjust the network settings at this stage (before performing the installation), click Network Configuration. This takes you to the YaST Network Settings module. For details, see Book “Reference”, Chapter 13 “Basic networking”, Section 13.4 “Configuring a network connection with YaST”.

openSUSE Leap can boot into two different targets (formerly known as “runlevels”). The graphical target starts a display manager, whereas the multi-user target starts the command line interface.

The default target is graphical. In case you have not installed the X Window System patterns, you need to change it to multi-user. If the system should be accessible via VNC, you need to choose graphical.

If an existing Linux installation on your computer was detected, YaST will import the most recent SSH host key found in /etc/ssh by default, optionally including other files in the directory as well. This makes it possible to reuse the SSH identity of the existing installation, avoiding the REMOTE HOST IDENTIFICATION HAS CHANGED warning on the first connection. Note that this item is not shown in the installation summary if YaST has not discovered any other installations. You have the following choices:

This screen lists all the hardware information the installer could obtain about your computer. When opened for the first time, the hardware detection is started. Depending on your system, this may take some time. Select any item in the list and click Details to see detailed information about the selected item. Use Save to File to save a detailed list to either the local file system or a removable device.

Advanced users can also change the PCI ID Setup and kernel settings by choosing Kernel Settings. A screen with two tabs opens:

If you use the GNOME desktop environment you can configure Auto Login for a certain user and Passwordless Login for all users. Auto login causes a user to become automatically logged in to the desktop environment on boot. This functionality can only be activated for one user at a time. Login without password allows all users to log in to the system after they have entered their user name in the login manager.

Warning: Security risk

Enabling Auto Login or Passwordless Login on a machine that can be accessed by more than one person is a security risk. Without the need to authenticate, any user can gain access to your system and your data. If your system contains confidential data, do not use this functionality.

To activate auto login or login without password, access these functions in the YaST User and Group Administration with Expert Options › Login Settings.

On any system with multiple users, it is a good idea to enforce at least basic password security policies. Users should change their passwords regularly and use strong passwords that cannot easily be exploited. For local users, proceed as follows:

To prevent system capacities from being exhausted without notification, system administrators can set up quotas for users or groups. Quotas can be defined for one or more file systems and restrict the amount of disk space that can be used and the number of inodes (index nodes) that can be created there. Inodes are data structures on a file system that store basic information about a regular file, directory, or other file system object. They store all attributes of a file system object (like user and group ownership, read, write, or execute permissions), except file name and contents.

openSUSE Leap allows usage of soft and hard quotas. Additionally, grace intervals can be defined that allow users or groups to temporarily violate their quotas by certain amounts.

openSUSE Leap also ships command line tools like repquota or warnquota. System administrators can use these tools to control the disk usage or send e-mail notifications to users exceeding their quota. Using quota_nld, administrators can also forward kernel messages about exceeded quotas to D-BUS. For more information, refer to the repquota, the warnquota and the quota_nld man page.

YaST has two different language categories:

Before installing additional languages, determine which of them should be the default system language (primary language).

To access the YaST language module, start YaST and click System › Language. Alternatively, start the Languages dialog directly by running sudo yast2 language & from a command line.

The system is now multilingual. However, to start an application in a language other than the primary one, you need to set the desired language explicitly as explained in Section 6.1.3, “Switching languages for standard X and GNOME applications”.

To globally change the default language of a system, use the following procedure:

After you have installed the respective language with YaST, you can run a single application in another language.

Start the application from the command line by using the following command:

LANG=LANGUAGE application

For example, to start f-spot in German, run LANG=de_DE f-spot. For other languages, use the appropriate language code. Get a list of all language codes available with the locale  -av command.

After completing a default installation of openSUSE Leap, firewalld is active and the network interfaces are configured to be in the public zone, which blocks incoming traffic.

When firewalld is active, you may need to configure it to allow clients to browse network printers by allowing mdns and ipp through the internal network zone. The public zone should never expose printer queues.

(More information about the firewalld configuration is available in Book “Security and Hardening Guide”, Chapter 23 “Masquerading and firewalls”, Section 23.4 “firewalld” and at https://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings.)

CUPS servers regularly announce the availability and status information of shared printers over the network. Clients can access this information to display a list of available printers in printing dialogs, for example. This is called “browsing”.

CUPS servers announce their print queues over the network either via the traditional CUPS browsing protocol, or via Bonjour/DNS-SD. To enable browsing network print queues, the service cups-browsed needs to run on all clients that print via CUPS servers. cups-browsed is not started by default. To start it for the active session, use sudo systemctl start cups-browsed. To ensure it is automatically started after booting, enable it with sudo systemctl enable cups-browsed on all clients.

In case browsing does not work after having started cups-browsed, the CUPS server(s) probably announce the network print queues via Bonjour/DNS-SD. In this case you need to additionally install the package avahi and start the associated service with sudo systemctl start avahi-daemon on all clients.

See Section 7.7.1, “CUPS and firewall” for information on allowing printer browsing through firewalld.

The YaST printer configuration sets up the queues for CUPS using the PPD files installed in /usr/share/cups/model. To find the suitable PPD files for the printer model, YaST compares the vendor and model determined during hardware detection with the vendors and models in all PPD files. For this purpose, the YaST printer configuration generates a database from the vendor and model information extracted from the PPD files.

The configuration using only PPD files and no other information sources has the advantage that the PPD files in /usr/share/cups/model can be modified freely. For example, if you have PostScript printers the PPD files can be copied directly to /usr/share/cups/model (if they do not already exist in the manufacturer-PPDs or OpenPrintingPPDs-postscript packages) to achieve an optimum configuration for your printers.

Additional PPD files are provided by the following packages:

These printers do not support any common printer language and can only be addressed with special proprietary control sequences. Therefore they can only work with the operating system versions for which the manufacturer delivers a driver. GDI is a programming interface developed by Microsoft* for graphics devices. Usually the manufacturer delivers drivers only for Windows, and since the Windows driver uses the GDI interface these printers are also called GDI printers. The actual problem is not the programming interface, but that these printers can only be addressed with the proprietary printer language of the respective printer model.

Some GDI printers can be switched to operate either in GDI mode or in one of the standard printer languages. See the manual of the printer whether this is possible. Some models require special Windows software to do the switch (note that the Windows printer driver may always switch the printer back into GDI mode when printing from Windows). For other GDI printers there are extension modules for a standard printer language available.

Some manufacturers provide proprietary drivers for their printers. The disadvantage of proprietary printer drivers is that there is no guarantee that these work with the installed print system or that they are suitable for the various hardware platforms. In contrast, printers that support a standard printer language do not depend on a special print system version or a special hardware platform.

Instead of spending time trying to make a proprietary Linux driver work, it may be more cost-effective to purchase a printer which supports a standard printer language (preferably PostScript). This would solve the driver problem once and for all, eliminating the need to install and configure special driver software and obtain driver updates that may be required because of new developments in the print system.

If the manufacturer-PPDs or OpenPrintingPPDs-postscript packages do not contain a suitable PPD file for a PostScript printer, it should be possible to use the PPD file from the driver CD of the printer manufacturer or download a suitable PPD file from the Web page of the printer manufacturer.

If the PPD file is provided as a zip archive (.zip) or a self-extracting zip archive (.exe), unpack it with unzip. First, review the license terms of the PPD file. Then use the cupstestppd utility to check if the PPD file complies with “Adobe PostScript Printer Description File Format Specification, version 4.3.” If the utility returns “FAIL,” the errors in the PPD files are serious and are likely to cause major problems. The problem spots reported by cupstestppd should be eliminated. If necessary, ask the printer manufacturer for a suitable PPD file.

For the print system, the print job is completed when the CUPS back-end completes the data transfer to the recipient (printer). If further processing on the recipient fails (for example, if the printer is not able to print the printer-specific data) the print system does not notice this. If the printer cannot print the printer-specific data, select a PPD file that is more suitable for the printer.

If the data transfer to the recipient fails entirely after several attempts, the CUPS back-end, such as USB or socket, reports an error to the print system (to cupsd). The back-end determines how many unsuccessful attempts are appropriate until the data transfer is reported as impossible. As further attempts would be in vain, cupsd disables printing for the respective queue. After eliminating the cause of the problem, the system administrator must re-enable printing with the command cupsenable.

If a CUPS network server broadcasts its queues to the client hosts via browsing and a suitable local cupsd is active on the client hosts, the client cupsd accepts print jobs from applications and forwards them to the cupsd on the server. When cupsd on the server accepts a print job, it is assigned a new job number. Therefore, the job number on the client host is different from the job number on the server. As a print job is usually forwarded immediately, it cannot be deleted with the job number on the client host This is because the client cupsd regards the print job as completed when it has been forwarded to the server cupsd.

To delete the print job on the server, use a command such as lpstat -h cups.example.com -o to determine the job number on the server. This assumes that the server has not already completed the print job (that is, sent it completely to the printer). Use the obtained job number to delete the print job on the server as follows:

> cancel -h cups.example.com QUEUE-JOBNUMBER

If you switch the printer off or shut down the computer during the printing process, print jobs remain in the queue. Printing resumes when the computer (or the printer) is switched back on. Defective print jobs must be removed from the queue with cancel.

If a print job is corrupted or an error occurs in the communication between the host and the printer, the printer cannot process the data correctly and prints numerous sheets of paper with unintelligible characters. To fix the problem, follow these steps:

Use the following generic procedure to locate problems in CUPS:

In-depth information about printing on openSUSE Leap is presented in the openSUSE Support Database at https://en.opensuse.org/Portal:Printing.

The YaST software manager can install packages or patterns from all currently enabled repositories. It offers different views and filters to make it easier to find the software you are searching for. The Search view is the default view of the window. To change view, click View and select one of the following entries from the drop-down box. The selected view opens in a new tab.

Tip: Finding packages not belonging to an active repository

To list all packages that do not belong to an active repository, choose View › Repositories › @System and then choose Secondary Filter › Unmaintained Packages. This is useful, for example, if you have deleted a repository and want to make sure no packages from that repository remain installed.

Certain packages are dependent on other packages, such as shared libraries. On the other hand, some packages cannot coexist with others on the system. If possible, YaST automatically resolves these dependencies or conflicts. If your choice results in a dependency conflict that cannot be automatically solved, you need to solve it manually as described in Section 9.2.4, “Package dependencies”.

Note: Removal of packages

When removing any packages, by default YaST only removes the selected packages. If you want YaST to also remove any other packages that become unneeded after removal of the specified package, select Options › Cleanup when deleting packages from the main menu.

Note: Installing source packages

Installing source packages with YaST Software Manager is not possible at the moment. Use the command line tool zypper for this purpose. For more information, see Book “Reference”, Chapter 2 “Managing software with command line tools”, Section 2.1.3.5 “Installing or downloading source packages”.

Instead of updating individual packages, you can also update all installed packages or all packages from a certain repository. When mass updating packages, the following aspects are generally considered:

Which of the aspects has the highest importance for choosing the update candidates depends on the respective update option you choose.

Most packages are dependent on other packages. If a package, for example, uses a shared library, it is dependent on the package providing this library. On the other hand, some packages cannot coexist, causing a conflict (for example, you can only install one mail transfer agent: sendmail or postfix). When installing or removing software, the Software Manager makes sure no dependencies or conflicts remain unsolved to ensure system integrity.

In case there exists only one solution to resolve a dependency or a conflict, it is resolved automatically. Multiple solutions always cause a conflict which needs to be resolved manually. If solving a conflict involves a vendor or architecture change, it also needs to be solved manually. When clicking Accept to apply any changes in the Software Manager, you get an overview of all actions triggered by the automatic resolver which you need to confirm.

By default, dependencies are automatically checked. A check is performed every time you change a package status (for example, by marking a package for installation or removal). This is generally useful, but can become exhausting when manually resolving a dependency conflict. To disable this function, go to the main menu and deactivate Dependencies › Autocheck. Manually perform a dependency check with Dependencies › Check Now. A consistency check is always performed when you confirm your selection with Accept.

To review a package's dependencies, right-click it and choose Show Solver Information. A map showing the dependencies opens. Packages that are already installed are displayed in a green frame.

Note: Manually solving package conflicts

Unless you are very experienced, follow the suggestions YaST makes when handling package conflicts, otherwise you may not be able to resolve them. Keep in mind that every change you make potentially triggers other conflicts, so you can easily end up with a steadily increasing number of conflicts. In case this happens, Cancel the Software Manager, Abandon all your changes and start again.

Figure 9.1: Conflict management of the software manager #

  

In addition to the hard dependencies required to run a program (for example a certain library), a package can also have weak dependencies, which add for example extra functionality or translations. These weak dependencies are called package recommendations.

When installing a new package, recommended packages are still installed by default. When updating an existing package, missing recommendations will not be installed automatically. To change this, set PKGMGR_RECOMMENDED="yes" in /etc/sysconfig/yast2. To install all missing recommendations for already installed packages, start YaST › Software Manager and choose Extras › Install All Matching Recommended Packages.

To disable the installation of recommended packages when installing new packages, deactivate Dependencies › Install Recommended Packages in the YaST Software Manager. When using the command-line tool Zypper to install packages, use the option --no-recommends.

You can either add repositories from DVD/CD, a USB flash drive, a local directory, an ISO image, or a network source.

To add repositories from the Configured Software Repositories dialog in YaST proceed as follows:

The Configured Software Repositories overview of the Software Repositories lets you change the following repository properties:

To ensure their integrity, software repositories can be signed with the GPG Key of the repository maintainer. Whenever you add a new repository, YaST offers to import its key. Verify it as you would do with any other GPG key and make sure it does not change. If you detect a key change, something might be wrong with the repository. Disable the repository as an installation source until you know the cause of the key change.

To manage all imported keys, click GPG Keys in the Configured Software Repositories dialog. Select an entry with the mouse to show the key properties at the bottom of the window. Add, Edit, or Delete keys with a click on the respective buttons.

Before upgrading, copy the old configuration files to a separate medium (such as removable hard disk or USB flash drive) to secure the data. This primarily applies to files stored in /etc as well as some of the directories and files in /var. You may also want to write the user data in /home (the HOME directories) to a backup medium. Back up this data as root. Only root has read permission for all local files.

Before starting your update, make note of the root partition. The command df / lists the device name of the root partition. In Example 12.1, “List with df -h”, the root partition to write down is /dev/sda3 (mounted as /).

Filesystem     Size  Used Avail Use% Mounted on
/dev/sda3       74G   22G   53G  29% /
udev           252M  124K  252M   1% /dev
/dev/sda5      116G  5.8G  111G   5% /home
/dev/sda1       39G  1.6G   37G   4% /windows/C
/dev/sda2      4.6G  2.6G  2.1G  57% /windows/D

If you upgrade a default system from the previous version to this version, YaST works out the necessary changes and performs them. Depending on your customization, some steps (or the entire upgrade procedure) may fail and you must resort to copying back your backup data. Check the following issues before starting the system update.