Linux Lite Forums
Software - Support => Updates => Topic started by: LarryB1607 on January 05, 2022, 01:54:12 PM
-
I have LL on an external HDD. When I now try to boot I get the GRUB menu and let it default to Ubuntu. Instead of going to the LL login screen, the system hangs up. Part of the error message say something about a controller and that the USB device was not recognized. I got major updates yesterday that looked like Ubuntu version updates. Not sure where to proceed from here. I might have a timeshift backup, but not a very recent one and if I cannot boot into LL, is kind of tough to run Timeshift. I will check to see if I have a backup on other media.
-
I tried to boot again and this time I chose Advanced mode and went back to the last version which I believe was 5.4.91. The version listed above this was 5.4.92 which I think might be the new version giving me issues. In the options, there was a recovery mode listed for both versions. Should I try the recovery mode for 5.4.92 and what do I do there or should I do something else? I am able to boot normally into version 4.5.91.
Thanks
-
The update was 5.4.0.92.96 replacing 5.4.0.91.95
If 5.4.0.92.96 is causing your problem you have no option but to stick with 5.4.0.91.95 for the time being. The only point of retrying 5.4.0.92.96 would be to make an accurate record of the error messages so that you can search for the issue and see if there is a fix or a bug report.
GRUB can be set to remember your last choice, so if you selected 5.4.0.91.95 and it works, you don't have to choose each time.
Having been bitten by a similar issue (in which a kernel change stopped firefox working), if an update includes kernel or related changes, I now cancel the process and run timeshift before proceeding.
-
Thanks for the reply stevef. I noticed that grub used my choices from yesterfay so I did not have to redo them which was nice. Looks like I need to do a Timeshift backup on the config that is working. I checked updates yesterday and they included some strange language. Here is one of them: command-not-found INSTALLED: 20.04.4 AVAILABLE: 20.04.5. The Python update also had the command-not-found line with it. A bunch more updates today, but I am going to refrain until I get a backup.
-
I made a backup of 5.4.0-91. A few days later, 5.4.0-94 came out so I decided to try it and it seemed to work. once or twice. Then When I tried booting, I got a similar error. I then tried the recovery mode and it was still running after about 2 hours. I did not know if it was going to take another 5 minutes or 5 hours+ so I stopped it. After another failed boot I decided to try and do a recovery, but I do not have Linux on a USB stick anymore. I tired another boot and it worked. No inkling of whether it will continue to work in the future. The error message seemed like a lot to write down, especially with all of the numbers included in it. I also not longer have the option of running 5.4.0-92 anymore at boot. I did remove 5.4.0-93 which was the problematic one. I still see 5.4.0-92 in the list of kernels that can be removed. Not sure what my next move should be, I would like to stay current with updates but the sporadicness of my current situation is not very enjoyable.
Any recommendations would be appreciated. Thanks
-
Recovery mode (for any version) boots the system with minimal 'extras'. It should not take long to boot. If your problem is related to a specific kernel rather than the 'extras', then recovery mode is likely fail in the same way as a full boot but noting the point at which it ails may help understanding.
A bit confused about what has changed since January 6th.
Your first posts implied that you only had problems after moving to 5.4.0.92.96 on January 4th and that reverting to 5.4.0.91.95 had fixed things.
Is that correct ?
How long did you stay with 5.4.0.91.95 after January 6th and was it reliable ?
Do you still have the option to boot using 5.4.0.91.95 ?
-
Sorry about any confusion. As 4 attempted boots today have failed I am going to install an older version of LLOS and then attempt to use Timeshift to restore my latest backup. When I boot now, I do NOT have any other choices than the one listed. It is this one and the previous kernel that have rendered this useless. I get an error that starts with Busybox and ends with (initramfs)
-
The dates of recent kernel changes on my system have been
5.4.0-91 Nov 30th 2021
5.4.0-92 Jan 5th 2022
5.4.0-94 Jan 11th 2022
I do not understand how the option to boot 5.4.0-91 which you had available on Jan 5th has disappeared.
Did you run any apt remove commands or the Lite Tweaks Kernel Remover at all in the meantime ?
Provided your timeshift image was made on a good working system your plan sounds ok. That would be while you were reverted to 5.4.0-91 using GRUB, though your first post of Jan 16 talks about making a back up of 5.4.0-92 (which is partly why I am confused). Obviously you will need to keep the timeshift archive safe through any changes you make while reverting to the older source.
If it works reliably, GRUB can be set to always boots the working kernel. But that is not a great idea so you will need to know what the error actually is so that you can search for the issue and check for bug reports/fixes in subsequent kernels.
I am struggling to come up with a kernel issue scenario in which it can work intermittently so make sure the system boots reliably on whatever solution you come to.
-
Well, I guess I sometimes get confused by the updates. I believe I mentioned that when I installed 5.4.0-94 and it seemed to be working, I used kernel remover and removed 5.4.0-92. I did not remove 5.4.0-91 and it is still listed in the kernels to remove. However all that is listed is 5.4.0-91 generic and the other 2 items associated with kernels is not there. I only removed the items matching 5.4.0-92. Tried several times to make a new live USB without success. Fortunately my 5th time trying to boot 5.4.0-94 was successful so I can hopefully run Timeshist.
-
It appears that I successfully restored 5.4.0-91. I see that there are a bunch of updates. Included in the list is the kernel 5.4.0-94. Is there some way I can selectively choose the updates or do I have to take them all? thanks
-
That's good news.
There is a facility for apt to hold back updates which can be applied to kernel - any package in the hold list does not get updates so is effectively frozen.
But as you can keep multiple kernels on your system and use GRUB to selectively boot them I'd go with letting any new kernel downloads but using GRUB to keep booting 5.4.0-91 for the time being as you seem to have had problems with both 5.4.0-92 and 5.4.0-94
When a new kernel comes you can try it once and if it doesn't work switch back to the working kernel using GRUB.
-
Thanks stevef, that is exactly what I was thinking now that I have a working kernel back.
-
Trying to run following command and get accompanying error. What do I need to do to fix. Thanks
(initramfs) fsck /dev/sdc1 -y
bash: syntax error near unexpected token `fsck'
-
Try putting the -y after fsck
-
Thanks for the reply, got same error
(initramfs) fsck -Y /dev/sdc1
bash: syntax error near unexpected token `fsck'
-
@LarryB1607
Context and flags are case sensitive... lower case Y
fsck -y /dev/sdc1
If a permissions error - you may need elevated/sudo access..
sudo fsck -y /dev/sdc1
-
sudo fsck -y /dev/sdc1
[sudo] password for larrypc:
fsck from util-linux 2.34
e2fsck 1.45.5 (07-Jan-2020)
fsck.ext2: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdc1
Could this be a zero-length partition?
sudo fsck -y /dev/sdc1
[sudo] password for larrypc:
fsck from util-linux 2.34
e2fsck 1.45.5 (07-Jan-2020)
scd1 is an extended partition bootable. It contains sdc5 LLOS and sdc6/home
-
@LarryB1607
You may want to paste the output of the following command... Might help those and ensure you run on the correct partitions
lsblk
I assume /dev/sdc is the USB drive?
sdc5 is root for LL
sd6 is LL /home
sdc1 is ?? (extended partition?) is this just data or unallocated, swap or something else..
is there sdc3 and sdc4 ?? /boot or swap
More so curious as to what's what...
those errors, I've seen - but usually when I've been working with LVM managed partitions. ?? but maybe something else... It should prompt to unmount if mounted.....
How were the partitions formatted - xfs, ext4, btrfs ??
-
sdc1 is an extended partition created on a USB external HDD, The rest of the HDD is formatted ntfs. sdc1 is formatted ext4 and contains sdc5 & sdc6. I have had the busybox error with every kernel update since 5.4.0-91. I found the supposed solution to the error and then ran into the syntax error and then got the short read error. Not sure why no kernel updates until these are causing this.
Thanks for all help so far.
-
@LarryB1607
Are you running on the your installed LL?
If so - its possible, if sdc5 & 6 are sub to sdc1 (?? - as its extended, havent messed with extended partitions for some time)
That it cannot check because those are mounted...
also... in your output fsck... it says "fsck.ext2"
You could try ... see if any better... although I assume the same...
sudo fsck.ext4 -y /dev/sdc1
or
sudo e2fsck -y /dev/sdc1
BUT what are the hopes in checking sdc1? its not the root/data partition... which root is /dev/sdc5 ...
If you wanting to check root - use sdc5 ..
BUT - if its mounted it wont run on a mounted system....
You can try a force at next boot.. you need to create a file in the root directory...
touch /forcefsck
That's assuming the system boots properly (not to a default shell)..
ELSE you could boot to a LiveUSB, attach the drive with LL and run fsck on the root partition on the usb drive from inside the Live Environment... *note the disk letters may change... sdc may become sdb or sde for example...
Hope that helps ..??...
-
Same thing happened with both of the 1st suggestions. I do not feel comfortable trying the forced fsck. I will try again to make a live usb. I tried LLOS 4.8 and 5.6 and had issues getting to a desktop. I was using etcher and had issues with that before. I will try again with unetbootin which has worked for me in the past. Not sure I will get to it today anymore.
Thanks for the replies
-
I ran fsck on both partitions and was told that they were clean. Earlier this week came a new kernel update. It was listed as 5.4.0-96.101 or something like that. Running a kernel identifier command said it is 5.4.0-97. No problems with this one and have had several inconsequential boots. Made a backup of it. Would like to get rid of the problem kernels and have successfully done this before except last time when for some unknown reason2 of the 3 parts of 5.4.0-91were also removed which caused boot issues. Thanks for all of the help to now.