Showing posts with label SparkyLinux. Show all posts
Showing posts with label SparkyLinux. Show all posts

2020-02-19

Kwort Linux 4.3.4 review

In my endeavor to revisit lightweight Linux distributions I looked back on my old dream to try CRUX Linux distribution. Since my last attempt ended up in failure, I decided to look if there were any CRUX-based distributions around with the simplified installation process. With the help of DistroWatch.com filter I found that only two CRUX-based distributions existed. Between two of them, the Kwort Linux seemed like the one I may have been looking for. There were few uncertainties though:
  • It wasn't clear if I would also need to build kernel during installation process similar to CRUX distribution.
  • At that time the project homepage was down despite its relative recent release (2019-06-16), casting doubts if it will be maintained in the future.
  • I wasn't sure how distribution's kpkg package manager operates, and if it is still maintained. Finally, I didn't know if I would be able to use CRUX ports system alongside with it. I believe together with BSD style init system it makes an essence of CRUX Linux and support for it was one of requirements to CRUX based distribution as well.
Nevertheless, I downloaded the ISO image from linuxtracker.org with the intention to try it out on my VIA EPIA-M900 motherboard later on. The ISO image is around ~917 MB in size. Fortunately, before my attempt, the homepage was partially restored with the documentation available in github (by the time I finished an article, the homepage is fully recovered and updated). It provided answers to some of those uncertainties except maintainability prospects of this small distribution. CRUX ports appeared to be supported to a certain extent, installation process didn't require to recompile the kernel as well. Furthermore, I also checked that kpkg mirrors were still updated regularly. All those factors combined gave a decent reason to try Kwort Linux.

The Kwort Linux did not have a "real" installer so to speak. Once booted, it automatically logins into console and gives a long message on the installation process. It can be always reprinted using "helpinstall" command. All the steps are manual: 1) first step is to partition the hard drive using one of fdisk/cfdisk (for MBR) or gdisk/cgdisk (for GPT) utilities. In my case I didn't need to partition hard drive since I just reused partitions used by previously installed SparkyLinux. 2) format partitions using mkfs. command; 3) mount those partitions to /mnt/install/ for root and /mnt/install/ for other partitions (if any); 4) run pkgsinstall command to install base packages; 5) use jumpOS command to chroot to your newly installed system; 6) finally configure your system by editing /etc/fstab, /etc/rc.conf (vim editor was available), creating users and installing bootloader (lilo or grub2 options are available). After all these steps, system installation is finished and computer can be rebooted.

In my case everything went smoothly and the newly installed system booted successfully. By default, kpkg package manager doesn't have any repositories, so the first command requires to install one. europa.kdb is available after installation and can be installed using kpkg instkdb /root/europa.kdb command. Alternative ctrl-c.kdb mirror was available here. After that, package manager is pretty simple to use kpkg update && kpkg upgrade will upgrade the system. Unfortunately, the package manager doesn't handle dependency management, thus, issues appeared right after the first upgrade. Several applications were failing to start citing missing library files. In all cases, I solved it by reinstalling those libraries. However, the challenge was to find the right package, as at times, few libraries were needed to be reinstalled before application started to work again. Another issue is that kpkg is pretty limited. During the time of writing this article, it had 203 packages only.

To partially circumvent missing packages, CRUX ports can be used. To achieve that, initially you need to install packages from CD image kpkg install /mnt/cdrom/packages_more/ports/*.tar.gz. After that, just refer to CRUX ports documentation. Unfortunately, not everything successfully compiled too and during kpkg upgrade, packages may interfere if versions doesn't match. Nevertheless, I successfully used ports system to install some applications unavailable in kpkg package manager mirrors (like wget). As a last resort, I compiled some packages manually from original repositories (like openchrome video driver).

To run Xorg you just need to run startx command. It did not seem that there's any display manager available as well. The default window manager is Openbox combine with conky and tint2. There are some distribution specific shortcuts like alt+z to lunch urxvt or alt+x to launch the browser. Actually, no alternative to Openbox was available in kpkg, though ports system provided some.

Probably, the final point is that though the kernel binary was provided during installation, no kernel updates are available. So, in order to update it, compiling manually is necessary. The installer provides 4.19.46 version in the ISO image. I successfully updated to 4.19.88 soon after installation.

In conclusion, I can say that Kwort is a really different distribution compared to the mainstream. It requires more manual work and research but in turn it gives one of the leanest systems available, fast boot process and complete control in your hands. It is suitable mainly for the experienced Linux user or the person who is not afraid to tinker with his/her system. It can be a perfect distribution for your secondary PCs, testing and rescue purposes or on dual boot as well. For desktop usage, one should have quite minimal requirements, since running typical heavy weight applications or games may be a challenging task. Here there is a nice response from a distribution creator and developer, along with its features and goals. It also has an IRC channel on OFTC network where you can reach him directly.
Default Kwort Linux 4.3.4 desktop

2018-01-06

Linux on Jetway JNF76-N1G-LF in 2017

Back in 2009 I bought the Jetway JNF76 motherboard including ADPE4S-PB daughterboard (4xSATA II marvell controller) for their proprietary connection (Jetway Daughter Board Connector Gen 1). The motherboard was equipped with VIA Nano U2300 1GHz CPU and VX800 chipset. Eventually it replaced another board VIA VT-310DP as my main NAS (network attached storage) server. During that time it took me quite a while to find a properly working setup. I tried all BSDs and some Linux distributions, until I was forced to switch from my initial NetBSD 5.0 setup to Debian Linux 5. Refer to my previous articles by clicking here, here and here. Finally some outstanding issues were resolved during my transition to Debian 6 in 2011. Debian Linux setup worked for around 5 years in my server till my OS installation containing flash drive died. Few weeks ago I decided to revive the system but using a different lighter Linux distribution. The folowing points I listed were the issues I encountered during the time I was using Debian.
  • Debian Linux required additional configuration for drives connected to ADPE4S-PB controller to be recognized (adding ahci.marvell_enable=1 to some file in /etc/modprobe.d/). I was wondering if it is still the case today.
  • A06.1 BIOS version wasn't compatible with any Linux distribution I've tried at that time (boot process was hanging up before any boot messages were available on the screen), only falling back to A05 version was solving the issue.
  • IDE mode was needed to be used for native VX800 SATA controller for ADPE4S-PB daughterboard to initialize during PC boot process (BIOS issue).
  • Graphical install was working during that time.
During this endeavor I have tried to install the following Linux distributions:
I also tested live images of these distributions:

A06.1 Linux issue 

The board reached EOL long ago however I was still expecting some BIOS upgrades after A06.1 version in 2010. Since then I was communicating with Jetway extensively regarding Linux boot issue (I've tried around 5 major distributions at that time, all of them failed to boot), however their answers didn't help me reach any conclusion. Eventually I just downgraded BIOS back to A05. Unfortunately, visiting their current page showed that A06.1 version is the last upgrade for this board, and no more upgrades can be expected. Out of curiosity I updated BIOS again and I can confirm that during the time I was writing this article, Linux boots unless no USB devices are attached, otherwise system crashes with "Fatal exception in interrupt" message. If you attach USB device after system is loaded, it will work but Linux still can crash at any given with the same error (in my case during system upgrade process). It is  improvement over immediate crash without boot log messages but hardly justifies BIOS upgrade. On the other hand, BIOS release notes stated that it fixed the 2TB hard drive detection issue however I didn't have any problems with >2TB drives on A05 BIOS anyway (over the time I used at least three or four different models from Hitachi, Seagate, Toshiba and possibly WD). I would personally recommend to upgrade the latest BIOS version only if necessary.

LXLE and SparkyLinux

My initial goal was to use CRUX distribution for the NAS server. It didn't have a live image and its installation image was pretty primitive, thus it lead me to search for a light Linux distribution which had live image for initial testing. SparkyLinux and LXLE were the ones which caught my attention because they both used light window managers by default (OpenBox, LXDE). The former is based on testing Debian branch, while the latter on Ubuntu. Unfortunately, it appeared that graphics-based installation failed on both, which meant LXLE was not useful for my needs. Therefore, since SparkyLinux had a console-based boot support then it proved to be a quite good "rescue" type distribution. It is important to note that hard drives attached to ADPE4S-PB daughterboard weren't recognized on SparkyLinux otherwise it worked OK on the system and provided enough tools for my testing needs.

CRUX Linux

I was really hoping to finally grasp this quite unique Linux distribution which uses BSD style unit scripts and ports style package management. Why? Mainly because among all other Linux distributions CRUX has the features closest to BSD since I am more a BSD person than a Linux one. 

Initially setup image boot failed which was caused by an aspm (Active-State Power Management for PCI-E) issue. The solution was to add pcie_aspm=off parameter on every boot (just write CRUX pcie_aspm=off in boot console). Apparently other Linux distributions do that automatically depending on detected PCI-E version (noticed that in boot logs). CRUX installation is similar but even more primitive than NetBSD or OpenBSD. You need to partition disks manually using fdisk, manually edit fstab, hosts and other required configuration. Eventually you run setup script on mounted root partition (to /mnt) which copies system files to a required location. Then you chroot to your system root partition (setup_chroot), compile your own kernel and install bootloader (lilo is default but I used grub2). This Linux distribution doesn't have initial RAM disk (initrd) by default so all drivers must be compiled into the kernel. This condition eventually became my brick wall. I just couldn't find the combination which could boot the system. Even if partitions and hard drives were visible in boot log during boot process (both attached to native VX800 controller or daughterboard one) it was ending up with "VFS: Unable to mount root fs" error. After a week of recompiling different kernel configurations I decided to give up on CRUX.

antiX Linux

Based on the problems I encountered previously, I looked around for faster solution and stumbled upon Antix Linux which was systemd free Debian based system and supported console based installation. Installation went pretty smoothly but I could not resolve an issue for drives attached to an ADPE4S-PB daughterboard. It is based on Marvell 88SE6145-TFE1 controller and similar to my installation back in 2009 it still required disabling marvell pata driver in most Linux distributions manually. I just couldn't find ways on how to do this in antiX but I didn't want to spend more time in searching for answers from forums (I couldn't find the information I needed from old discussions thus getting it would mean starting a new thread). For this reason I just decided to switch again.

Manjaro Linux

There were three reasons why I wanted to try Manjaro Linux:
  1. I use Manjaro as my main distribution on my desktop system from the end of 2013 to present, and I am familiar with it pretty well by now. 
  2. It is based on Arch which had a good description on how to solve marvell SATA issue from their forums
  3. Manjaro has a console-based Manjaro-Architect edition which gave me hope to run it successfully on the system.
Unfortunately though, the boot process ended up with a message in my monitor showing "Sync. Out of range", and I couldn't find a quick solution to that. Therefore, Manjaro failed as well, which made me decide to try Arch Linux.

Arch Linux

Arch Linux had a console-based installation and required internet access (at least the image I used). It had a couple of helpful utilities which generated files, like fstab, compared to manual editing which can be found on CRUX, although partition management is still manual using fdisk or cfdisk. Installation went pretty smoothly according to Arch Linux documentation. I won't go into details because this article is not about Arch Linux installation process, but I will describe specific changes that I had made to configuration for my particular setup. Initially, I replaced filesystem references from /dev/sd* to partition UUIDs in fstab file. In addition, I also disabled system beep by adding  /etc/modprobe.d/nobeep.conf file with "blacklist pcspkr" content. Finally I performed changes to enable marvell SATA (for ADPE4S-PB daughterboard to work):
  • Added /etc/moprobe.d/blacklist_pata_marvell.conf
    • blacklist pata_marvell
  • Added /etc/modprobe.d/ahci-enable-marvell.conf
    • options ahci marvell_enable=1
  • Modified /etc/mkinitcpio.conf file
    • MODULES=(ahci)
  • Regenarated initramfs
    • mkinitcpio -g /boot/initramfs-linux.img
The boot disk can now be connected to the daughterboard after the changes in the configuration and system reboot were done.

So far this installation runs OK. Arch Linux is a distribution which is relatively less troublesome to install and fully utilizes my hardware.

Conclusions

  • IDE mode is still required for native controller in BIOS if you want to use ADPE4S-PB daughterboard (including the latest A06.1 BIOS version). LAN boot ROM can be enabled though.
  • Additional configuration is still necessary for Linux to see drives attached to ADPE4S-PB daughterboard. More specifically marvell pata driver needs to be disabled and ahci marvell driver needs to be enabled. It means you can't install OS to drive attached to this daughterboard but it can be reattached to the daughterboard after necessary changes are performed.
  • Linux is booting on A06.1 BIOS version currently but only without USB devices attached, therefore I personally recommend A05 version.
  • It takes hell of a time to find the right distribution and configuration mainly because of SATA daughterboard. If you are not using it, most distributions should work out-of-the-box in case they are using console-based installation. I couldn't boot into CRUX unfortunately but setup image works with pcie_aspi disabled, so probably I just couldn't find the right kernel/system configuration.
  • Arch Linux proved to be the most suitable lightweight distribution to utilize ADPE4S-PB daughterboard.
  • Graphical installation or xserver failed to work on any distro mentioned above (not sure about the reasons, some definitely didn't have openchrome driver but I believe some had. Your experience may be different. Since this particular issue is irrelevant to my setup at the moment, I didn't investigate further. VX800 integrated graphics is supported by openchrome driver, so theoretically it should work with light window managers).