Recovering from a Linux Mint crash

Topic

New Reply

Recently my Linux Mint 19.1 laptop wouldn’t boot up after running fine the day before.  I explored a number of ways to find out why, and tried various cures with no luck. The details are at the end of the thread directly below this one.  So, I decided to reinstall the program from scratch and things are almost back to normal, except all of the updating that now needs to be done since the drive got wiped when I reinstalled.  The laptop is running fine now.

I’m now wondering what is the most efficient way to update from the old kernel 4.15.0-20, and 235 updates.  I would like to go back up to kernel 4.15.0-123 where I was before the crash.  I’m wondering if installing the new kernel 4.15.0-124 first would maybe save me some time downloading and installing all those updates.  Do kernel updates include previous major security and software updates or am I stuck with having to do them all separately?  I think I know the answer to that question but just thought I’d ask to be sure.

At any rate, the current kernel update in the Update Manager is 4.15.0-124 and if there are no other security or software updates in with the kernel then it might be better to get the newer current kernel.  One other question – is there a certain proper way or sequence to install all those updates?  Can I assume that the ones at the bottom are the oldest (since they’re not dated)?  Any help anyone can offer me will be greatly appreciated.

Being 20 something in the 70's was so much better than being 70 something in the insane 20's

Reply | Quote

Replies

I’ve installed Mint 19.2 three times, Ubuntu 16.04 two times, and Ubuntu 18.04 one time, all of which were clean installations. Every time, there were a bunch of updates (probably a couple hundred or so). I just let selected all the updates, clicked on ‘Install updates’ and let the Update Manager do its thing. It always worked just fine and in what I considered a reasonable amount of time – one to two hours.

I would hesitate to try and outsmart the Update Manager, without knowing more about the individual patches and any interdependencies that might exist among them. But that’s just me. You may well be more knowledgeable than I am.

1 user thanked author for this post.

Charlie

Reply | Quote

Sorry I/we could not be of more help, but I can understand running out of patience and just doing it. Once we got to the point of there being a LVM (logical volume manager) in the mix, we were beyond my sphere of experience, but others here use them and know much more about them than I do (my knowledge consists mainly of knowing that they exist).

Just remember that restoring a backup is much easier than reinstalling everything. Mint makes it easy with Timeshift integration, and Timeshift is usually all you need to get back up and running if there is some kind of error with updates. It’s like Windows system restore, but is (in my experience) far more robust. I’ve had system restore fail more times than it worked in my Windows days, but Timeshift has never failed me.

Charlie wrote:

I’m now wondering what is the most efficient way to update from the old kernel 4.15.0-20, and 235 updates. I would like to go back up to kernel 4.15.0-123 where I was before the crash. I’m wondering if installing the new kernel 4.15.0-124 first would maybe save me some time downloading and installing all those updates. Do kernel updates include previous major security and software updates or am I stuck with having to do them all separately? I think I know the answer to that question but just thought I’d ask to be sure.

It’s not like Windows, where there are rollup and cumulative updates. Each package is updated individually in Mint, so updating to the newest kernel gets you all the changes in the kernel up to that point, but nothing else.

There is no more efficient way than just letting ‘er rip with the updates. I’d go for the newest kernel too… there’s no reason I saw to believe it was a bad kernel update that caused the issue. It could have been anything, and the warning you mentioned about the LVM thing saying it was “bad” makes me think that’s the most likely cause, not the kernel itself (though the kernel, being the heart of everything, could conceivably be at fault… it’s just not that likely). If you’re concerned, you can create a Timeshift snapshot before accepting the updates, so you can go back if something goes wrong. Then, if/when the updates are all successfully done, you can create another one.

Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)

1 user thanked author for this post.

Charlie

Reply | Quote

What messages did you get (if any) when you tried to boot? I had two boot issues in the last two months with Linux Mint 20. i ended up in Busybox with confusing choices and had to use a live USB and research the problem online? I tried a Timeshift restore the first time and it didn’t work and eventually used Fsck on my harddrive (dev/sda2) and got back to my desktop.

i am not sure what caused the first issue but I played a game in .Wine for hours and then went into Firefox but it was sluggish so I tried to check System Monitor but it wouldn’t load and neither would Logs. When i tried Firefox again it wouldn’t load so I rebooted the computer and ended up in Busybox and it mentioned inodes (?) and orphan files. I hadn’t updated or deleted anything around that time so don’t know what got corrupted.

The second time it happened may be related to some security updates i had done during previous boot session. i updated and ran my comp for hours afterwards with no problems. On boot the next day I got stuck in Busybox again but Fsck fixed things and I got to my desktop.

i upgraded from 19.3 so old snippets of files may be what corrupted my system as orphan files were mentioned.

Reply | Quote

I didn’t get any messages while trying to boot.  All I got was a Linux Mint Logo and then a black screen with a cursor blinking in the upper left corner.  For more information I suggest if you haven’t already done it, go to the thread “Is this patch, aka “ubuntu-system-adjustments”, legit? (Linux Mint)“.  Towards the end of that thread is where I talk about all the things I tried and messages I got.

Being 20 something in the 70's was so much better than being 70 something in the insane 20's

Reply | Quote

Ascaris wrote:

I’d go for the newest kernel too… there’s no reason I saw to believe it was a bad kernel update that caused the issue.

Oh and the thing about kernels… 4.15.0-whatever are all just “security and bugfix only” on top of 4.15 and unlikely to cause problems you didn’t have already.

However… if some of your hardware is newer than what is well-supported by the drivers in original 4.15 (released 28 January 2018), you might want to get a newer kernel.

So there should be a “hwe” kernel alternative (for “hardware enablement”) available in the packages.

I’m on Xubuntu 18.04, I see 4.15.0-124 as the newest “generic” kernel and 5.4.0-56 as the newest “hwe” kernel in the Ubuntu repositories. 5.4 branch is from November 2019 and the -56 is security and bugfix on top of that.

What I’m actually running right now is 5.10-rc6 … as in a mainline preview/testing release candidate kernel, may never be packaged into Ubuntu/Mint repositories officially and the rc versions certainly won’t. (One of my sons took an elective course on PC hardware and built something with an AMD B550 chipset, and even 5.4 is just too old for that motherboard. 5.9 didn’t yet have everything working either but 5.10 does seem to have.)

Charlie wrote:

current kernel

… yeah, that can be a bit confusing with mainline (Linus himself) and distribution kernels (whatever is packaged by Ubuntu, Mint, Red Hat, etc…). Mainline “current” is 5.9 right now.

firemind wrote:

i am not sure what caused the first issue but I played a game in .Wine for hours and then went into Firefox but it was sluggish so I tried to check System Monitor but it wouldn’t load and neither would Logs. When i tried Firefox again it wouldn’t load so I rebooted the computer and ended up in Busybox and it mentioned inodes (?) and orphan files. I hadn’t updated or deleted anything around that time so don’t know what got corrupted.

There usually are at least some temporary files open when the system is running, and those can cause things like this on a crash or hard reset. Running a fsck in simple unattended check mode should be automatic because of that, but also there’s a limit to what simple unattended mode will fix.

So, the part where things would refuse to load before the reboot… means there was an actual problem somewhere. Most likely place to find it afterwards would be /var/log/syslog and its older versions. (Usually those logfiles get rotated and older versions compressed, so “syslog” is the constantly updating one, then “syslog.1” is the previous one, then “syslog.2.gz” is the one before that and compressed, etc.)

Looking in the logfiles is of course only helpful if your system didn’t lose the ability to write to disk when the problem occurred. Putting disks into read-only mode is a common way to react to disk-related errors, at least stops corrupting the on-disk data further…

So if your system starts to exhibit symptoms like that again but you retain ability to run commands, please use the “dmesg” command to read the kernel message buffer directly. That’s where the error messages are before they’re written to the logfiles.

2 users thanked author for this post.

firemind, Charlie

Reply | Quote

Well things seem to be okay and I’ve been back up and running for over a week after re-installing and doing the updates.  Keeping my fingers crossed and hoping this doesn’t happen again.  Thank all of you for your generous help.

Being 20 something in the 70's was so much better than being 70 something in the insane 20's

1 user thanked author for this post.

DrBonzo

Reply | Quote

Interesting thread. Could it have been the recent Grub update that created the issue you had?

I just did an relatively large update to my Ubuntu 18 netbook that I had not used in 2 months or so and lost the ability to boot. As I had I had been considering doing a clean Mint 20 install to bring mint to all our Linux devices, I decided to just do the planned change of OS, rather than try to fix the boot issue or do an Ubuntu re-install.

However, when I tried, the LiveUSB Mint-Cinnamon 20 told be the grub was corrupt on the SSD and offered to do a repair. I have read of the recent Grub update giving some issues. As I was considering salvaging the SSD and letting the netbook meet its maker as the AMD CPU has always been a bit of a PITA and as a netbook is a bit slow, both in Windows 7-64Pro and Ubuntu, I decided to let the repair rip and it worked. (I was surprised about the repair capability, as I did not have to interact with the process.)

Got Mint 20 installed and it looked OK, but I am not sure the new Cinnamon is as nice as 19.3. Time will tell.

The update also invited the return of the unwanted visitor glitch of the keyboard not working. Fortunately there is a virtual screen keyboard, but using it with a mouse is a slow process. After reviewing logs, I managed to get the keyboard working by disabling the trackpad which I never used. That trackpad issue has been an off and on issue in both Windows and Linux.

Sorry for the diverge, but the title reminded me of my Grub issue.

Glad you got it sorted.

1 user thanked author for this post.

Charlie

Reply | Quote

[Charlie]

A grub update was one of the first things I suspected.  I did a grub update the night before, and my laptop would not boot the next day.  But, I was able to use grub when trying to fix things and it seemed to do everything it’s supposed to do.  I got no indication from the Linux Live DVD that there was any grub corruption when I reinstalled Linux 19.1.  So the whole experience remains a mystery to me, and one I’m hopefully rid of for good.

Edit:  For reference, here’s my first post in another thread:  #2315694

Being 20 something in the 70's was so much better than being 70 something in the insane 20's

• This reply was modified 4 years, 5 months ago by Charlie.

Reply | Quote