Falla arranque Leap 15.6 KDE

surrender · July 29, 2026, 2:17am

Buenas tardes comunidad:
Traigo nuevamente un problema y solicito su apoyo.
Tengo un equipo con OS Leap 15.6 hoy luego de reiniciarlo presentó un fallo que no permite utilizarlo aún seleccionando diferente kernel.

Los datos de sistema son: (datos recuperados de un respaldo anterior)
inxi -Fxxxzr
System:

Kernel: 6.4.0-150600.23.92-default arch: x86_64 bits: 64 compiler: gcc
v: 7.5.0 Desktop: KDE Plasma v: 5.27.11 tk: Qt v: 5.15.12 wm: kwin_x11 vt: 2
dm: SDDM Distro: openSUSE Leap 15.6
Machine:
Type: Laptop System: LENOVO product: 627786S v: ThinkPad Edge E431
serial: Chassis: type: 10 serial:
Mobo: LENOVO model: 627786S v: Win8 Pro DPK TPG
serial: UEFI-[Legacy]: LENOVO v: HEET34WW (1.15 )
date: 07/02/2013

Battery:
ID-1: BAT0 charge: 35.5 Wh (100.0%) condition: 35.5/38.9 Wh (91.4%)
volts: 12.2 min: 10.8 model: SANYO 45N1043 type: Li-ion serial:
status: full

CPU:
Info: dual core model: Intel Core i3-3120M bits: 64 type: MT MCP
smt: enabled arch: Ivy Bridge rev: 9 cache: L1: 128 KiB L2: 512 KiB
L3: 3 MiB
Speed (MHz): avg: 1200 min/max: 1200/2500 cores: 1: 1200 2: 1200 3: 1200
4: 1200 bogomips: 19953
Flags: avx ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3
Graphics:
Device-1: Intel 3rd Gen Core processor Graphics vendor: Lenovo driver: i915
v: kernel arch: Gen-7 ports: active: LVDS-1 empty: DP-1, DP-2, HDMI-A-1,
HDMI-A-2, VGA-1 bus-ID: 00:02.0 chip-ID: 8086:0166 class-ID: 0300
Device-2: Bison Integrated Camera driver: uvcvideo type: USB rev: 2.0
speed: 480 Mb/s lanes: 1 bus-ID: 1-1.6:5 chip-ID: 5986:0397 class-ID: 0e02
Display: x11 server: X.Org v: 1.21.1.11 with: Xwayland v: 24.1.1
compositor: kwin_x11 driver: X: loaded: modesetting unloaded: fbdev,vesa
alternate: intel dri: crocus gpu: i915 display-ID: :0 screens: 1
Screen-1: 0 s-res: 1366x768 s-dpi: 96 s-size: 361x203mm (14.21x7.99")
s-diag: 414mm (16.31")
Monitor-1: LVDS-1 model: BOE Display 0x05c9 res: 1366x768 hz: 60 dpi: 112
size: 309x173mm (12.17x6.81") diag: 354mm (13.9") modes: 1366x768
API: OpenGL v: 4.2 Mesa 23.3.4 renderer: Mesa Intel HD Graphics 4000 (IVB
GT2) direct-render: Yes

Audio:
Device-1: Intel 7 Series/C216 Family High Definition Audio vendor: Lenovo
driver: snd_hda_intel v: kernel bus-ID: 00:1b.0 chip-ID: 8086:1e20
class-ID: 0403
API: ALSA v: k6.4.0-150600.23.92-default status: kernel-api with: aoss
type: oss-emulator
Server-1: PipeWire v: 1.0.5 status: off with: wireplumber status: active
Server-2: PulseAudio v: 17.0 status: active with: pulseaudio-alsa
type: plugin

Network:
Device-1: Broadcom BCM43142 802.11b/g/n vendor: Lenovo driver: wl v: kernel
pcie: speed: 2.5 GT/s lanes: 1 bus-ID: 04:00.0 chip-ID: 14e4:4365
class-ID: 0280
IF: wlan1 state: up mac:
Device-2: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet
vendor: Lenovo driver: r8169 v: kernel pcie: speed: 2.5 GT/s lanes: 1
port: 2000 bus-ID: 05:00.0 chip-ID: 10ec:8168 class-ID: 0200
IF: eth0 state: down mac:
Bluetooth:
Device-1: Foxconn BCM43142A0 Bluetooth module driver: btusb v: 0.8 type: USB
rev: 2.0 speed: 12 Mb/s lanes: 1 bus-ID: 1-1.3:3 chip-ID: 105b:e065
class-ID: fe01 serial:
Report: rfkill ID: hci0 rfk-id: 2 state: up address: see --recommends
Drives:
Local Storage: total: 447.13 GiB used: 280.61 GiB (62.8%)
ID-1: /dev/sda vendor: Western Digital model: WDS480G2G0A-00JH30
size: 447.13 GiB speed: 6.0 Gb/s tech: SSD serial: fw-rev: 0400
scheme: MBR

Partition:
ID-1: / size: 342.59 GiB used: 278.61 GiB (81.3%) fs: btrfs dev: /dev/sda3
ID-2: /home size: 342.59 GiB used: 278.61 GiB (81.3%) fs: btrfs
dev: /dev/sda3
ID-3: /opt size: 342.59 GiB used: 278.61 GiB (81.3%) fs: btrfs
dev: /dev/sda3
ID-4: /tmp size: 342.59 GiB used: 278.61 GiB (81.3%) fs: btrfs
dev: /dev/sda3
ID-5: /var size: 342.59 GiB used: 278.61 GiB (81.3%) fs: btrfs
dev: /dev/sda3
Swap:
ID-1: swap-1 type: partition size: 2 GiB used: 2 GiB (100.0%) priority: -2
dev: /dev/sda4

Sensors:
System Temperatures: cpu: 46.0 C mobo: N/A
Fan Speeds (RPM): cpu: 0 fan-2: 0
Repos:
Packages: pm: rpm pkgs: N/A note: see --rpm
Active zypp repos in: /etc/zypp/repos.d/Packman.repo
1: Packman ~ https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_15.6/
No active zypp repos in: /etc/zypp/repos.d/openSUSE-Leap-15.6-1.repo
No active zypp repos in: /etc/zypp/repos.d/repo-backports-debug-update.repo
Active zypp repos in: /etc/zypp/repos.d/repo-backports-update.repo
1: repo-backports-update ~ http://download.opensuse.org/update/leap/$releasever/backports/
No active zypp repos in: /etc/zypp/repos.d/repo-debug-non-oss.repo
No active zypp repos in: /etc/zypp/repos.d/repo-debug-update-non-oss.repo
No active zypp repos in: /etc/zypp/repos.d/repo-debug-update.repo
No active zypp repos in: /etc/zypp/repos.d/repo-debug.repo
Active zypp repos in: /etc/zypp/repos.d/repo-non-oss.repo
1: repo-non-oss ~ http://download.opensuse.org/distribution/leap/$releasever/repo/non-oss/
Active zypp repos in: /etc/zypp/repos.d/repo-openh264.repo
1: repo-openh264 ~ http://codecs.opensuse.org/openh264/openSUSE_Leap/
Active zypp repos in: /etc/zypp/repos.d/repo-oss.repo
1: repo-oss ~ http://download.opensuse.org/distribution/leap/$releasever/repo/oss/
No active zypp repos in: /etc/zypp/repos.d/repo-sle-debug-update.repo
Active zypp repos in: /etc/zypp/repos.d/repo-sle-update.repo
1: repo-sle-update ~ http://download.opensuse.org/update/leap/$releasever/sle/
No active zypp repos in: /etc/zypp/repos.d/repo-source.repo
Active zypp repos in: /etc/zypp/repos.d/repo-update-non-oss.repo
1: repo-update-non-oss ~ http://download.opensuse.org/update/leap/$releasever/non-oss/
Active zypp repos in: /etc/zypp/repos.d/repo-update.repo
1: repo-update ~ http://download.opensuse.org/update/leap/$releasever/oss/

Info:
Processes: 276 Uptime: 2h 10m wakeups: 7415 Memory: available: 5.37 GiB
used: 4.59 GiB (85.5%) Init: systemd v: 254 default: graphical Compilers:
gcc: 7.5.0 alt: 7 Shell: Bash v: 4.4.23 running-in: konsole inxi: 3.3.27

Esta es la imagen de la falla principal.

Intenté la opción de “actualizar” el sistema operativo, no resultó.
Imagen 02

Imagen 03

Imagen 04

Probé con un disco live de Mint para leer las particiones y no pudo montarla. Al abrir la carpeta “Initramfs” aparece vacía, por lo que no puedo leer el registro indicado en la falla principal.

Mi objetivo principal es reparar la instalación o al menos acceder a los archivos para realizar un respaldo.

En este punto no entiendo lo que ocurre.

Agradezco de antemano su apoyo

Saludos

Krovikan · July 29, 2026, 8:48am

Es un problema con el initramfs.

Si te fijas, te dice: “Entering emergency mode” etc y después “Give root password for maintenance”.

Ahí, has de escribir tu contraseña de root y te permitirá hacer cosas. Como montar dispositivos y ojear archivos, en especial el que interesa /run/initramfs/rdsosreport.txt.

Aunque puede que se pase por aquí un compañero para decirte como generar de nuevo el initramfs (creo que es con sudo dracut -f pero no lo teclees sin que ellos te respondan o igual empeora las cosas), eso si es tan solo hacer eso.

Saludos

mikrios · July 29, 2026, 10:34pm

Hola:

Dracut -force ( o también -f) fuerza a reescribir initrd y initramfs , pero lo hace del kernel en uso ; Dracut creo que tiene mas opciones , pero no he encontrado ejemplos de ello, si bien se suele ejecutar al finalizar una actualización (los scripts que aparecen en azul) .
Es importante no interrumpir ese proceso , ya que puede fastidiar el arranque.
No se si tiene posibilidad de entrar en una TTY y de ahí hacer un rollback a una instantánea anterior (snapshots) ; sería la forma mas cómoda de recuperar el sistema .

Saludos

DiabloRojo · July 30, 2026, 4:49pm

Para reconstruir el initramfs te sirve los comandos que te di en tu anterior problema con el kernel que está solucionado.

Si no puedes montar una particion con los kernels de tu gecko, el problema ya es bastante chusco, una corrupción de la partición.

Entra en modo de emergencia, identifica tu partición raíz con lsblk o fdisi -l

Y repararlo con , si usas ext4:
fsck -y /dev/sdX (cambia sdX por tu partición real).

Si usas Btfrs, antes de repararlo chequealo con
btrfs check /dev/sdXn para buscar errores sin modificar nada. Y cuéntanos.

PD: Sería gran ayuda que publicaras el registro, ponlo en pastebin de openSUSE y pásanos el enlace.
O danos la salida de
journalctl -p 3 -xb

surrender · July 31, 2026, 11:12pm

Estimado Sr. Diablo:
Ingresé en modo de emergencia y el resultado de “journalctl -p 3 -xb” es el siguiente:

Al ingresar btrfs check /dev/sdXn , esto se obtiene como resultado:

Qué tan mal está?

Saludos

Krovikan · July 31, 2026, 11:35pm

sda3 parece estar bien (no error found), pero journalctl dice que el kernel tiene algún problema con él.

Saludos

soyasi · August 1, 2026, 3:29pm

Hola @surrender:

Con el journalctl que has puesto ya se puede afinar el diagnóstico. El error clave es este:

BTRFS: Transaction aborted (error -17)
…en __btrfs_run_delayed_items, btrfs_recover_log_trees y btrfs_replay_log
“Failed to recover log tree” → open_ctree failed

El -17 es EEXIST (“Object already exists”). Esto pasa en el log tree de btrfs, que es el “diario” de escrituras pendientes que se usa para recuperarse de un apagado no limpio. Al intentar repetir (replay) ese log al montar, encuentra un objeto que ya existe y aborta.

Esto encaja con lo que comenta Krovikan: sda3 está bien a nivel de estructura general (por eso btrfs check no reporta error), pero el log de recuperación en sí está corrupto o inconsistente, y es lo que impide montar.

La solución estándar para esto (y que no debería tocar tus datos) es borrar ese log tree, sin montar la partición antes:

btrfs rescue zero-log /dev/sda3

Esto elimina el log pendiente, así que btrfs deja de intentar el replay que está fallando. Lo único que se pierde son las últimas escrituras que estaban sin confirmar en ese log (normalmente segundos de actividad justo antes del corte), no el sistema de archivos ni los datos ya asentados.

Pasos:

Arrancar en modo live/rescate.
No montar /dev/sda3 antes de nada.
Ejecutar: btrfs rescue zero-log /dev/sda3
Intentar montar de nuevo, o reiniciar y dejar que arranque normalmente.
Si arranca, hacer un respaldo cuanto antes por precaución.

Si zero-log no soluciona el arranque, el siguiente paso sería montar en modo rescate para al menos salvar los archivos importantes:

mount -o ro,rescue=all /dev/sda3 /mnt

Cuéntanos qué tal va.

Saludos

nota: La respuesta es de la IA claude, que la he conectado con el hilo del foro y ha analizado el hilo y las imagenes, dando la respuesta paso a paso.

karlggest · August 1, 2026, 6:33pm

< inserte maldición lo más malsonante posible >

No sé si está respuesta también usan LLM, pero era sencilla de encontrar:

surrender · August 1, 2026, 7:22pm

Si, el kernel no ha tenido muy buena actitud ultimamente.

Haré un respaldo total para luego realizar una instalación limpia con Leap 16

surrender · August 1, 2026, 7:23pm

Muchísimas gracias
Funcionó y ya estoy trabajando en el respaldo

surrender · August 1, 2026, 7:24pm

Tiene toda la razón, lo hice repetidamente!
Jajajaja

DiabloRojo · August 2, 2026, 5:54am

¿Y cual fue la solución?. Marca el mensaje que te lo soluciono o cuentanos como lo has hecho.

Krovikan · August 2, 2026, 9:55am

Por su respuesta… deduzco que el btrfs rescue zero-log /dev/sda3 de @soyasi .

Pero estaría bien que lo dijera y que marcara la solución.

Saludos

karlggest · August 2, 2026, 10:10am

Quicir, en realidad la respuesta estaba ahí, bastaba con buscar el mensaje de error en cualquier navegador. Por ejemplo, en noai.DuckDuckgo.com el primer resultado de buscar btrfs errorno -17 object already exists es ese mismo error en los foros de Fedora.

Una implicación adicional es que puedes repararlo y actualizar el sistema después en lugar de hacer una instalación completa.

Tener copias de seguridad siempre es una buena idea, no por esto en particular, que como se dice en el enlace es un viejo error ya parcheado.

surrender · August 3, 2026, 1:19am

Estimada Comunidad, no puedo menos que agradecer el tiempo y dedicación que dispusieron para ayudarme.

Estos son los pasos que seguí para solucionar el problema

Entrar en modo emergencia (si, es la primera vez que lo hacía)
Identificar el problema con el comando: “journalctl -p 3 -xb”
Realizar diagnóstico con “btrfs check /dev/sdXn” , el resultado indica que la partición no tenía daños.
Borrar el registro con “btrfs rescue zero-log /dev/sda3”
Reiniciar
Realizar el respaldo pendiente de información.

El Equipo funciona normalmente, y en las próximas semanas realizaré una instalación limpia de Leap 16.

Muchas muchas gracias por su constante apoyo

surrender · August 3, 2026, 1:23am

Estimado Karlggest, muchas gracias por su consejo. Tendré que estudiar más sobre las particiones y registros.

DiabloRojo · August 3, 2026, 6:42am

Es decir, que el mensaje de @soyasi es la solución.

Puedes usar opensuse-migration-tool (esta en el repo OSS) para pasar de Leap 15.6 a Leap 16.0, asi lo hice yo.

surrender · August 3, 2026, 4:43pm

Principalmente si, aunque sus recomendaciones me dieron la base para iniciar en la solución

system · August 10, 2026, 4:43pm

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