Multiple bugs and a question

Newbie Corner
,
#1

I've been dabbling with Manjaro on and off for a year, hoping it can replace Mint KDE since Mint is dropping KDE. I've encountered a series of bugs that I'll report just as background and as a potential alert to the community. If someone happens to have fixes or workarounds for the bugs, that would be helpful, but I'm posting them mainly as background for my question.

  1. Update Failures; inability to process massive updates.

A year ago, I downloaded KDE 17.0.2 x86-64 (current at the time), and installed it on a small external hard drive. It's not my primary distro, I just play with it and evaluate it. But I make it a point to regularly update it so it doesn't get too far behind.

The update files slowly filled the drive, until it reached a point where there wasn't sufficient room to download the update files. I uninstalled all of the software I wasn't using and made some more space, but that was only a temporary solution. I had installed Pamac, which allows individually selecting packages to update, and was able to do multiple rounds of updates to get through them. However, the drive was too small and I had to abandon it.

Round 2: a much bigger drive, able to handle all of the updates in one go. I installed the same old version on the new drive, and there was something like 350 odd updates, if I remember right. It was all handled by Octopi. Octopi got lost in its underwear with dozen of package conflicts it couldn't handle, and I couldn't find a way to manually select updates to deal with the problem, it appears to be all or nothing.

So I downloaded the latest release, KDE 17.1.12, figuring there shouldn't be too many updates or update conflicts. After installation, it found almost 140 updates, if I remember right. Again it was unable to process the updates. There was round after round of lists of conflicts, and the choices presented for dealing with the conflicts didn't solve the problem. I gave up after many hours of trying, unsuccessfully, to get Octopi to handle the updates. So bug alert: the latest release has a large number of updates, and it cannot be updated.

  1. The Beta release only boots with the recovery tools.

Since I'm not relying on Manjaro to get my work done, I tried solving the update issue by installing the latest Beta version (KDE 18.0 Beta-6). It still had a surprising number of updates, but it processed them without a problem. So I spent a few hours customizing it, and booted it several times.

After booting several times, the next boot resulted in "Kernel panic - not synching: VFS: Unable to mount root fs on unknown-block (0,0)". In case it's related, this followed installing another Linux distro in a different partition. The only effect that could have had is that the other distro updated GRUB (no other distros on that drive were similarly affected). There was a full screen of related failure data, which I can add if it would be useful. So bug alert: the Beta version is subject to boot failure.

I explored the issue and found that Manjaro boots fine if I use the recovery boot option with the fallback initramfs. That isn't an older kernel, it just appears to contain the complete collection of drivers, rather than the minimum required set in the default version.

Some online research found that this symptom is known to happen in Arch and some other distros. However, none of the posted fixes solved the problem. I also couldn't figure out how to just make the fallback initramfs the normal boot option. So if there's a known fix for the boot failure problem, or instructions on how to make the fallback the normal boot, that would be great.

  1. Question

So now I've got the Beta version installed, and at least a way to get it to boot. If I don't run into any other problems, that will be fine to do my evaluation, but if I switch to Manjaro as my primary distro, I'll want the stable release.

What I don't know is the update/upgrade path this puts me on. Will the Beta version just continue to be updated until it is actually released, at which point I will have the same thing as someone who downloads the new stable v18.0, and my installation will become the stable release? Or does the Beta version put the installation on the Beta, or Testing, track, and I will continue to always have the "latest" Testing release, even after stable v18.0 is released?

#2

I assure you that it works for many people so if you are having issues you will need to post the specific errors you are getting so we can help resolve them.

This sounds like you tried to use another distros grub to boot Manjaro. That won't work without manual tweaking.

Yes, Manjaro is rolling so it doesn't really matter where you start, you will end up at the same place.

The only thing that is different is that you are on the "testing" branch. You can either continue to run the testing branch or switch to stable at any time.

1 Like
#3

dalto, thanks for the response.

Right after posting, I spotted another question here, with someone else experiencing a similar boot failure. I tried abc's solution of using Manjaro to reinstall and update GRUB (Kernel panic amd-ucode), and that did fix the boot issue. Yeah, the distro I installed after Manjaro was Kubuntu, so apparently the issue of Ubuntu's GRUB installation trashing Manjaro's is a known problem . I verified that every OS boots properly using Manjaro's GRUB installation. I'll have to get used to seeing the Manjaro GRUB logo regardless of what I boot. :slight_smile:

Regarding Octopi and the updates, there isn't a simple way to replicate the specific errors at this point. There were dozens of packages with conflicts, mostly related to packages available in different versions or from different streams. It gave me the impression that Octopi thought the originally installed versions were from one stream, and those were being replaced by newer packages from a different stream. Octopi just got it wrong, claiming there was a conflict with something that was not installed. Octopi wanted me to chose whether to delete the "old" version, and regardless of what I chose, the entire update bombed.

Thanks for clarifying that installing the Beta version puts me in the Testing stream. I guess I can wait for the stable version to be released and switch, or just switch now and use Pamac for updates.

#4

Pacman caches all installed packages in /var/cache/pacman/pkg.

This cache needs to be managed, otherwise it will continue to grow over time. Default is generally to keep the last three versions of all packages, but if space is short two versions will suffice.

Use Octopi or Pamac or paccache to do this.

Screenshot_20180916_144602

Use pacman-mirrors to switch branches from testing to stable ...

sudo pacman-mirrors -B stable
sudo pacman -Syyuu

This will force a pacman database refresh and downgrade any testing packages with a later version than stable.

2 Likes
#5

Thanks. The cache information will be really useful.

I had actually just stumbled across another thread that explained what you described about just needing to switch mirrors to go back to Stable. That's brilliantly simple. I'm used to the Debian family, where the difference between branches isn't just a question of timing. There can be different versions of packages in the different branches, with different dependencies, etc.

#6

You may also want to check the size of your systemd journal logs. By default they are very verbose and can quickly reach their 4GB limit.

Reduce log size using ...

sudo journalctl --vacuum-size=50M

To make your journal logging less verbose, edit your /etc/systemd/journald.conf ...

SystemMaxUse=50M
...
RuntimeMaxUse=50M
...
MaxLevelStore=err
MaxLevelSyslog=warning
MaxLevelKMsg=warning
MaxLevelConsole=err
1 Like
#7

More good stuff! Thanks.

#8

you may want sometimes free space for cache ,
but beware no downgrade allowed after until next update

sudo pacman -Sc ( keep only one version )

#9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by