Ubuntu boot partíció repair és UEFI meghajtó probléma

csuhas32

laszlo.a.toth@googlemail.com kernel frissítés után történt a fejreállás, lehet hogy a kernelem korrupt lett

Indítsd a GRUB-menüből a korábbi kernellel a rendszert.

klt

Itt volt róla szó:

https://ubuntu.hu/d/46279-rendszerparticio-meretenek-megnovelese-hogyan-lehetseges/37

laszlo.a.toth@googlemail.com

Szervusztok,
Ráróbáltam a jelenlegi GRUB beállításokkal a korábbi kernellel bootolni.
Nekem az 5.19.0-50 és 5.19.0-46 kernelek vannak fenn automatikusan.

Ha normál módban indítoma -46-ot, akkor pár képernyőn olvasható sikeres betöltés és hibaüzenet után automatikusan emergency módba kerülök. Fogalmam sincs hogy miért

Normál módban a dmesg lenne a parancs, amivel el tudom olvasni a kernel üzeneteket. Ilyenkor hová logol bármit is? A Journal file tartalmaz valamit arróll, hogy mi történik boot közben vagy mehetett tönkre?
Ha recovery módban indítom a -46-ot, akkor szuper összetört képernyőt kapok.

Bár egyszer már betöltődött normálisan, de egy sorral lentebb léptetés után lefagyott. Ezt épp le tudtam fényképezni.

meskobalazs

laszlo.a.toth@googlemail.com Próbáltad a journalctl -xb parancsot, amit javasol is? Az kiírja a legutóbbi rendszerindítás óta keletkezett üzeneteket. Van egy csomó kapcsolója, amivel még több infót lehet kiszedni, de általában ez elég szokott lenni.

klt

Egy picit visszább lapoztam a sztoriban, és néhány ponton elakadtam.

laszlo.a.toth@googlemail.com Ha normál módban indítoma -46-ot, akkor pár képernyőn olvasható sikeres betöltés és hibaüzenet után automatikusan emergency módba kerülök. Fogalmam sincs hogy miért

Ilyesmit akkor láttam, ha az fstab-ban valami lehetetlen volt megadva. Például, csatolni akart egy partíciót (UUID alapján), amit időközben formáztam, így az UUID már nem az volt...
Ezt kellene ellenőrizni, hogy mint mond a blkid, és mik vannak annak a rendszernek az fstab-jában?

laszlo.a.toth@googlemail.com az fsck-nak pedig itt az eredménye
laci@Sanyika:~$ sudo fsck /dev/nvme0n1p2
[sudo] password for laci:
fsck from util-linux 2.37.2
e2fsck 1.46.5 (30-Dec-2021)
/dev/nvme0n1p2: clean, 482534/5005312 files, 9140495/20000000 blocks
laci@Sanyika:~$

Ez azt jelenti, hogy az fsck úgy látja, az a fájlrendszer tisztának van jelölve, emiatt ellenőrzést sem végez.
Próbáld meg, hogy -f kapcsolóval indítod:

sudo fsck -f /dev/nvme0n1p2

Látni fogod, belemegy az ellenőrzésbe, ha pedig talál valamit, megkérdezi, javítsa-e?

laszlo.a.toth@googlemail.com esetleg futtassam chroot-olva a sérült gépen direktben?

Az fsck-t nem egészséges csatolt partícióra ereszteni, nem értem, mit akarsz chroot-olni?

laszlo.a.toth@googlemail.com

Egy másik, mőködő rendszerről elvileg az öszes elkészült logot elérem, csak nem tudom hogy mit keressek benne . . .

laszlo.a.toth@googlemail.com

lala2 Kaptam választ a TimeShift problémára. Azt írták hogy az rsync verzió ismert problémája.
vagy downgrade-elek vagy várok a javításra.
The source of the problem is something related in combination with rsync 3.2.7-0ubuntu0.22.04.2

"You can either downgrade and hold on to rsync 3.2.3-8ubuntu3
but not sure what of importance was fix in 3.2.7 or what else maybe relies on the newer version.
Or switch to the ubuntu timeshift PPA (upstream "unstable") Version:
https://launchpad.net/~teejee2008/+archive/ubuntu/timeshift/

And hopefully ubuntu's Timeshift gets a downstream patch or fixed "stable" version really soon. Seriously it is nearly 5 month now, otherwise someone should probably search for their ubuntu bugtacker and request a complete removal of their Timeshift because carry on with a broken version, in my opinion, is not much longer tolerable."

Nekem amíg a rendszer nem indul el, teljesen mindegy.

laszlo.a.toth@googlemail.com

és ez lehet mondjuk chroot-olt környezetből kiíratni mondjuk egy file-ba? Gondolom elég sokat kel majd olvasni . .

meskobalazs

laszlo.a.toth@googlemail.com

Kiírathatod fájlba is, csak minek? Tudniillik eleve abban van, csak bináris. Ha csatolod a fájlrendszert mondjuk az /mnt/valami alatt, akkor így tudod megnyitni:

journalctl --directory=/mnt/valami/run/log/journal/<gépazonosító>

A gépazonosító valamilyen hexa számsorozat lesz, de egy lesz belőle, szóval megtalálod.

Ha ki akarod vele íratni szövegesen, akkor csak irányítsd át egy fájlba, pl. journalctl [...] > system.log.

laszlo.a.toth@googlemail.com

chroot-olva nem talál semmit:
laci@Sanyika:/mnt$ sudo chroot /mnt /bin/bash
root@Sanyika:/# journalctl -xb
-- No entries --
root@Sanyika:/#

klt

laszlo.a.toth@googlemail.com sudo chroot /mnt /bin/bash

Ezt mit csinálna?

laszlo.a.toth@googlemail.com Csináltam pár fotót a logokról,

Szó szerint fotó?
Szöveges (kereshető) formában nem jó?
És amúgy hol vannak?

laszlo.a.toth@googlemail.com

Szervusztok,
Csináltam pár fotót a logokról, amikor a kernelt be akarja tölteni az op. rendszer. Láttatok már ilyet?
Ki tudja ezeket az üzeneteket értelmezni? Az ubuntu.com/support fizetős . . .

laszlo.a.toth@googlemail.com

klt dehogynem, szöveg file-ban a legjobb. te tudsz esetleg olyat javasolni?
igen, mobillal készült fotó
csak chroot-olva üres a journalctl lista, rescue módban lekérdezve meg nem tudok semmit írható módon felmountolni hogy oda átirányitsam
recovery módban a mount parancs is hibaüzenetet ad, lásd fenti üzenet

laszlo.a.toth@googlemail.com

becsatoltam az előző válaszomba, de látom hogy nem jelent meg.
most azt próbálom megtenni, hogy standard boot -> kibob rescue (és nem recovery!) módba
ott felmountolok egy olyan helyet ahová tudok írni és szöveg file-ba irányítom a journalctl listát

laszlo.a.toth@googlemail.com

rescue módban az alábbi megszorítások élnek (recovery módban összetörik a képernyő)

nincs hálózat, így nem tudom a csomag listát apt-get-tel frissíteni -> ez bug vagy feature itt?
fdisk -l listázza a disk partíciókat, de
nincs pld. mount parancs sem
hibaüzenet: mount: lib/x86_64-linux-gnu/libmount.so.1 'MOUNT_2_38' not found
vagyis a journalctl listát nem tudom kiírni sehová
hogy tudok szert tenni hálózatra, vagy elemzéshez a journalctl -xb parancsot kiírni file-ba?

a mester

laszlo.a.toth@googlemail.com És olyankor a kopasz mount parancs mit mutat?

csuhas32

klt
+1 az fstab-ra.

lala2

klt
Mikor evekkel ezelott fsck-t futtattam terminalbol -y kapcsolo nelkul, megfogadtam hogy soha tobbe!
Annyiszor kert megerositest, (y) hogy mire a vegere ert, elzsibbadt az ujjam hegye.

laszlo.a.toth@googlemail.com

klt Nos, íme bulkid parancs eredménye és az fstab file tartalma.
Ahogy látható 2 SATA disk-em van (sda, sdb) és egy SSD meghajtóm (nvme0n1)
mivel semmit ne formáztam, cseréltem így UUID-k meg is egyeznek. (ez várható is volt) Az sdb1 partíció mountolását, amint elkezdett nem bootolni a gép, óvatosságból kiszedtem.

root@Sanyika:/# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/nvme0n1p2 during installation
UUID=07416fa3-8f35-49ac-b51f-63c874ad8f6d /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=84EE-38A9  /boot/efi       vfat    umask=0077      0       1
# /home was on /dev/nvme0n1p4 during installation
UUID=5c647be0-ae21-4129-8743-13d8d6d15260 /home           ext4    defaults        0       2
# swap was on /dev/nvme0n1p3 during installation
UUID=4b0d2250-acaf-487c-bd02-e79b1ff5ae21 none            swap    sw              0       0
# swap was on /dev/sda3 during installation
UUID=ebc1af76-fb40-401a-9f68-0af842eba76b none            swap    sw              0       0
#storage disk mount
#UUID=e3c02eb5-8d30-4dc6-8873-3284c809ddc4 /mnt/storage ext4 defaults 0 2
root@Sanyika:/#

root@Sanyika:/# blkid
/dev/nvme0n1p3: UUID="4b0d2250-acaf-487c-bd02-e79b1ff5ae21" TYPE="swap" PARTUUID="a1b97666-3c54-43f2-a789-b69d445bd5f3"
/dev/nvme0n1p1: UUID="84EE-38A9" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="7d9def40-162e-4036-9753-98eadf5473d7"
/dev/nvme0n1p4: UUID="5c647be0-ae21-4129-8743-13d8d6d15260" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="d6dd08ff-c38a-4236-97a0-dbb36aec83b6"
/dev/nvme0n1p2: UUID="07416fa3-8f35-49ac-b51f-63c874ad8f6d" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="03fee6b8-6acd-412b-a45c-bb72ce46eca9"
/dev/sdb1: UUID="e3c02eb5-8d30-4dc6-8873-3284c809ddc4" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="storage" PARTUUID="ca71652a-cf1f-4d72-bd9f-e4fc37e03e53"
/dev/sda4: UUID="a55cf807-bdcf-416c-8e9e-aba7ab49f22c" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="712b67be-4bac-4d2d-9302-1428a7dad561"
/dev/sda2: UUID="1f97010f-13b7-436b-a0de-40097f69067c" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="c5948c20-20fb-4bb3-b792-417158c5f5f9"
/dev/sda3: UUID="ebc1af76-fb40-401a-9f68-0af842eba76b" TYPE="swap" PARTUUID="71d9d539-cf7c-42d9-85a0-29fbe14fd990"
/dev/sda1: UUID="DF04-2652" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="35d0a003-785c-443f-aba1-47b4cdfe3b01"
root@Sanyika:/# blkid > /root/bulkid

A shell-ből ki tudok lépni az exit-tel. Amint CtrlAlt+Del-t nyomok az újraindításhoz:

[SKIP] Ordering cycle found skipping ACPI events check

Ennek van jelentősége?

klt

lala2 Egyszer kellett volna A-t (all) nyomni - az adott típusú kérdésre, akkor többet azt nem teszi fel.
🙂

csuhas32

lala2

Egyszer én is megszívtam így, magam sem ismertem ezt az „A” opciót (egészen eddig, nagy kérdés, hogy megjegyzem-e).
A Ctrl+C-vel a folyamatot megszakítani és újra kiadni az fsck-t y kapcsolóval nem lett volna járható út, vagy ez csak egy grafikus felületen vitézkedő huszár képzelgése a karakteres világról?

a mester

klt PEBKAC

lala2

klt
Ez az amit ott es akkor nem tudtam. 🙂

Következő oldal »