taanegl

taanegl, 1 year ago (edited 1 year ago)

Firstly, check the logs directly to get a more concise error that we can analyse. journalctl is the standard systemd logging client you can use in the terminal. By specifying the unit (units can be socket files, timers, services) you can get logs specifically for said unit.

<span style="color:#323232;">journalctl -u udisks2.service
</span>

You can also specify binary, if said binary logs to journalctl, like so (if the binary path exists):

<span style="color:#323232;">journalctl /usr/lib/udisks2/udisksd
</span>

You can also check kernel messages (dmesg) by using the -k flag, like so:

<span style="color:#323232;">journalctl -k
</span>

You can utelize flags such as -e to scroll to the end of a journal, -f to follow a journal in realtime and utelize the -p flag to set priorities like error, crit, warning (-o error) and others to filter away common journal entries so you don’t have to scroll through every line in the log.

Secondly, and this is gonna sound weird, but reboot into windows twice. The first time you boot windows run diskchk on the partition(s) in terminal/powershell/command as administrator. If it tells you it needs to do an offline scan, reboot and you’ll see an offline diskchk screen on boot before login. If not, reboot again into windows anyways, and then reboot into Linux.

The reason is that NTFS has a weird failsafe flag that NTFS on Linux considers a no-go, and it’s usually set if the system crashes more than twice, but not always. If Linux NTFS drivers see the flag, it won’t mount as a precaution. The only way to reset the flag is to reboot in windows twice. Not once, not three times, but twice.

This might be outdated info, but that was the fact some years ago. There might be a way to fix it with modern day Linux, but I don’t know, especially when I have no direct and informative errors to go by.

journalctl is your friend :)

taanegl, 1 year ago

Generally speaking, and I’m not talking about your Raspberry Pi’s, but even there we find some limitations for getting a system up and booting - and it’s not for lack of transistors.

But say if you take a consumer facing ARM device, almost always the bootloader is locked and apart of some read only ROM - that if you touch it without permission voids your warranty.

Compare that with an x86 system, whereby the boot loader is installed on an independent partition and has to be “declared” to the firmware, which means you can have several systems on the same machine.

Note how I’m talking about consumer devices and not servers for data centres or embedded systems.