Broken Bios, can't boot up laptop like I normally would.
- Login o registrati per inviare commenti
Hi there,
Just now I accidentally pulled the power chord out of my laptop while the battery was out, and while I was able to boot back into my home screen with some errors about not being able to use the applet, I wasn't able to boot back in again after rebooting it (hoping that it would fix the previous problem. And now I can't work on my laptop anymore.
I have skimmed through the logs to learn that my laptop failed to do so due to a broken BIOS. So I'm assuming I would have to flash the bios to make it run as normal again?
My laptop is a Lenova Thinkpad X200t which uses Libreboot.
I'm not sure how to go about this, I hoping it can be done with a simple usb drive with a Libreboot image.
I can't search for the link atm because I'm in a heavily censored country, so sharing the link as well as some tips would be most grateful.
Will provide photos of specific text logs soon
Thank you.
The BIOS lives protected in a flash chip on the board and was probably not affected by a loss of power in any way.
Possibly but that's what the log is saying and it still won't boot up normally in anyway.
If it's not the bios, then what else could it be? I'm just not sure what to do here.
I've taken photos of some parts of the log, I just need to decrease their file sizes before I can post them here for all to see.
That's a normal message; it does not mean there is a problem.. An explanation can be seen here - https://fedoraproject.org/wiki/Common_F12_bugs#iommu-problems
The very top of IMG_20240426_212748_0.jpg and IMG_20240426_212748_0.jpg and IMG_20240426_212915.jpg and IMG_20240426_213140.jpg mentions problems with fsck. That seems to suggest filesystem corruption. That seems more likely given the unclean shutdown. It may be useful to run fsck manually, while booted from a live Trisquel USB, to see if the corrupted filesystem can be repaired. If it cannot be, the next step would be to reformat and reinstall.
The most latter, I had recently been expecting that I had to do.
I'll take your advice and try and repair the file system.
Either way, I just so glad that the BIOS and motherboard is okay.
Thank you very much @jxseld
Hi jxself,
I followed your advice and booted a live usb distro on my device. After using fsck and e2fsck using alternative superblocks (e2fsck -b 8193 /dev/sda (and using '32768'), I get the following response in the terminal (see picture), and resulsts are the same.
Do you think there is anything else to tryout here to possibly repair or at least gain access to my files?
Why not just sudo fsck /dev/sda???
I that was the first thing I did before trying the alternatives. Still the same results.
Is the drive encrypted? It's necessary to decrypt it first so that it can be read.
If the superblock is indeed corrupt, you can try running e2fsck using an alternative superblock. Something like dumpe2fs /dev/sdaX | grep -i superblock (adjust the X) should give a list of superblocks.
It's an encrypted disk, yes but I had unecrypted from the gui window. Would I need to do the same within the terminal too. If so, will I need to run from root or superuser?
I still have access to the files if I run as admin/superuser, but I'm afraid that I'll only have access to those files I copied over until I run them as admin only (aka I won't be able to run them using them within apps)
Perhaps things are fine then. Still, try looking for other superblocks.
trisquel@trisquel:~ sudo dumpe2fs /dev/sda | grep -i superblock
dumpe2fs 1.46.5 (30-DEC-2021)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sda
Couldn't find valid filesystem superblock.
Found a gpt partition table in /dev/sda
trisquel@trisquel:~ sudo e2fsck /dev/sda | grep -i superblock
e2fsck 1.46.5 (30-DEC-2021)
e2fsck: Cannot continue, aborting.
Is there something I'm doing wrong? Am I suppose to unlock the encrypted Hdd via the terminal?
Sorry, I'm completely new in this area.
I am a translator!
/dev/sda is a whole disk, including the partition table, so fsck probably can't work on that.
A filesystem is usually in a partition (the filename in /dev may be sda1, sda2 or something of that kind), in an encrypted device or in a logical volume. "lsblk --fs" should tell you how things look on your disk and the corresponding names.
Okay, I'm getting closer now.
Already made a backup, and checked all of the file names of my hdd.
I'm assuming it's the sda3 cause it's ext4 and it's the only one that has found a file system inside.
...but something's telling me that it's sda4 (the encrypted part of the disk)
Took a photo (see attachment)
And these are the results:
trisquel@trisquel:~ sudo dumpe2fs /dev/sda3
dumpe2fs 1.46.5 (30-Dec-2021)
Filesystem volume name:
Last mounted on: /media/trisquel/27f3c56b-9772-471d-a1d7-0d0171e776b3
Filesystem UUID: 27f3c56b-9772-471d-a1d7-0d0171e776b3
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 109536
Block count: 437504
Reserved block count: 21875
Overhead clusters: 16356
Free blocks: 363167
Free inodes: 108889
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Reserved GDT blocks: 213
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 7824
Inode blocks per group: 489
Flex block group size: 16
Filesystem created: Mon Jul 31 15:31:17 2023
Last mount time: Sun Apr 28 12:22:39 2024
Last write time: Thu May 2 17:01:55 2024
Mount count: 482
Maximum mount count: -1
Last checked: Mon Jul 31 15:31:17 2023
Check interval: 0 ()
Lifetime writes: 2219 MB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 32
Desired extra isize: 32
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 554bfb55-c1f3-4829-87a8-53ee3d2ef12d
Journal backup: inode blocks
Checksum type: crc32c
Checksum: 0x2761e12d
Journal features: journal_incompat_revoke journal_64bit journal_checksum_v3
Total journal size: 32M
Total journal blocks: 8192
Max transaction length: 8192
Fast commit length: 0
Journal sequence: 0x000012e6
Journal start: 0
Journal checksum type: crc32c
Journal checksum: 0xf5a9bc6a
Group 0: (Blocks 0-32767) csum 0x01ba [ITABLE_ZEROED]
Primary superblock at 0, Group descriptors at 1-1
Reserved GDT blocks at 2-214
Block bitmap at 215 (+215), csum 0xb4a8edb9
Inode bitmap at 229 (+229), csum 0x7bfb9d64
Inode table at 243-731 (+243)
25661 free blocks, 7178 free inodes, 7 directories, 6858 unused inodes
Free blocks: 7107-32767
Free inodes: 32-38, 42-68, 360-363, 682-963, 967-7824
Group 1: (Blocks 32768-65535) csum 0x9907 [ITABLE_ZEROED]
Backup superblock at 32768, Group descriptors at 32769-32769
Reserved GDT blocks at 32770-32982
Block bitmap at 216 (bg #0 + 216), csum 0xc8694a23
Inode bitmap at 230 (bg #0 + 230), csum 0x8a85a7e3
Inode table at 732-1220 (bg #0 + 732)
13598 free blocks, 7823 free inodes, 1 directories, 7823 unused inodes
Free blocks: 32983-33663, 33703-33727, 33767-34047, 34084-34111, 34132-34143, 34164-34175, 34195-34207, 34238-34239, 34271, 34303, 34816-35199, 35264-35295, 35324-35327, 35456-35839, 36864-37382, 37386-37887, 37889-38399, 38433-38463, 38484-38527, 38563-38911, 40960-41759, 41791, 41838-41855, 41876-41887, 41910-41919, 41951, 41982-41983, 42569-43007, 43081-45055, 49662-51199, 57846-58367, 58878-59391, 60193-61439, 61475-61535, 61564-61695, 61734-61759, 61784-61791, 61865-61887, 61918-61919, 61950-62975, 63008-63583, 63608-63615, 63652-63679, 63710-63711, 63742-63743, 63785-63807, 63838-63839, 63869-63871, 63933-63935, 63980-64000, 64199-64513, 65094-65535
Free inodes: 7826-15648
Group 2: (Blocks 65536-98303) csum 0xbd7b [INODE_UNINIT, ITABLE_ZEROED]
Block bitmap at 217 (bg #0 + 217), csum 0xb2d937db
Inode bitmap at 231 (bg #0 + 231), csum 0x00000000
Inode table at 1221-1709 (bg #0 + 1221)
8865 free blocks, 7824 free inodes, 0 directories, 7824 unused inodes
Free blocks: 65536-67071, 67200-67612, 67940-69631, 77111-77823, 86016-87871, 87901-88128, 88397-90111, 97592-98303
Free inodes: 15649-23472
Group 3: (Blocks 98304-131071) csum 0x5913 [INODE_UNINIT, ITABLE_ZEROED]
Backup superblock at 98304, Group descriptors at 98305-98305
Reserved GDT blocks at 98306-98518
Block bitmap at 218 (bg #0 + 218), csum 0xedf582c1
Inode bitmap at 232 (bg #0 + 232), csum 0x00000000
Inode table at 1710-2198 (bg #0 + 1710)
20288 free blocks, 7824 free inodes, 0 directories, 7824 unused inodes
Free blocks: 98519-100351, 103173-104447, 113892-131071
Free inodes: 23473-31296
Group 4: (Blocks 131072-163839) csum 0xdcfd [INODE_UNINIT, ITABLE_ZEROED]
Block bitmap at 219 (bg #0 + 219), csum 0x42aec813
Inode bitmap at 233 (bg #0 + 233), csum 0x00000000
Inode table at 2199-2687 (bg #0 + 2199)
29928 free blocks, 7824 free inodes, 0 directories, 7824 unused inodes
Free blocks: 131072-145407, 148248-163839
Free inodes: 31297-39120
Group 5: (Blocks 163840-196607) csum 0x5181 [INODE_UNINIT, ITABLE_ZEROED]
Backup superblock at 163840, Group descriptors at 163841-163841
Reserved GDT blocks at 163842-164054
Block bitmap at 220 (bg #0 + 220), csum 0xb5f8bc43
Inode bitmap at 234 (bg #0 + 234), csum 0x00000000
Inode table at 2688-3176 (bg #0 + 2688)
32553 free blocks, 7824 free inodes, 0 directories, 7824 unused inodes
Free blocks: 164055-196607
Free inodes: 39121-46944
Group 6: (Blocks 196608-229375) csum 0x369b [INODE_UNINIT, ITABLE_ZEROED]
Block bitmap at 221 (bg #0 + 221), csum 0x2e5bf7dc
Inode bitmap at 235 (bg #0 + 235), csum 0x00000000
Inode table at 3177-3665 (bg #0 + 3177)
24576 free blocks, 7824 free inodes, 0 directories, 7824 unused inodes
Free blocks: 204800-229375
Free inodes: 46945-54768
Group 7: (Blocks 229376-262143) csum 0x0e5a [INODE_UNINIT, ITABLE_ZEROED]
Backup superblock at 229376, Group descriptors at 229377-229377
Reserved GDT blocks at 229378-229590
Block bitmap at 222 (bg #0 + 222), csum 0xb5f8bc43
Inode bitmap at 236 (bg #0 + 236), csum 0x00000000
Inode table at 3666-4154 (bg #0 + 3666)
32553 free blocks, 7824 free inodes, 0 directories, 7824 unused inodes
Free blocks: 229591-262143
Free inodes: 54769-62592
Group 8: (Blocks 262144-294911) csum 0x9532 [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
Block bitmap at 223 (bg #0 + 223), csum 0x00000000
Inode bitmap at 237 (bg #0 + 237), csum 0x00000000
Inode table at 4155-4643 (bg #0 + 4155)
32768 free blocks, 7824 free inodes, 0 directories, 7824 unused inodes
Free blocks: 262144-294911
Free inodes: 62593-70416
Group 9: (Blocks 294912-327679) csum 0xdc50 [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
Backup superblock at 294912, Group descriptors at 294913-294913
Reserved GDT blocks at 294914-295126
Block bitmap at 224 (bg #0 + 224), csum 0x00000000
Inode bitmap at 238 (bg #0 + 238), csum 0x00000000
Inode table at 4644-5132 (bg #0 + 4644)
32553 free blocks, 7824 free inodes, 0 directories, 7824 unused inodes
Free blocks: 295127-327679
Free inodes: 70417-78240
Group 10: (Blocks 327680-360447) csum 0x258f [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
Block bitmap at 225 (bg #0 + 225), csum 0x00000000
Inode bitmap at 239 (bg #0 + 239), csum 0x00000000
Inode table at 5133-5621 (bg #0 + 5133)
32768 free blocks, 7824 free inodes, 0 directories, 7824 unused inodes
Free blocks: 327680-360447
Free inodes: 78241-86064
Group 11: (Blocks 360448-393215) csum 0x54ac [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
Block bitmap at 226 (bg #0 + 226), csum 0x00000000
Inode bitmap at 240 (bg #0 + 240), csum 0x00000000
Inode table at 5622-6110 (bg #0 + 5622)
32768 free blocks, 7824 free inodes, 0 directories, 7824 unused inodes
Free blocks: 360448-393215
Free inodes: 86065-93888
Group 12: (Blocks 393216-425983) csum 0x30e2 [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
Block bitmap at 227 (bg #0 + 227), csum 0x00000000
Inode bitmap at 241 (bg #0 + 241), csum 0x00000000
Inode table at 6111-6599 (bg #0 + 6111)
32768 free blocks, 7824 free inodes, 0 directories, 7824 unused inodes
Free blocks: 393216-425983
Free inodes: 93889-101712
Group 13: (Blocks 425984-437503) csum 0xb1ad [INODE_UNINIT, ITABLE_ZEROED]
Block bitmap at 228 (bg #0 + 228), csum 0x3392294c
Inode bitmap at 242 (bg #0 + 242), csum 0x00000000
Inode table at 6600-7088 (bg #0 + 6600)
11520 free blocks, 7824 free inodes, 0 directories, 7824 unused inodes
Free blocks: 425984-437503
Free inodes: 101713-109536
trisquel@trisquel:~ sudo fsck /dev/sda3
fsck from util-linux 2.37.2
e2fsck 1.46.5 (30-DEC-2021)
/dev/sda3 clean, 647/109536 files, 74337/437504 blocks
Here they are, sorry for uploading so late.
It's not as convenient to reduce the file sizes without my laptop.
Okay, I've fixed sda3 and now the behavior changes and it still won't boot normally. (please see attached photo, red text at bottom).
I'm starting to think it's sda4 but whenever I use e2fsck or dumpe2fs it won't detect any file system.
'lsblk --fs' gives me this:
lsblk --fs
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
loop0
squash 4.0 0 100% /rofs
sda
└─sda4
crypto 2 da4881d0-1afd-4ed3-8427-d5efd8cce7c7
└─9c63fe4d-09d8-439e-bf0c-e45f1d6396a4
LVM2_m LVM2 aggsTt-oKZD-sDt3-rCrK-NqoB-Luil-Mi4Vy1
├─vgtrisquel-root
│ ext4 1.0 9873c771-bbbc-4938-91eb-b52f632e7a66
├─vgtrisquel-swap_1
│ swap 1 875466b0-3f94-4b46-9616-40cdf5ff6267
└─vgtrisquel-home
ext4 1.0 9c63fe4d-09d8-439e-bf0c-e45f1d6396a4
I'm just not sure how I am suppose to type out the command correctly.
'sudo dump2fs /dev/sda4/LVM2_m LVM2 | grep -i superblock' didn't work.
Something tells me that the filesystem is in vgtrisquel-home but I not sure.
Dammit, I was idiot.
I was suppose to use:
fsck /dev/mapper/vgtrisquel-home
Had fixed this ages ago though. One or two things need to be fixed but I've regained access and use of the OS and hard drive on my device.
- Login o registrati per inviare commenti