Warning: The root device is not configured to be mounted read-write!

[T-Flips]

Well, i agree that it doesn’t feel right. I guess there is still something wrong due to the hard reset, unfortunately. Maybe you need to take a deeper look into your disk(s).

@keybreak

smartctl --test=long /dev/sda

Please wait 272 minutes for test to complete

let it run when you have the time for it

@keybreak

Is this normal that fsck for 4 Tb disk takes…1,5 seconds

i have no experience with that, but i don’t think so. Did you run from a recovery shell / a live environment?

[2000]

You’re right, it would bug me too.

Regarding the fsck you ran manually. Did you actually repair anything?

Maybe try running fsck.ext4 -p to automatically repair or try to force a check with fsck.ext4 -f to mark the device as clean.
[Edit] Oh, and you should unmount the device before checking or repairing file systems. But you probably know that.

[keybreak]

@T-Flips

i have no experience with that, but i don’t think so. Did you run from a recovery shell / a live environment?

From USB live environment

---

@2000

Regarding the fsck you ran manually. Did you actually repair anything?

Nope…Just ran extremely quick and nothing was found / fixed
Output was normal

@2000

Maybe try running fsck.ext4 -p to automatically repair or try to force a check with fsck.ext4 -f to mark the device as clean.

Thank you i’ll read man on those options and try it out!

@2000

Oh, and you should unmount the device before checking or repairing file systems. But you probably know that.

Yep, luckily fsck also warns you about it, because if you don’t you can loose data

[jonathon]

@keybreak

ran extremely quick and nothing was found / fixed
Output was normal

Might still be worth running with fsck -f so it runs a check even if the FS is marked as “clean”. -c (check for bad blocks) might also be useful, though that will take a while.

[keybreak]

Ok so i’ve ran fsck.ext4 -f for all drives:

1. It definitely actually runned this time, took at least some time (although pretty fast)

2. System disk was totally fine

3. On two of my 4 Tb storage drives (one of which was the one which i used to watch movie in VLC), i had been asked few times about:

   Inode <some number> extent tree (at level 1) could be narrower. optimize <y>?
   Inode <some number> extent tree (at level 2) could be narrower. optimize <y>?
   

   I’ve said y to everything, although from what i have read - it’s not a major error / problem.

   At the end both disks had message:

   ***** FILE SYSTEM WAS MODIFIED *****
   

4. After reboot still got the fscking message!

---

So i guess should try with -fc now…?
30% of system disk, so far (0/0/0 errors)

[keybreak]

Finished fsck.ext4 -fc for system drive, got:

***** FILE SYSTEM WAS MODIFIED *****

in the end, so it fixed something i guess

Guess what…
Yep, still got this fscking message on reboot!!

So that’s why systemd sucks…
(c) keybreak

[zangoku]

Are you dual-booting with Windows ?

[onyxnz]

Run a memtest from a live iso too; page faults in your RAM will fsck your harddisks.

[keybreak]

@zangoku
No, God forbid!
Only

@onyxnz
Will do, thx!
I had no idea that’s the case

[otherbarry]

Do you have a backup of your root file system?

File system corruptions are relatively rare, especially for ext4, but they can happen.

[keybreak]

@otherbarry

Do you have a backup of your root file system?

Only home, seems to be intact

@otherbarry

File system corruptions are relatively rare, especially for ext4, but they can happen.

Yeah…Well running fsck.ext4 -fc should have noticed that…hopefully?

---

Running Memtest86 with defaults “as is”, no errors found so far

[zangoku]

I was asking because it messes up with hard drives if you shut it down or restart pressing the actual buttons. I made a shortcut with a command that shuts it down without messing my drives in the start menu.

[keybreak]

I know, i know…Was unlucky enough to not enable [Tip] Enable Magic SysRq Key (REISUB) on exactly this machine

[keybreak]

Single pass for memtest should be enough?

[BONK]

Not to be captain obvious but you check your cabling yes?

[keybreak]

Meaning SATA?
Yep cap, and also if there would be a problem SMART would’ve been full of UltraDMA CRC error types, but there’s 0 (however i still need to do full long SMART check, will do after Memtest)

[onyxnz]

Yes, it would usually show up very quickly.

[keybreak]

Ok, RAM is fine, did full single pass

---

Going for that one next:

smartctl --test=long /dev/sda

Something tells me that will be wasted 272 minutes, but since we don’t have anything else for the time

[keybreak]

I was researching this errors which caused initial freeze and came to this russian part of arch:
https://archlinux.org.ru/forum/topic/20418/?page=1#post-238682

Here’s google-translation:

Well, he was right. But in theory, grep --color=auto smep /proc/cpuinfo should work, but I like cpuid better, although it’s a matter of taste.
The kernel supports these smap and smep technologies, and if they are also supported by cpu, then they can be disabled using the options: nosmap , nosmep - thereby disabling the supervisor mode … you can experiment in terms of changing the speed … you are unlikely to break who will be.

PS - I do not exclude that this supervisor had something to do with OOPS … something went wrong with the kernel and userspace memory areas

Supervisor Mode Execution Prevention (SMEP) is a technology developed by Intel to protect your computer from hacker attacks and other threats that use the so-called “supervisor mode”.
Supervisor mode is the privileged processor mode used by the operating system kernel. This mode is also called kernel mode. The opposite is user mode, in which user applications run.
By exploiting kernel mode vulnerabilities, an experienced hacker is able to gain complete control over the system. However, if SMEP is used on a computer, user applications lose the ability to perform privileged operations, such as accessing I / O ports that control processor registers, etc. In addition, the memory used in kernel mode is protected from user mode access.
Any attempt to execute code in the memory of the user application leads to a page error and the computer “falls out” into the blue screen of death (without completing the actions required by the attacker).

EDIT 1 - I’ll add the difference between smep and smap right away - let everything be in one place

Although SMEP significantly complicates the task of hacking a system, it still does not guarantee complete protection. Therefore, later (in processors of the Broadwell architecture), in order to improve security and protect against vulnerabilities not addressed by SMEP, SMAP (Supervisor Mode Access Prevention) technology was additionally implemented. It prevents unauthorized use of supervisor mode from writing to and reading from memory, while SMEP only prevents this code from being executed.

So…
My CPU is Intel i7-4770k

Could very well be that stupid anti-hacker Intel crap

Should try

cpuid -1 | grep -i SMAP
cpuid -1 | grep -i SMEP

or

grep --color=auto smap /proc/cpuinfo
grep --color=auto smep /proc/cpuinfo

after running full smart, what do you guys think about that info?

Yep, i have smep…So if i add nosmep to grub and reboot, then remove it i guess it should work, will try it out later

[keybreak]

smartctl --test=long /dev/sda

have wasted 272 minutes, disk is fine

---

Tried adding nosmep to grub - still fscking message!

Can somebody tell me what’s that all about?!