[SOLVED] Segmentation faults while recovering existing installation

Phantz_ · 2025-12-17 11:15:49

I am trying to recover my existing Arch installation after fstrim seemingly corrupted it. After a fstrim run (ran it twice in one day, first run didn't corrupt), my initramfs probably got busted and I couldn't boot back in anymore (stuck on "Loading initial ram disk" forever) - so I decided to boot into a live arch iso to try and recover.

My only other system was using windows so I used rufus with MBT partition type + DD write mode on a usb drive. The Arch ISO I have is x86_64 and I verified the sha256sum of it. My laptop is a framework 13 with i5-1260p.

I booted in and did fsck on the root partition, turns out it had a LOT of errors and there had to be a lot of inode modifications, removals, directory splitting etc by fsck.

I mounted my existing root partition to /mnt and my /boot partition to /mnt/boot but unfortunately, I'm stumped at recovering since almost everything causes a seg fault. arch-chroot causes a segfault. chroot itself hits seg faults and illegal instructions....

I tried to install intel-ucode on the archiso itself (outside of chroot) but I assume that's not meant to work as it gives me "/boot/vmlinuz-linux must be readable" error...

I ran memtest and it passed fine. At this point, I'm not entirely sure why I'm getting illegal instruction. I'm on a x86_64 ISO, and on a x86_64 system.... right?

I know I likely need to reinstall most packages as a lot of them seem corrupted (after all, fsck did have to fix a lot of errors on the root partition; and I also saw a lot of packages with missing desc file, unknown key etc). However, I am unable to do so because, as one might expect by now, even `pacman -b /mnt/var/lib/pacman/ -r /mnt` commands hit seg faults and illegal instructions.

Is there any way out of this? What is causing chroot itself to hit illegal instructions? Am I somehow on the wrong archiso or perhaps I burned it into the USB improperly...?

My arch ISO SHA256: C2B1F13A68482DB3AAD008F14BB75CB15A44CD38FA8A1AA15E6675A50D4C4374

Last edited by Phantz_ (2025-12-18 00:34:22)

Phantz_ · 2025-12-17 11:19:14

The story behind needing to run fstrim several times in a day (not great, I know) didn't seem relevant. Basically I was trying to debug my laptop being far too slow and I suspect it started after my NVME SSD (SN770) hit 90%+ used up earlier that day. I proceeded to remove a lot of unnecessary stuff (from my home partition, nothing important - I booted just fine several times after this deletion). Interestingly enough, after I ran fstrim the first time - it said it cleared a lot of gigs but nothing really improved. I ran it again much later, on another boot, expecting nothing to happen (as I hadn't deleted much since then). Instead, it trimmed almost the exact same amount as the last run..... pretty obvious that something went wrong at that point.

Last edited by Phantz_ (2025-12-17 11:20:18)

Lone_Wolf · 2025-12-17 12:03:44

man fstrim wrote:

]
fstrim will report the same potential discard bytes each time

The amount shown is useful to verify progress when trimming multiple partitions, but that's all.

This sounds like your SSD is dying.
Dismount the ssd , minimize access to it and certainly don't write anything to it.

Read https://wiki.archlinux.org/title/S.M.A.R.T. and post the output of # smartctl -H /dev/device .

Moderator Note
moving to Kernel & Hardware

Last edited by Lone_Wolf (2025-12-17 12:04:21)

seth · 2025-12-17 14:19:06

framework 13 with i5-1260p

Just in case it has an AMD GPU, see https://bbs.archlinux.org/viewtopic.php?id=310245

Still! See smartctl! And you can use http://grml.org/ to hopefully get out of the amdgpu firmware thing (if any) and generally avoid any other kernel bugs - if the drive acts up there as well, there's a problem w/ the drive.
The fsck errors /can/ be a result of the trim gone horribly wrong but we need to rule out a broken drive first and foremost.

Phantz_ · 2025-12-17 20:25:22

Sorry I should've posted the output of smart in my original post. SSD dying was my first thought before the catastrophe (of corrupting my root partition) happened, i.e before fstrim and so on. Health and everything was fine, and I ran the short and long tests via smartctl which also passed without errors.

I ran once again within the installation media after the catastrophe (pointing to my nvme drive of course) and indeed it still reports no errors.

Lone_Wolf wrote:

man fstrim wrote:
]
fstrim will report the same potential discard bytes each time
The amount shown is useful to verify progress when trimming multiple partitions, but that's all.

Not to get too much into the topic of fstrim since it's probably a bit off-topic at this point, but it doesn't make sense to me for fstrim (regardless of the man page) to say "Trimmed 200 gigs from partition A" on the first run (after I indeed rm-ed ~200 gigs of data myself), then after no further real deletions (and a few boots), for fstrim to run again and say again "Trimmed 200 gigs from partition A" (it wasn't the exact same number but almost the same). I'd expect it to say either a much lower number or zero, as there shouldn't be much to trim at this point. Given that this was the moment (I tried to reboot immediately afterwards) when my initramfs and stuff got corrupted (could no longer boot back in) - it _seems_ a lot like fstrim was at fault.

Regardless, I can find the blame later (hopefully), and certainly in a different thread to be more on-topic. At the moment, I should focus on figuring out why the hell I'd be getting illegal instructions - ideally without having to valgrind things and similar rabbit hole....

seth wrote:

Just in case it has an AMD GPU, see,,,,

I unfortunately don't have an AMD GPU, it's just the intel on board graphics on the i5 itself.

Phantz_ · 2025-12-17 20:28:43

Since we're talking about my SSD, I should mention that my root is using ext4 (alongside the other partitions except /boot of course). Yes, I know I should probably move on to a different fs in 2025.

seth · 2025-12-17 20:32:59

long tests via smartctl which also passed without errors.

What's the spare sector percentage? Below 100%?

it wasn't the exact same number but almost the same

Please don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855

At the moment, I should focus on figuring out why the hell I'd be getting illegal instructions

Also for this.
Please post your complete system journal for the boot after causing such

sudo journalctl -b | curl -F 'file=@-' 0x0.st

I know I should probably move on to a different fs in 2025.

Why?

Phantz_ · 2025-12-17 21:51:44

There has been another change, on another a boot - my drive had disappeared from /dev altogether. It's still showing up in lspci as "Non Volatile Memory Controller ... SN770 ..."
Here is the boot log from that boot (though I rebooted next and it reappared (?)): https://0x0.st/PrGY.txt

Next, here's the smart output for my drive (once it showed up again on the next boot): https://0x0.st/PrG0.txt

And here's the journalctl log right after calling arch-chroot and it hitting a segfault (check around 21:40): https://0x0.st/PrGG.txt

I have made some progress however. The segfaults always happen in bash it seems, so I went ahead and reinstalled bash in my /mnt (using `pacman -b /mnt/var/lib/pacman -r /mnt`) and I can _at least_ arch-chroot again. This confirms the previous beliefs about my data being corrupted.

I'm glad reinstalling bash didn't cause too much trouble, however `pacstrap -K /mnt base base-devel linux linux-firmware` does report "Invalid or corrupted package" on linux-6.18.1 already existing in my /mnt/var/lib/pacman/local, Specifically:

error: could not open file /mnt/var/lib/pacman/local/linux-6.18.1.arch1-2/files: No such file or directory

At this point, I probably have to uninstall everything and reinstall it from scratch. What would the best way to do it? Obviously simple reinstalls (which is what the pacstrap command earlier triggerred as those packages already exist on my system) wouldn't work as, during the reinstall, pacman will realize something is terribly wrong with the installed stuff.

> I know I should probably move on to a different fs in 2025.
Off-topic but BRTFS seems mature enough at this point and data integrity functionalities may actually have been useful in my case here....

Phantz_ · 2025-12-17 21:58:06

I should mention that after arch-chrooting, simple commands such as `pacman -Syy`, `pacman -Qi` all seg fault. Perhaps the pacman db, cache etc are all hopelessly broken on my root? If so, how can I - well - manually clear it up and trigger pacman to start from scratch....?

Whichever `pacman` is being used after chrooting (probably my root partition's pacman) is entirely broken. I can use archiso's pacman (using `-r` and `-b` to set to `/mnt`) to at least _attempt_ installing things. However, trying to reinstall base via `-Syu base` still hits a segfault....

seth · 2025-12-17 22:09:54

Dec 17 21:29:36 archiso kernel: nvme nvme0: I/O tag 29 (201d) QID 0 timeout, disable controller
Dec 17 21:29:36 archiso kernel: nvme nvme0: Failed to read smart log (error -4)
Dec 17 21:29:36 archiso kernel: nvme 0000:01:00.0: probe with driver nvme failed with error -4

Temperature:                        34 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    2%
Data Units Read:                    17,481,496 [8.95 TB]
Data Units Written:                 34,093,521 [17.4 TB]
Host Read Commands:                 281,104,128
Host Write Commands:                505,592,705
Controller Busy Time:               10,607
Power Cycles:                       4,997
Power On Hours:                     549

Doesn't look that bad, chaces are it's the bus, not the drive.

log right after calling arch-chroot and it hitting a segfault

Dec 17 21:39:42 archiso kernel: EXT4-fs (nvme0n1p2): mounted filesystem c6d740a8-e700-49dc-a0bc-c7a8d88ade74 r/w with ordered data mode. Quota mode: none.
Dec 17 21:39:45 archiso systemd[1]: systemd-hostnamed.service: Deactivated successfully.
Dec 17 21:39:45 archiso audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 17 21:39:45 archiso kernel: audit: type=1131 audit(1766007585.509:143): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 17 21:39:45 archiso audit: BPF prog-id=71 op=UNLOAD
Dec 17 21:39:45 archiso kernel: audit: type=1334 audit(1766007585.539:144): prog-id=71 op=UNLOAD
Dec 17 21:40:17 archiso audit[1411]: ANOM_ABEND auid=0 uid=0 gid=0 ses=1 pid=1411 comm="bash" exe="/usr/bin/bash" sig=11 res=1
Dec 17 21:40:17 archiso kernel: bash[1411]: segfault at 0 ip 000055d34118ad26 sp 00007ffd8e9a3fb0 error 6 in bash[86d26,55d341120000+cb000] likely on CPU 14 (core 22, socket 0)
Dec 17 21:40:17 archiso kernel: Code: c7 18 4d 39 fe 75 cd 31 d2 48 8d b5 40 ff ff ff bf 02 00 00 00 ff 15 29 1e 09 00 83 bd 3c ff ff ff 00 0f 84 68 ff ff ff 31 c0 <48> 89 04 25 00 00 00 00 0f 0b f3 0f 1e fa 48 8b 35 f5 30 0a 00 bf
Dec 17 21:40:17 archiso kernel: audit: type=1701 audit(1766007617.233:145): auid=0 uid=0 gid=0 ses=1 pid=1411 comm="bash" exe="/usr/bin/bash" sig=11 res=1
Dec 17 21:40:17 archiso systemd-coredump[1412]: Process 1411 (bash) of user 0 terminated abnormally with signal 11/SEGV, processing...
Dec 17 21:40:17 archiso systemd[1]: Created slice Slice /system/systemd-coredump.
Dec 17 21:40:17 archiso audit: BPF prog-id=74 op=LOAD
Dec 17 21:40:17 archiso audit: BPF prog-id=75 op=LOAD
Dec 17 21:40:17 archiso audit: BPF prog-id=76 op=LOAD
Dec 17 21:40:17 archiso audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@0-1-1412_1413-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 17 21:40:17 archiso systemd[1]: Started Process Core Dump (PID 1412/UID 0).
Dec 17 21:40:17 archiso kernel: audit: type=1334 audit(1766007617.270:146): prog-id=74 op=LOAD
Dec 17 21:40:17 archiso kernel: audit: type=1334 audit(1766007617.270:147): prog-id=75 op=LOAD
Dec 17 21:40:17 archiso kernel: audit: type=1334 audit(1766007617.270:148): prog-id=76 op=LOAD
Dec 17 21:40:17 archiso kernel: audit: type=1130 audit(1766007617.271:149): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@0-1-1412_1413-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 17 21:40:17 archiso systemd-coredump[1413]: Process 1411 (bash) of user 0 dumped core.
                                                
                                                Stack trace of thread 1:
                                                #0  0x000055d34118ad26 n/a (/usr/bin/bash + 0x86d26)
                                                #1  0x000055d34118e7a8 n/a (/usr/bin/bash + 0x8a7a8)
                                                #2  0x000055d34118e8fd n/a (/usr/bin/bash + 0x8a8fd)
                                                #3  0x00007f879a83e4d0 n/a (libc.so.6 + 0x3e4d0)
                                                #4  0x000055d3411c5520 n/a (/usr/bin/bash + 0xc1520)
                                                #5  0x000055d3411215b8 n/a (/usr/bin/bash + 0x1d5b8)
                                                #6  0x00007f879a827635 n/a (libc.so.6 + 0x27635)
                                                #7  0x00007f879a8276e9 __libc_start_main (libc.so.6 + 0x276e9)
                                                #8  0x000055d3411225a5 n/a (/usr/bin/bash + 0x1e5a5)
                                                ELF object binary architecture: AMD x86-64
Dec 17 21:40:17 archiso audit[1410]: ANOM_ABEND auid=0 uid=0 gid=0 ses=1 pid=1410 comm="unshare" exe="/usr/bin/unshare" sig=11 res=1
Dec 17 21:40:17 archiso systemd[1]: systemd-coredump@0-1-1412_1413-0.service: Deactivated successfully.
Dec 17 21:40:17 archiso audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@0-1-1412_1413-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 17 21:40:17 archiso kernel: audit: type=1701 audit(1766007617.318:150): auid=0 uid=0 gid=0 ses=1 pid=1410 comm="unshare" exe="/usr/bin/unshare" sig=11 res=1
Dec 17 21:40:17 archiso kernel: audit: type=1131 audit(1766007617.318:151): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@0-1-1412_1413-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 17 21:40:17 archiso systemd-coredump[1416]: Process 1410 (unshare) of user 0 terminated abnormally with signal 11/SEGV, processing...
Dec 17 21:40:17 archiso audit: BPF prog-id=77 op=LOAD
Dec 17 21:40:17 archiso audit: BPF prog-id=78 op=LOAD
Dec 17 21:40:17 archiso audit: BPF prog-id=79 op=LOAD
Dec 17 21:40:17 archiso systemd[1]: Started Process Core Dump (PID 1416/UID 0).
Dec 17 21:40:17 archiso audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@1-2-1416_1417-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 17 21:40:17 archiso kernel: audit: type=1334 audit(1766007617.322:152): prog-id=77 op=LOAD
Dec 17 21:40:17 archiso kernel: audit: type=1334 audit(1766007617.322:153): prog-id=78 op=LOAD
Dec 17 21:40:17 archiso audit: BPF prog-id=76 op=UNLOAD
Dec 17 21:40:17 archiso audit: BPF prog-id=75 op=UNLOAD
Dec 17 21:40:17 archiso audit: BPF prog-id=74 op=UNLOAD
Dec 17 21:40:17 archiso systemd-coredump[1419]: Process 1410 (unshare) of user 0 dumped core.
                                                
                                                Stack trace of thread 1410:
                                                #0  0x00007f53a91086db kill (libc.so.6 + 0x3e6db)
                                                #1  0x000055655f35a298 n/a (/usr/bin/unshare + 0x4298)
                                                #2  0x00007f53a90f1635 n/a (libc.so.6 + 0x27635)
                                                #3  0x00007f53a90f16e9 __libc_start_main (libc.so.6 + 0x276e9)
                                                #4  0x000055655f35a885 n/a (/usr/bin/unshare + 0x4885)
                                                ELF object binary architecture: AMD x86-64
Dec 17 21:40:17 archiso systemd[1]: systemd-coredump@1-2-1416_1417-0.service: Deactivated successfully.
Dec 17 21:40:17 archiso audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@1-2-1416_1417-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 17 21:40:17 archiso audit: BPF prog-id=79 op=UNLOAD
Dec 17 21:40:17 archiso audit: BPF prog-id=78 op=UNLOAD
Dec 17 21:40:17 archiso audit: BPF prog-id=77 op=UNLOAD

Probably just filesystem corruption?
From the iso (do not chroot!)

LC_ALL=C pacman --root=/mnt -Qkk |& grep --line-buffered -v ', 0 altered files' | grep -v backup > /tmp/howbadisit.txt
cat /tmp/howbadisit.txt | curl -F 'file=@-' 0x0.st

At this point, I probably have to uninstall everything and reinstall it from scratch.

No.
1. let's see how bad it acutally is
2. you need to get the drive under control first!

Dec 17 21:36:22 archiso kernel:  nvme0n1: p1 p2 p3 p4

There's no parallel windows installation on that extra partition(s)?

nvme_core.default_ps_max_latency_us=0 pcie_aspm=off iommu=soft

and maybe also

pcie_port_pm=off

https://wiki.archlinux.org/title/Solid_ … ST_support

data integrity functionalities may actually have been useful in my case here

Search the forums - "trimming incidents" tend to hurt more on btrfs…

Phantz_ · 2025-12-17 22:13:32

Another update: Reinstalling glibc (honestly should have tried to reinstall that before any of the other reinstalls e.g base) has decreased the segfaults and unblocked some other reinstalls.

Phantz_ · 2025-12-17 22:26:41

Here's the howbadisit, and I'm afraid that it looks quite bad (it might be almost all my packages): https://0x0.st/PrDj.txt

I do not have windows in any of the partitions (or any other drives for that matter) - this laptop is just one SSD and it's all linux partitions. p1 is boot, p2 is root, p3 is home (doesn't seem corrupted according to fsck), p4 is nix packages (unimportant and seem uncorrupted).

seth · 2025-12-17 22:41:25

aws-c-event-stream: no mtree file
clingo: no mtree file
libdvdread: no mtree file
libexif: no mtree file
libimobiledevice: no mtree file
linux-firmware-whence: no mtree file
mkinitcpio: no mtree file
mlt: no mtree file
sdl3: no mtree file
simdjson: no mtree file
zsh: no mtree file

You completely lost the database for those and need to sanitize that and re-install the packages then

pacman --root=/mnt --cachedir=/mnt/var/cache/pacman/pkg --dbonly -Sy aws-c-event-stream clingo libdvdread libexif libimobiledevice linux-firmware-whence mkinitcpio  mlt sdl3 simdjson zsh

Then probably re-install all packages (also using pacman --root=/mnt --cachedir=/mnt/var/cache/pacman/pkg from the iso, no chroot! And do NOT use --dbonly on this second pass)
Make sure to have you /boot partition mounted into /mnt/boot

The --db-only pass will probably throw a lot of ld errors at you, you can ignore those and just continue.

Phantz_ · 2025-12-17 23:03:42

I was able to reinstall those. However, reinstalling some more packages (e.g pacman, audit, systemd etc) gives me seg faults on /usr/share/libalpm/scripts/systemd-hook of the following:

- line 30: 5762 Segmentation fault /usr/bin/systemd-sysusers
- line 3: 5770 Segmentation fault systemd-detect-virt --chroot
- line 10: 5775 Segmentation fault systemd-notify --booted

And yes I do have my boot partition mounted.

Here's the journal log taken after those seg faults (check bottom entries): https://0x0.st/PrD5.txt

EDIT: mkinitcpio installation itself seems to segfault at the same places actually

Last edited by Phantz_ (2025-12-17 23:14:43)

seth · 2025-12-17 23:38:25

DO NOT CHROOT.

pacman --root=/mnt -Qnq | pacman --root=/mnt --cachedir=/mnt/var/cache/pacman/pkg -S -

You *cannot* use the pacman of the installed system.
You might also get some hooks failing, just re-run the re-installation of all pacakges to trigger all hooks on the now hopefully fixed system again.

DO NOT CHROOT.

Phantz_ · 2025-12-18 00:03:33

To be clear, and as reassurance, I haven't been using the installed system's pacman to issue any of the previous stateful commands - rather, I was merely trying to gauge its health (simple stuff such with `-Q*`) after the prior steps.

A lot of packages are being downloaded for reinstallation (after `touch`ing a few missing `*/files`) from the command you provided (and indeed to reassure, I'm not chrooted). Note that I had to run it with `--dbonly` once first (it gave me "... exists in filesystem" errors. There were A LOT of logs, with many warings, and probably some errors as well - in the end, I got a 0 exit code though.

At the end of the screen, I see a few errors such as:
- "Failed to import file /usr/lib/systemd/catalog/dbus-broker-launch.catalog: No such file or directory"
- Failed to write database /usr/lib/udev/hwdb.bin: Function not imlemeneted
etc...

Is there a good way to perhaps capture all the stuff printed on the terminal?

If not, how can I verify how much progress towards fixing that command was able to do?

Phantz_ · 2025-12-18 00:10:54

There's a lot of failures related to /dev/fd/63 - which I'm guessing is simply because the hooks are looking at the wrong root (`/` instead of `/mnt`) - I guess pacman's root arg isn't necessarily forwarded to all hooks.

I'm tempted to chroot now and rerun those hooks, ideally they'd simply work there - but I'll await confirmation.

seth · 2025-12-18 00:17:22

If the overall installation eventually went fine and only the hooks failed you can attempt to chroot into the system and re-install packages there.
fd 63 is the pipe and it's kinda normal that several hooks will fail in an offline update.

Phantz_ · 2025-12-18 00:33:10

Thanks! That seemed to have rescued my root partition and I'm able to boot back in.

Unfortunately, it looks like my home partition is also corrupted.... most filesystems operations (including ls) give me "Bad message". I'll run fsck and see what can be recovered - hopefully not everything is lost.

But this thread, at least, is solved. Thanks a lot!

Phantz_ · 2025-12-18 00:37:12

Just for my own reference in the future: Any clue what could have caused that fstrim to hammer my drive? Is trimming particularly risky?

seth · 2025-12-18 07:47:24

Is trimming particularly risky?

If your drive doesn't properly support it or maybe if you're trying an explicit trim while another one is running (scheduled) or the device is mounted "discard".

Might also have been a pre-emptive power loss, ie. you shut down the system (hard or soft) *while* the trim was ongoing?
Edit: https://wiki.archlinux.org/title/Solid_state_drive#TRIM

Last edited by seth (2025-12-18 07:47:49)

Arch Linux

#1 2025-12-17 11:15:49

[SOLVED] Segmentation faults while recovering existing installation

#2 2025-12-17 11:19:14

Re: [SOLVED] Segmentation faults while recovering existing installation

#3 2025-12-17 12:03:44

Re: [SOLVED] Segmentation faults while recovering existing installation

#4 2025-12-17 14:19:06

Re: [SOLVED] Segmentation faults while recovering existing installation

#5 2025-12-17 20:25:22

Re: [SOLVED] Segmentation faults while recovering existing installation

#6 2025-12-17 20:28:43

Re: [SOLVED] Segmentation faults while recovering existing installation

#7 2025-12-17 20:32:59

Re: [SOLVED] Segmentation faults while recovering existing installation

#8 2025-12-17 21:51:44

Re: [SOLVED] Segmentation faults while recovering existing installation

#9 2025-12-17 21:58:06

Re: [SOLVED] Segmentation faults while recovering existing installation

#10 2025-12-17 22:09:54

Re: [SOLVED] Segmentation faults while recovering existing installation

#11 2025-12-17 22:13:32

Re: [SOLVED] Segmentation faults while recovering existing installation

#12 2025-12-17 22:26:41

Re: [SOLVED] Segmentation faults while recovering existing installation

#13 2025-12-17 22:41:25

Re: [SOLVED] Segmentation faults while recovering existing installation

#14 2025-12-17 23:03:42

Re: [SOLVED] Segmentation faults while recovering existing installation

#15 2025-12-17 23:38:25

Re: [SOLVED] Segmentation faults while recovering existing installation

#16 2025-12-18 00:03:33

Re: [SOLVED] Segmentation faults while recovering existing installation

#17 2025-12-18 00:10:54

Re: [SOLVED] Segmentation faults while recovering existing installation

#18 2025-12-18 00:17:22

Re: [SOLVED] Segmentation faults while recovering existing installation

#19 2025-12-18 00:33:10

Re: [SOLVED] Segmentation faults while recovering existing installation

#20 2025-12-18 00:37:12

Re: [SOLVED] Segmentation faults while recovering existing installation

#21 2025-12-18 07:47:24

Re: [SOLVED] Segmentation faults while recovering existing installation

Board footer