When things don't work as they used to...

    Once upon a time I did set up a script (something like “yum –assumeno update” but to just filter out package names) on my Fedora machines to automatically send me an report about the updates that need to be applied nightly and since Fedora is an development distribution the emails should be daily (or at least weekly), but for some reason last couple weeks have been rather quiet…

    So digging in the internet a little and what do I found out – Fedora 31 EOL was 24 of November 2020… Another thing that happened on the midst of chaos that the year has been so far… So I have to upgrade several PC’s to the next release… I know Fedora 32 is not the latest version to upgrade to, but I like the stability of being 1 release behind the latest version as it has most likely been fixed from the bugs that sometimes creep into the latest releases. Also I don’t run the latest and greatest hardware so I don’t have the need for the latest kernel drivers so I usually don’t need the bleeding edge software...

    It has been a while since I had to dist upgrade my fedora machines (I usually do it one or twice a year as the EOL time nears, but seems that in the midst of all the chaos that is year 2020 I forgot to do another upgrade cycle until it already was past EOL for some time. Oh well – time to plan one night for downloading a lot of updates… I usually don’t have any issues with upgrades as the process for doing it is pretty much the same as it was 10 years ago. Yes it has gotten simpler and easier in years as the yum/dnf framework has evolved and I think the last mishap of dist upgrade going wrong was with Fedora 19 and that upgrade was long time ago. I just love the simplicity of the process in the midst of things. Windows people would say to that that the system is slow and cluttered and you should re-install windows regularly to keep the clutter and legacy software away, but this is Linux – you don't get all sorts of extra dll’s and who knows what… Yes in time some software is obsoleted and replaced with new, but still… One of the laptops I use regularly has been upgrades since Fedora 7 and now its running 32 and most likely will go to run even newer versions…


    Enough of rambling – the procedure I used to upgrade from F31 to F32 or to do a dist upgrade on my machines is this:

“dnf clean all”

“dnf –releasever=32 update”

“dnf –releasever=32 –downloadonly –skip-broken upgrade“

    This can be done remotely over ssh or from graphical environment and it just cleans out the F31 repository data and downloads the F32 meta-data and packages (I have slow internet so it took a while). I usually don’t have million repositories enabled so I don’t have a lot of package conflicts that need resolving. But now I recommend to switch to the terminal to do the actual upgrade so “Ctrl+Alt+F2” (yes I have done the upgrade over ssh and from the graphical environment, but I have had mishaps where you have 3000 packages upgraded and just when it is time to start uninstalling the previous version packages some script gives an error and the upgrade crashes and you are a left with 7000 installed packages just because some dependency is missing in the graphical environment).

“dnf –releasever=32 --skip-broken upgrade”

    And usually that’s all that is needed to do dist upgrade. Well not this time – this time I was left with packages that have an F32 version available but for some reason would not upgrade and the message was cryptic:


WARNING Modular dependency problems:

Problem 1: conflicting requests

- nothing provides module(platform:f31) needed by module gimp:2.10:3120191106095052:f636be4b-0.x86_64

Problem 2: conflicting requests

- nothing provides module(platform:f31) needed by module libgit2:0.27:3120190407181414:f636be4b-0.x86_64

    So it seems that Gimp and libgit2 need something that was in F31 and is no more in F32… Great… Google was also not particularly helpful as there were bug reports about this message but no real answer. After digging some more I found out that dnf has some new features where packages can have some sort of modules that they require in “/etc/dnf/modules.d/” and well after upgrade the version they were searching was not there any more… Again after some searching that the removal of package was not enough to remove and the only way would be to manually edit each offending module to add “state=disabled” to the file.

    Well… As I don’t have anything that is this module specific I found an easier way:

“dnf module reset '*'”


No more annoying modules :D

And when I now run “dnf upgrade” I end up with

Upgraded:

apache-commons-codec-1.13-2.fc32.noarch apache-commons-io-1:2.6-8.fc32.noarch apache-commons-lang3-3.11-1.fc32.noarch apache-commons-logging-1.2-20.fc32.noarch apache-commons-net-3.6-8.fc32.noarch hawtjni-runtime-1.17-2.fc32.noarch jansi-1.18-3.fc32.noarch jansi-native-1.8-2.fc32.x86_64 jsch-0.1.54-11.fc32.noarch jzlib-1.1.3-12.fc32.noarch slf4j-1.7.30-2.fc32.noarch xalan-j2-2.7.2-2.fc32.noarch xerces-j2-2.12.0-4.fc32.noarch xml-commons-apis-1.4.01-29.fc32.noarch xml-commons-resolver-1.2-29.fc32.noarch

    So… I don’t know why those modules are good for but I don’t need them and resetting them let me to finally upgrade the system…



Until next time I guess...

Installing Linux in 2019

It is January of 2019 Lets see how easy it has become to install Linux on a PC. Does it still require complicated hands on hacking to get it up and running? Well it depends on a flavor you choose, but most of the mainstream distributions wont need more than few clicks and couple of text boxes to fill. I could say that it takes even less of an effort than the first boot of an sysprepped stock windows 10 next, next, next, no, no no, no… setup. So lets see how easy it really is.

To begin with we need an installation media from which we can install the distribution. My go-to flavor for desktop/graphical environment is Fedora (specifically KDE spin) and for servers CentOS . I have used other distributions like Debian, Ubuntu, SUSE Linux Enterprise Server, Oracle Linux and Red Hat Enterprise Linux, but Oracle, SUSE and Red Hat are subscription based services so are less used on services that do not require to be certified on specific distribution. With Debian/Ubuntu… I can use them, but have never mastered the software packaging so I don’t use them much…

So today’s subject is installing basic CentOS machine called bazaar (well I have installed it and it is installed on physical hardware so to get the screenshots I’m just creating an virtual machine under KVM). This will become headless “server” for RPM cache to begin with and possibly acquire some more roles in the future.

So why do I need an rpm cache? Well – I have 4 Fedora machines, 3 CentOS machines and about 40 CentOS VM (no they are not online 24/7 – I boot them up/patch them as needed) for different projects and to play with. I patch them regularly and well my internet connection is not great (12Mbit down/1Mbit up) so when I have to upgrade Fedora 28 to Fedora 29 (which means downloading about 1..2GB of rpm-s for 4 times… taking an hour or two each time… well I’m tiered of waiting). I’m planning to do this upgrade in a week or two so I need an rpm caching server. This is not an issue with Fedora only – CentOS also releases major updates that may be as bit as 1GB (depends on how many packages are installed) and doing it 40 times… well… it takes a lot of time just to download everything again and again.

So how powerful the hardware needs to be? The answer is – I don’t know yet. I had an ASUS Eee Box EB1012P lying around with 4GB RAM, 250GB 2.5’’ WD SATA drive and a gigabit LAN adapter. The CPU is not fast, RAM is not fast, HDD is not fast, but it has 2 core 4 thread 13W TDP CPU. So average power consumption is low - it should stay around 5..20W so it is perfect for 24/7 operation. Yes an SoC like an Raspberry Pi would be more power efficient but I have had bad experience with SD cards dying on heavy IO and I don’t currently have a plan to start making backups of the rpm cache so Eee it is...

To start with I downloaded an CentOS 7 IOS and transferred it to an USB stick. Boot the machine and pressing F8 select the removable media as a boot device. The screen should look like this:

If the Install option is not highlighted then just press the up arrow on the keyboard an select it and press enter. The screen should look similar to this:

It should boot and ask for an language selection:

I like the language to stay English so it is easier to search for problems when they occur but it is up to the administrator to use the language they want. When done click continue and you should be arriving at a screen like this:

I’m hoping, that setting the timezone and keyboard layout is self explanatory so I wont go into that. Also leaving software installation source as local media is recommended (there is possibility to add external repositories, but relying on experience, it is easier to add them after the installation has completed). Since it will become headless “server” minimal install is sufficient.

On a production server I would leave kdump enabled as it will create kernel dumps that can help debug hardware issues, but when creating VM’s for testing I usually disable it as VM’s dont have direct hardware connected to them. I also like to disable the security policy as the policies are not included with CentOS and are available only on official Red Hat Enterprise Linux. This does not mean that CentOS is less secure than RHEL – it just means it is not certified under the example policies. Under network configuration… well it should be self explanatory… I’ll use dhcp in this example, but servers should be configured with static IP.

The hing that needs a little attention is the installation destination:

This VM has a 20GB virtual disk attached to it and since it has no partitions on it it is automatically selected and it should be good enough for basic installation (it is easier to make changes afterwards to change partitioning as it uses LVM by default than try to make a custom partitioning beforehand). So all that is left is click done and then “Begin Installation”. We are on the final stretch…

This should be the screen we are on now. Setting root password is like setting local administrator password in windows. The user root is the superuser that can do anything in the machine so its password should be strong. The user creation tab is optional but recommended as root user should be used only on an emergency's and not for day to day operation.

This screen is similar to setting the root user password with exception of adding username to it AND “Make this user administrator” option. Checking this box grants this use an option to run commands as a root without knowing the root password using "sudo" command. If this is done all that is left to do is wait for the installation to complete and reboot the machine when the option appears.

Now, if everything went well we should be greeted with a boot screen like this:

That means that the installation was successful and we have a brand new Linux machine available.

This should be sufficient for an example on how to install Linux in 2019 and in the near future we’ll configure it.