I am trying to update my system as a ‘guest’ from a live USB session as it has become unstable. I booted into a live USB session with the latest ISO, mounted the root partition and have attempted to update it with
pacman --sysroot <root mount point> -Syyu
It has gotten to the point of actually starting to do the update, and then it segfaults.
Adding the --debug option shows the fault happens at or after
loading fsinfo for <root mount point>
Any ideas about how to debug this further?
manjaro-chroot is not an option?
Hi @gssdu,
Please provide the whole, complete output of the command with the --debug argument:
pacman --sysroot <root mount point> -Syyu --debug
Tip When posting terminal output, copy the output and paste it here, wrapped in three (3) backticks, before AND after the pasted text. Like this:
```
pasted text
```
Or three (3) tilde signs, like this:
~~~
pasted text
~~~
This will just cause it to be rendered like this:
Sed
sollicitudin dolor
eget nisl elit id
condimentum
arcu erat varius
cursus sem quis eros.
Instead of like this:
Sed sollicitudin dolor eget nisl elit id condimentum arcu erat varius cursus sem quis eros.
Alternatively, paste the text you wish to format as terminal output, select all pasted text, and click the </> button on the taskbar. This will indent the whole pasted section with one TAB, causing it to render the same way as described above.
Thereby increasing legibility thus making it easier for those trying to provide assistance.
For more information, please see:
Additionally
If your language isn’t English, please prepend any and all terminal commands with LC_ALL=C. For example:
LC_ALL=C bluetoothctl
This will just cause the terminal output to be in English, making it easier to understand and debug.
Classic XY Problem.
Your attempted solution:
No information whatsoever about your actual problem:
I don’t suppose your recent topic is related?
Yes it is related; it’s the same system we are talking about. One of the suggestions in the kscreenlocker_greet thread was to make sure everything is up to date, leading to this thread.
I did not elaborate on the instability, but in brief:
pacman -Qi <package name> produced a message about double-free and crashed zshpamac completely locked up the system requiring a rebootAll of which led me to there are obviously issues with the software used to update the software, so how to update with a known ‘clean’ installation of pacman/pamac/etc. That lead to trying pacman --sysroot from the live USB session.
Hì @Mirdarthos the output of that command is rather lengthy (it exceeds whatever the default terminal buffer is) so would a link to Pastebin or the like be OK?
That’s perfect, thanks!
@Nachlese , @soundofthunder correct me if I’m wrong, as I don’t fully understand chroot, but in the chroot session would I not be running the software in that new root, rather than the software from my live USB session, when typing pacman ... and the like?
No correction needed.
The kernel is still the same, but the system is the other one.
If core components do not work anymore in that system - chroot will fail.
If that’s the case, your approach might be a way to go.
There is also pacman-static, which could be used in chroot.
@Nachlese yes, this is what I’m thinking, core components do not seem to be working in that system which is why I’m trying --sysroot
@Mirdarthos the log was too big for pastebin (at 13MB) so I broke it into two pieces:
part 1
part 2
--sysroot is also at some point trying to do a chroot - which doesn’t work as we know
--root might work
Look at the Arch wiki and at man pacman
since you said that zsh somehow “crashed”:
Have you tried to explicitly running bash in chroot?
I don’t know whether that is the default with the manjaro-chroot helper tool.
You can do a chroot “manually” - and specify which shell to run in the chroot
We have no idea why or how your chroot fails - you can see the messages when you try, we can’t.
I’m not even sure whether your system will still boot or not.
To TTY is enough - no need for chroot then …
I see many references to the community repository:
debug: config: new section 'community'
…and many, many more. The community repository was dropped ±a year ago already. Which means it’s still configured. Which means you haven’t handled the appropriate .pacnew file. And that suggests you haven’t handled any .pacnew files. Which can lead to breakage, and in this case might be the problem.
So please provide the output of:
sudo DIFFPROG=meld pacdiff
Also, check the following concerning handling .pacnew files:
https://wiki.archlinux.org/title/Pacman/Pacnew_and_Pacsave#.pacnew
Just a thought: At this point in time, it might just be better to do a full re-installation and maintain it better. I did it once as well, and now I maintain my system better.
If required system maintenance tasks have been ignored/neglected for an extended amount of time, as it would appear, then this fact may have contributed to the current state.
This would indeed place the OP’s backside in front of a working computer in the shortest amount of time. If /home is on a separate partition, this would make the whole process easier still.
Naturally, userland applications will also need to be reinstalled, but starting with a fresh slate can have obvious advantages.
It’s worth consideration, at least.
Good luck.
@Mirdarthos @soundofthunder Mea culpa- I’ve not done anything WRT pacnew or pacsave files. I will go read the references provided and do better in the future.
The pacdiff command as written didn’t work as the meld binary could not be found. However without the env var, it revealed some 13 pacnew files and 3 pacsave files including references to pamac.conf and pacman.conf. So it looks like this is something I have to sort at minimum.
I may well re-install, as I do have /home on a different partition.
@Nachlese The zsh crash was just because my first attempt to update the system was to use yakuake and to try running pacman and/or pamac. My system does boot, it just won’t update. It appears my lack of appropriate maintenance is at least partially responsible.
Thanks to everyone for all of the inputs.
What does that look like?
If the system does boot, even if only to a TTY, there should be no need for chroot.
On the chance that these points need to be stated:
/home partition to be formatted.If this just seems like common logic to you, that’s great;
but I have known of cases where some lost their personal data simply through inattention.
Cheers.
@Nachlese I’m not sure what you mean by “look like,” it looks, well, normal. The GUI comes up, I can log in, and use the apps I’ve got just fine (for the handful of things I use routinely; kate, dolphin, brave, yakuake, etc.). It’s only when I attempt to update or change the software that things crash and burn (and also if I let the screen lock kick in; that also crashes the system.) And there could be other apps or utilities that are broken that I just haven’t stumbled across yet.
@soundofthunder Ouch! Yes, I will careful to not reformat that partition. I will document the disk layout and partitions, save my currrent fstab, etc. before going down that path.
When I update, I issue, in a terminal:
sudo pacman-mirrors -c Germany
sudo pacman -Syyu
each of these give output.
You say you can’t update.
You need to show us the result of the second command at least if you want some help.
@Nachlese You can look at the two links, labeled part 1 and part 2, referenced in an earlier reply to Mirdarthos for that log.
… or you can give what I asked for
@Mirdarthos wanted to see debug output
of a different command
this is what is in the links
I did look at it back then
this is simply too much detail for my taste
and it reflects the output of a different command
We already spent some time until we discovered that not even chroot was needed because your system is still fully intact and that you just somehow can’t update.
You should therefore rather start a new thread and reformulate your question there.