While configuring the Sangoma UC 60 I had an interruption and now it won’t finish booting. I have attached a screenshot of the booting when it stops. Can someone help and explain what to do to fix my error?
Boot a ‘recovery’ or ‘live’ linux iso image and run fsck manually on /dev/sda2 as suggested ( it can’t be run on a mounted filesystem)
dicko, I am a noob with this, can you walk me through this? I was running ver 13 and also need to update to latest version so this seems like a good time to do it.
You need to repair the corrupted file system, download any linux iso that supports a live desktop, burn it to a usb stick and have your bios boot that by preference, when you get a desktop, open a terminal and
fsck /dev/sda2
answer yes to every question until completion , then remove the usb and reboot
my version of the UC 60 does not have a usb boot option in the bios for some reason.
Then call Sangoma support.
Your system clock is wrong.
1 Like
Although, if the disk is physically OK, this should result in a well formed file system, it is unlikely to be complete and what is left might not be correct. If there is anything important on it that cannot be restored, I’d suggest getting Linux expert on board, or at least trying to mount it readonly and copy critical files elsewhere. Typically lack of completeness is survivable, but, if the disk has two files allocated in the same space, one of them will be removed and the remaining one may have a mixture of blocks from both files.
At the very very least, I would run fsck -n on it, which answers no to everything, to get an idea of how much is actually broken.
Hopefully the inconsistency is just the date, in which case setting the hardware clock and then rebooting should remove the symptom.
Probably a discharged cmos battery but that is a red herring, a booted system will reset the software clock after the network is up. Repairing the FS is only possible after an OS is operational and likely on this hardware m it is rooted on /dev/sda2 he is in a Catch-22. Filesystem corruption is not clock dependent, nor is journal recovery, he has an ext4 filesytem, the hardware might well be fine but the inconsistencies need a fsck that is not itself corrupted
(What does your 'lack of completeness" mean here? man fsck ?)
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.