Tag Archives: dvd

Handbrake 1.2.2 packages fix library mismatch in -current

handbrake_logoHandbrake in Slackware-current was broken after a libvpx upgrade. So I had to recompile. Instead I took the opportunity to compile the new release of HandBrake (1.2.2). Read the releasenotes for the 1.2.x series if you are interested. Most notable is that the team switched back from libav to ffmpeg 4.x as the core engine.

Always uncertain whether the GTK+-3 based GUI will compile. This time, I had to patch a function call out of the sourcecode that was introduced in a later version of GTK+3 than we have in Slackware 14.2. But that was relatively easy, all you will miss is a clickable link to the Handbrake homepage in the “About” box I think. Slackware-current is still uptodate as far as GTK+-3 is concerned.

Please use the comments section to share your feedback about the Slackware package and the use of the Handbrake binary. I did not test, one of the reasons being that I do not have a DVD reader. I remember people giving feedback about older releases of Handbrake where DVD ripping had issues.
Note that my ‘handbrake‘ package does not have any external dependencies – unlike the slackbuilds.org version.
Install and run, it’s that simple. Everything you need is compiled statically into the package. The ‘HandBrakeCLI‘ program is the command-line variant, whereas ‘ghb‘ is the GUI variant of HandBrake, also found in the “Multimedia” menu of your desktop environment.

Packages for Slackware 14.2 and -current with AAC audio encoding support can be obtained from my “restricted” repository:

The variant which does not support AAC audio encoding and therefore does not violate US software patents can be downloaded from the regular repository:

Eric

Slackware Live Edition – Beta 2

blueSW-64pxThanks for all the valuable feedback on the first public beta of my Slackware Live Edition. It allowed me to fix quite a few bugs in the Live scripts (thanks again!), add new functionality (requested by you or from my own TODO) and I took the opportunity to fix the packages in my Plasma 5 repository so that its Live Edition should actually work now.

What is Slackware Live Edition?

If you’re new here: Slackware Live Edition is a “live OS” meaning it does not have to be installed to a harddrive and can run straight off a CDROM or DVD medium, or off a USB stick. Slackware Live Edition is meant to showcase the development of Slackware. Therefore it will boot slackware-current and no other OS. It is meant as an ideal opportunity for people who are curious what two years of Slackware development have resulted in. You do not have to erase your current OS, just copy the ISO to a suitable medium, boot from the medium and check it out. The previous article I wrote explains in more detail why I wanted to write my own Live scripts instead of just using one of the available solutions.

What’s with these three ISO’s?

Slackware Live Edition comes in three flavors (for now). There’s a 700 MB slimmed-down XFCE version with XDM as the graphical login manager; then there is the actual complete Slackware-current with KDE4 and using KDM as the graphical login manager (2.6 GB in size); and finally you can download a 3.0 GB ISO image of Slackware-current with Plasma 5 and the SDDM graphical login manager. The Plasma 5 edition has some cool extras like vlc, libreoffice, calibre, qbittorrent ffmpeg, chromium, openjdk, veracrypt… and more from my own repository.

slackwarelive_syslinux_beta2

How do I use the ISO?

The ISO can be burnt to a DVD (XFCE version will fit on CDROM even) or copied to USB stick. Since the ISOs are ‘hybrid’ just copying to the USB device using ‘dd’ or ‘cp’ will get you a fully functional bootable medium, albeit without persistence (it’s still technically a read-only CDROM filesystem that you’ve copied to the USB stick). The OS will not be bothered by this, because it thinks it can write to the filesystem. That is the trick of a Live OS – all these write operations are done to a RAM based filesystem. The changes are gone once you reboot.

But when using the ‘iso2usb.sh‘ script you can create a real Live OS on the USB device with persistence, meaning that the things you change will be preserved across reboots. All your modifications will be stored in the directory “persistency” in the root of the USB device. Therefore you are actually able to use the USB stick as your pocket-OS on the go:

# ./iso2usb.sh -i ~/Download/slackware64-live-current.iso -o /dev/sdX

… where /dev/sdX is the device name of your USB stick. Don’t worry about accidentally overwriting the content of your hard drive – the script will first show you details about the sdX device and wants your confirmation that this is actually the device you want to reformat.

When you boot Slackware Live you will be presented with a Syslinux boot menu:

  • Start (SLACKWARE | PLASMA5 | XFCE) Live (depending on which of the three ISOs you boot)
  • Non-US Keyboard selection
  • Non-US Language selection
  • Memory test with memtest86+

The first entry boots you straight into the Live OS, using US keyboard mapping and a “en_US.utf8” locale. If you have a non-US keyboard layout and/or want your Linux to show itself in a non-US Language, you can use the second and third menu entries to configure one of the languages I selected ( I picked what I thought were the most commonly used). If your language or keyboard is not listed, just hit the <TAB> key and change the values for the “kbd” and “locale” parameters. Likewise for the timezone parameter which by default is associated with your choice of language.

The memtest option was copied from the Slackware installer – it allows you to test your RAM sticks for hardware errors very thoroughly.

More parameters

The syslinux boot menu allows you to modify the boot command line. Press <TAB> to edit the command line. You will see several parameters you can edit but you can also add more. The <F2> key will show a couple of those.

  • 0|1|2|3|4|5|6|S|s|single (Select another runlevel to start with; the default is  4 for graphical login)
  • lang=nl_NL kbd=nl tz=Europe/Amsterdam (Example of language, keyboard and/or timezone customization)
  • nop (No persistence, i.e. boot the virgin installation)
  • nomodeset (Boot with kernel mode setting for graphics — needed with some machines)
  • load=nvidia (Load and configure binary Nvidia drivers that are present in the ISO)
  • rootdelay=10 (Add 10 second delay to allow proper USB initialization)

But there are some others, and some of these have been added after readers of this blog suggested them:

  • hostname=aliens (Change the hostname for the OS; default hostname is “darkstar“)
  • livepw=”somestring” (Change the password for the ‘live’ user)
  • rootpw=”somestring” (Change the password for the ‘root’ user)
  • load=mod1[,mod2[…]] (load one or more squashfs modules that are present in the directory “/liveslack/optional”; by default none of the modules in the “optional” directory are loaded)
  • noload=mod1[,mod2[…]] (prevent loading of one or more squashfs modules that are present in the directory “/liveslack/addons”; by default all of the modules in the “addons” directory are loaded on boot)
  • rescue (After initialization, you will be dropped in a rescue shell where you can perform lowlevel maintenance; the same happens anyway if the OS fails to boot)
  • swap (Allow the Live OS to activate all swap partitions it finds on the local hardware; by default, the hard drive will not be touched at all)

I get errors and booting fails

Booting an OS off a USB medium is tricky. Linux kernel initializes the storage and the usb subsystems in parallel. If you have a fast computer and slow USB medium or you use a USB-1 / USB-2 port, the probability is pretty high that the USB stick is not yet ready when the OS starts its mount attempts. There’s a parameter you can add to the boot command line to give the USB device some extra time to settle – try adding “rootdelay=10” or even “rootdelay=20” which will add 10 (or 20) seconds pause to the boot process. The iso2usb.sh script configures a default delay of 5 seconds which should be sufficient for most computers.

Instead of “rootdelay” you can use the parameter “waitforroot” with identical result.

Slackware Live does not log me on automatically!

Correct. This is a demonstration environment, with the purpose of getting you acquainted with Slackware, remember?

You already saw all these intimidating kernel messages scrolling across the screen while booting the OS, and now you have two choices for login:

  • user ‘root’ with the password ‘root’ (at least that is the default – you can change it using a boot parameter if you want)
  • user ‘live’ with the password ‘live’ (idem about the default value).

I would suggest using the ‘live’ user account to logon to the Live OS, because KDE 4 and Plasma 5 will not appreciate it when you login as root directly. If you need root access, then just run “sudo -i” or “su -” (both commands will request you to enter the password of user ‘live’, not the root password!).

What’s still on the TODO?

There are a couple of items that I did not get to but they should really be looked into to bring this out of Beta:

  • UEFI boot needs to work (must have)
  • Better documentation about how the scripts work (must have)
  • Documentation on all the boot parameters (must have)
  • Slackware installer as part of the ISO, perhaps even Didier’s polyglot installer (nice to have, only in the Plasma5 version)
  • A ‘copy2ram‘ function to run the OS entirely in RAM (nice to have)
  • Persistence directory inside a loop-mounted ext4 container file, so that the persistent USB stick can have a single FAT partition (nice to have)
  • Homedirectory of a persistent Live OS inside a loop-mounted LUKS-encrypted container file, to protect your private data (nice to have)
  • … tell me more! Or post patches!

Download the ISO images

Show me the source!

Git repository for the scripts can be found here: http://taper.alienbase.nl/cgit/liveslak/

A checkout of the repository can be found in http://www.slackware.com/~alien/liveslak/ and http://taper.alienbase.nl/mirrors/people/alien/liveslak/

Hopefully soon, I will write a proper README which takes you through the inner workings of the scripts. If you are curious you can of course check out the sources – they are full of comments. But there are some design decisions at the core which you need to be aware of before you start on these scripts.

Happy hacking! Eric

Update 25-dec-2015: please continue reading the follow-up article on “Beta 3“.

Update 24-jan-2016: please continue reading and commenting in my follow-up article “Beta 4″.