After a few package upgrades LMDE boots to ER shell???

[este.el.paz]

Folks:

Today was LMDE day, so when I tried to boot it the first time today it went to a TTY type shell, I believe I could reboot out of it, and on second boot, selecting LMDE from the grub menu out of 7 installs on the machine, it booted fine to the GUI.

I did some fiddling on the interweb and then ran an apt dist-upgrade . . . it showed 20 or so packages, many with the name "cinnamon" in front of the package . . . did not see any kernels listed. I ran the packages through and then suspended the machine for breakfast.

When I came back to the machine, I had the same problem I've had with a couple other systems, the machine itself spins up, but the display remains black and does not revive from suspend. Had to hit the power button to shut down.

On cold boot, again selecting LMDE @sdb8 . . . machine boots to a TTY ER shell, which I could log into . . . it gave me some hints to try "journalctl -xb" . . . so I did that. There were a few errors . . . something like "dead zone" was mentioned, nothing "catastrophic" seemed to be mentioned. Somewhere in either the dmesg going to the TTY ER, or in the journalctl data I saw "Leap 15.6"????? Leap 15.6 / is located in sda8 . . . .

I checked /etc/fstab && lsblk -f in this shell and it seemed to be showing me the UUID data for sda . . . but in the sdb locations???

I've had similar problems with ubuntu systems where the system wants to be in charge of grub, but, in this case I did not install a boot loader for LMDE, because I have another system handling grub, for that very reason. In this case it seems like LMDE is mixing sda UUIDs over to the sdb UUIDs, so I'm not sure if I try to boot LMDE again, if it in fact is going to that system, OR whether it is booting Leap 15.6, therefore I won't be able to edit /etc/fstab for LMDE???

I took some screenshots in the ER shell, but don't know enough about SSHing or sending TTY data to a location to be able to check it, but I'm now in Leap 15.6 and I ran the same commands . . . it looks like the data LMDE is using is the Leap 15.6 data, posted below.

Any thoughts on a fix? Or, it's the nuke and the pave??

Code: Select all

> lsblk -f
NAME FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                         
├─sda1
│    vfat   FAT32 EFI   67E3-17ED                                           
├─sda2
│    hfsplu       High Sierra
│                       a2775dc9-eb23-316b-a4d8-7d4361ba2dad                
├─sda3
│    hfsplu       Recovery HD
│                       4815c1b0-16a2-3b33-b224-1be9a3e9d181                
├─sda4
│    hfsplu       FutureShock
│                       3a958b85-2be4-36cb-a8bc-6d470790d9ff                
├─sda5
│    vfat   FAT32       E592-ECD3                             278.2M     3% /boot/efi
├─sda6
│    ext4   1.0         907551ab-87d2-41c0-9b56-6e68d9947d7e                
├─sda7
│    ext4   1.0         929e9949-2d18-424c-be4a-80166827335b                
├─sda8
│    ext4   1.0         3011fcb2-1618-4d9a-975a-6426eb7e0f8e   33.1G    22% /
├─sda9
│    swap   1           d3f92ffb-ed1e-4f91-a030-97d5b608e2fa                [SWAP]
└─sda10
     ext4   1.0         50f7f65f-5963-49a9-b091-995afbf66e26  139.7G     3% /home
sdb                                                                         
├─sdb1
│    vfat   FAT32 EFI   67E3-17ED                                           
├─sdb2
│    hfsplu       1Macinto
│                       632a31b3-7430-3c28-a992-c92271adfa58                
├─sdb3
│    hfsplu       2Macinto
│                       93f0ad8c-baed-3a31-8811-56b4a5cc6765                
├─sdb4
│    hfsplu       Recovery HD
│                       11b8a168-b278-3d38-8df7-daee4fec3d35                
├─sdb5
│    hfsplu       3MacintoMavrik
│                       ee616cc5-97f5-3568-8841-0fdd4585518e                
├─sdb6
│    exfat  1.0   disk2s12
│                       6416-071B                                           
├─sdb7
│    ext4   1.0         4b916772-18f6-4b7c-b47c-eb0fa3796eff                
├─sdb8
│    ext4   1.0         f0aaf13b-c57b-4f2a-b606-7d9e5d737693                
├─sdb9
│    ext4   1.0         ab58c2d1-47b2-4b63-9b1c-b86c4f182c8e                
├─sdb10
│    ext4   1.0         64c5dba2-bacd-4459-9904-6bda0fbe24e7                
└─sdb11
     swap   1           01988475-fd31-486a-a258-ae01a153a885                
sdc                                                                         
├─sdc1
│    vfat   FAT32 EFI   67E3-17ED                                           
├─sdc2
│    hfsplu       MacintoUno
│                       8037621e-c63c-3884-bfb4-729282cf76fd                
├─sdc3
│    hfsplu       Recovery HD
│                       15f8192a-a9d0-3409-a5b9-084fc913ca7e                
├─sdc4
│    hfsplu       MacintoDos
│                       6073161c-00c1-3827-9f81-000472e23582                
├─sdc5
│    ext4   1.0         9f39fc44-d590-4a43-9544-56ad458a9e6e                
├─sdc6
│    ext4   1.0         d4853378-2816-4678-8308-1f245d9123ac                
├─sdc7
│    ext4   1.0         17bcb813-d05e-4cc3-bcdf-16d283156780                
├─sdc8
│    ext4   1.0         598d1ebe-6ad9-4491-b95a-7540208c28e3                
└─sdc9
     swap   1           ee6d03c4-27ea-4218-8b30-36329d26cdd0                
sr0                                                                         
d:~> sudo cat /etc/fstab
[sudo] password for root: 
UUID=3011fcb2-1618-4d9a-975a-6426eb7e0f8e  /          ext4  defaults      0  1
UUID=50f7f65f-5963-49a9-b091-995afbf66e26  /home      ext4  data=ordered  0  2
UUID=d3f92ffb-ed1e-4f91-a030-97d5b608e2fa  swap       swap  defaults      0  0
UUID=E592-ECD3                             /boot/efi  vfat  utf8 

[este.el.paz]

Latest update:

Just ran an upgrade on Deb Trixie partition, which included a fair number of packages, with kernel . . . updated grub in the grub handler system and on reboot . . . back into Trixie . . . .

So, I'm inclined to conclude that something went awry in LMDE, unrelated to the Debian undercarriage . . . rewriting its own UUID location numbers??? just because it can . . . .

I'll check back to LMDE in a bit . . . seems like sometimes it boots cleanly and sometimes not . . . on the revisiting . . . .

[SMG]

Latest update:

Just ran an upgrade on Deb Trixie partition, which included a fair number of packages, with kernel . . . updated grub in the grub handler system and on reboot . . . back into Trixie . . . .

So, I'm inclined to conclude that something went awry in LMDE, unrelated to the Debian undercarriage . . .

LMDE is not based on Trixie. It's based on Debian stable.

[este.el.paz]

Latest update:

Just ran an upgrade on Deb Trixie partition, which included a fair number of packages, with kernel . . . updated grub in the grub handler system and on reboot . . . back into Trixie . . . .

So, I'm inclined to conclude that something went awry in LMDE, unrelated to the Debian undercarriage . . .

LMDE is not based on Trixie. It's based on Debian stable.

Yep . . . exactly my point. The Debian side is most likely "stable" . . . . I've since tried to reboot back to LMDE . . . same issue, it sees itself as being in the Leap 15.6 location . . . so the shell is in Leap . . . don't see how I can remedy this problem, as the /etc/fstab data is showing the Leap 15.6 location UUIDs . . . so if I try to edit it, that will be editing the Leap 15.6 /etc/fstab data???

[SMG]

Yep . . . exactly my point. The Debian side is most likely "stable"...

Your point is you are making an assumption which may or may not be true. I do understand that.

You have not given us any idea of what updates you ran which makes it difficult for guess what might have happened.

I don't usually help with fstab issues so I will let others help you.

[este.el.paz]

Yep . . . exactly my point. The Debian side is most likely "stable"...

Your point is you are making an assumption which may or may not be true. I do understand that.

You have not given us any idea of what updates you ran which makes it difficult for guess what might have happened.

I don't usually help with fstab issues so I will let others help you.

Thanks for stopping by, that is appreciated. One of the problems is that for what should have been a "routine," small number of upgrades, I didn't snap a cell shot of the data to be upgraded in LMDE, from recollection, as I mentioned above "cinnamon-xxxx-xxxxx" was included in a fair number of them. Hence I tend to think this is a "cinnamon" problem??

And now, the shell that is booting is not an LMDE shell, so I can't log in and try to run upgrades, or try to edit fstab . . . . As also mentioned I have had issues with ubuntu based systems trying to "take over" the other multi-boot players, usually modifying the other systems UUIDs, but, in this case, thankfully, it only modified itself???

In those previous cases I vaguely recall "chrooting" into the modified system and trying to do something that way, but, I'm not sure whether that could be done in this present case, OR, what it is I would do ????

[SMG]

One of the problems is that for what should have been a "routine," small number of upgrades, I didn't snap a cell shot of the data to be upgraded in LMDE, from recollection, as I mentioned above "cinnamon-xxxx-xxxxx" was included in a fair number of them. Hence I tend to think this is a "cinnamon" problem??

It really depends on when you last updated. LMDE 6 was recently upgraded from Cinnamon 5.8 to 6.0. (LMDE gets Cinnamon upgrades soon after the latest LM version is released.) Those Cinnamon upgrades would be for the desktop environment (DE). I would not guess they have any relation to booting the OS.

In those previous cases I vaguely recall "chrooting" into the modified system and trying to do something that way, but, I'm not sure whether that could be done in this present case, OR, what it is I would do ????

That would be my likely guess and I would also guess you should be able to boot to a live session of some distro to do it. I do not have experience helping others do that so I cannot make anything more than higher level comments about what might be needed.

[este.el.paz]

One of the problems is that for what should have been a "routine," small number of upgrades, I didn't snap a cell shot of the data to be upgraded in LMDE, from recollection, as I mentioned above "cinnamon-xxxx-xxxxx" was included in a fair number of them. Hence I tend to think this is a "cinnamon" problem??

It really depends on when you last updated. LMDE 6 was recently upgraded from Cinnamon 5.8 to 6.0. (LMDE gets Cinnamon upgrades soon after the latest LM version is released.) Those Cinnamon upgrades would be for the desktop environment (DE). I would not guess they have any relation to booting the OS.

In those previous cases I vaguely recall "chrooting" into the modified system and trying to do something that way, but, I'm not sure whether that could be done in this present case, OR, what it is I would do ????

That would be my likely guess and I would also guess you should be able to boot to a live session of some distro to do it. I do not have experience helping others do that so I cannot make anything more than higher level comments about what might be needed.

Yesterday, was LMDE day . . . so prolly going from 5.8 to 6.0 . . . for the DE.

I have multi-boot options to choose from in the machine . . . chrooting more or less exceeds my skillz capacity, often times easier to just nuke it, but for the kicks of the pursuit of the diagnosis, perhaps something to play with??

I recently had an issue in another operating system where an upgrade, that "wasn't supposed to affect my gpu" blacklisted nouveau, resulting in a "failure to revive from suspend" problem . . . took a few months dealing with bug reports to get a hint on how to fix the problem. In spite of the best efforts of the devs, it seems that sometimes problems slip through to the end user.

[SMG]

Yesterday, was LMDE day . . . so prolly going from 5.8 to 6.0 . . . for the DE.

Depending upon which packages you received, there was a problem related to the screensaver which would make the screen black after resuming from suspend, but if one blindly typed their password they could get back in. The fix for that was released, but I don't know the timing in relation to what you did.

I have multi-boot options to choose from in the machine . . . chrooting more or less exceeds my skillz capacity, often times easier to just nuke it, but for the kicks of the pursuit of the diagnosis, perhaps something to play with??

Do you have any install usbs? That's what I meant by booting to a live session to chroot. (Or maybe you found your UUID issue from a live session?)

I don't know if any of these might help you:
What scenarios causes a hard drive UUID to change?
UUIDs change during reboot
how to change UUIDs on a boot stick, and update GRUB?

[este.el.paz]

@SMG:

Thanks for the follow up and reply . . . I did know what you meant by "live session usb" . . . in my case that is complicated by 7 other linux installs, and a number of OSX's . . . . In theory I could chroot from any of the other linux installs I've got going, but then where would I go??

Somebody over in the LMDE software sub-forum had issues with "failing to boot after upgrade to 6.1. xx -18 kernel, and I posted on that thread and there was a reply saying that the Debian forum found problems with that kernel and nvidia cards . . . of which I do have, but running nouveau . . . .

So, possibly that might be involved as well . . . seems like some over-lapping of problems that might be contributing to the present condition of "failure to thrive"???

[SMG]

Thanks for the follow up and reply . . . I did know what you meant by "live session usb" . . . in my case that is complicated by 7 other linux installs, and a number of OSX's . . . . In theory I could chroot from any of the other linux installs I've got going, but then where would I go??

I didn't know how many UUIDs might be messed up which is why I thought the live session (completely off the installed versions) might be better. As I said, I don't really have experience with that.

Somebody over in the LMDE software sub-forum had issues with "failing to boot after upgrade to 6.1. xx -18 kernel, and I posted on that thread and there was a reply saying that the Debian forum found problems with that kernel and nvidia cards . . . of which I do have, but running nouveau . . . .

So, possibly that might be involved as well . . . seems like some over-lapping of problems that might be contributing to the present condition of "failure to thrive"???

I did see that other topic and thought of your situation because you had mentioned Nvidia, but you mentioned in your initial post you hadn't noticed any kernels in what you installed.

Nvidia driver modules must be made for each kernel which means new ones must be built when a new kernel is installed. Because nouveau comes with the kernel, I'm not sure how nouveau kernel modules are handled.

[este.el.paz]

Nvidia driver modules must be made for each kernel which means new ones must be built when a new kernel is installed. Because nouveau comes with the kernel, I'm not sure how nouveau kernel modules are handled.

Yep. I found out a number of years back that going proprietary in alpha/beta or rolling distros pulling the latest kernels did not fare well for function. Too much maintenance going that way, so I stick with nouveau or default mods for video.

But, then it does seem that going Nvidia hardware does carry some extra processing or handling????

One of my moves when having problems booting systems has been to use Supergrub2 usb to find and boot systems . . . but I don't think that will help out in this "missing UUID" situation. My installed grub shows LMDE in the proper sdb8 location, but booting it goes to Leap in TTY ER shell.

I'll read your links on those topics tomorrow or when I have a free moment . . . .

[este.el.paz]

Had a few minutes to play around with a chrooting . . . I did look through the links to other posts, seemed "close" but not exactly "the same." I'm in Deb Sid today, when I ran

Code: Select all

lsblk -f

it shows the LMDE / data as being in

Code: Select all

sdc8

. . . so I tried to use that location, and that then shows the outcome of

Code: Select all

sdb8

and the UUIDs are correct.

Code: Select all

$ sudo -i
root@02:~# mount /dev/sdc8 /mnt
root@02:~# mount --bind /dev /mnt/dev
root@02:~# mount --bind /proc /mnt/proc
root@02:~# mount --bind /sys /mnt/sys
root@02:~# chroot /mnt /bin/bash
root@02:/# cat /etc/fstab
#### Static Filesystem Table File
proc    /proc   proc    defaults        0       0
# /dev/sda1
UUID=67E3-17ED  /boot/efi       vfat    defaults        0       1
# /dev/sda5
UUID=E592-ECD3  /boot/efi       vfat    defaults        0       1
# /dev/sda9
UUID=d3f92ffb-ed1e-4f91-a030-97d5b608e2fa       swap    swap    sw      0       0
# /dev/sdb1
UUID=67E3-17ED  /boot/efi       vfat    defaults        0       1

# /dev/sdb8
UUID=f0aaf13b-c57b-4f2a-b606-7d9e5d737693       /       ext4    rw,errors=remount-ro    0       1
# /dev/sdb11
UUID=01988475-fd31-486a-a258-ae01a153a885       swap    swap    sw      0       0
# /dev/sdb10
UUID=64c5dba2-bacd-4459-9904-6bda0fbe24e7       /home   ext4    rw,errors=remount-ro    0       0

# /dev/sdc1
UUID=67E3-17ED  /boot/efi       vfat    defaults        0       1
# /dev/sdc9
UUID=ee6d03c4-27ea-4218-8b30-36329d26cdd0       swap    swap    sw      0       0
root@02:/# 
exit

So, then I tried to run it as sdb8 and it errors out at step one???:

Code: Select all

root@02:~# mount /dev/sdb8 /mnt
root@02:~# mount --bind /dev /mnt/dev
mount: /mnt/dev: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.
       
       

[edit:] Based upon the possible chroot data showing the UUIDs were correct I rebooted, selected LMDE in the grub menu and . . . it booted up, as "itself"!!!??? So, the question is will this be an intermittent thing, sometimes booting, sometimes not??? But now in LMDE, ran an apt and it showed the 6.1. xxx -18 kernel packages, which seemed to cause problems for another poster in the forum, also having Nvidia card. So, for now I'm in LMDE, but declined to upgrade to the newer kernel that apt is offering . . . . Possibly there might be a newer on available in the "Kernel" app??

Code: Select all

sudo apt dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
  linux-headers-6.1.0-18-amd64 linux-headers-6.1.0-18-common
  linux-image-6.1.0-18-amd64
The following packages will be upgraded:
  cryptsetup cryptsetup-bin cryptsetup-initramfs espeak-ng-data
  gstreamer1.0-pipewire libcryptsetup12 libde265-0 libespeak-ng1 libgnutls30
  libisl23 libmateweather-common libmateweather1 libnss-myhostname
  libnss-systemd libpam-systemd libpipewire-0.3-0 libpipewire-0.3-modules
  libspa-0.2-bluetooth libspa-0.2-modules libsystemd-shared libsystemd0
  libudev1 linux-compiler-gcc-12-x86 linux-headers-amd64 linux-image-amd64
  linux-kbuild-6.1 linux-libc-dev pipewire pipewire-alsa pipewire-audio
  pipewire-bin pipewire-pulse systemd systemd-coredump systemd-sysv
  systemd-timesyncd tar tzdata udev usb.ids usbutils usr-is-merged
42 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 106 MB of archives.
After this operation, 470 MB of additional disk space will be used.
Do you want to continue? [Y/n] n

[SMG]

[edit:] Based upon the possible chroot data showing the UUIDs were correct I rebooted, selected LMDE in the grub menu and . . . it booted up, as "itself"!!!??? So, the question is will this be an intermittent thing, sometimes booting, sometimes not??? But now in LMDE, ran an apt and it showed the 6.1. xxx -18 kernel packages, which seemed to cause problems for another poster in the forum, also having Nvidia card. So, for now I'm in LMDE, but declined to upgrade to the newer kernel that apt is offering . . . . Possibly there might be a newer on available in the "Kernel" app??

My read of the bug report and the fix in the other topic is that the problem is with the proprietary Nvidia driver packages which you said you are not using. The fix is going to be to change the proprietary Nvidia driver packages and not a change to the kernel.

I don't know if people who are not using the proprietary Nvidia driver are having problems with that kernel.

[este.el.paz]

I don't know if people who are not using the proprietary Nvidia driver are having problems with that kernel.

@SMG:

LOL. I don't know that either . . . hence my post on the question.

But, I did rifle around in the GUI trying to find "kernel" app, but that must be in another installed system, or was in the Live "Virginia" MATE system that I booted up a month back??

Anyway, in synaptic I searched "kernel" and it did seem like in the 6.1 iterations that the "18" is the latest option, uname -r showed I'm in "17." But then it did seem like there might be some 6.5 xxx offerings to mess with. I'm in LMDE right now, but not exactly feeling "frisky" on trying out the "18" option, or jumping up to 6.5???

I'm not sure if there is an exact match of kernels across ALL linux systems, but I think in my openSUSE TW install that is running 6.7 xxx?? So, I'm not entirely averse to jumping over "18" . . . but then who knows if that will bring smooth sailing or just freshened dysfunctions???

[SMG]

But, I did rifle around in the GUI trying to find "kernel" app, but that must be in another installed system, or was in the Live "Virginia" MATE system that I booted up a month back??

There is no "kernel app" in LMDE. You have to use Synaptic Package Manager.

Linux Mint (based on Ubuntu) can manage kernels through functionality in Update Manager so it is likely the Live Virginia MATE system you are recalling.

Anyway, in synaptic I searched "kernel" and it did seem like in the 6.1 iterations that the "18" is the latest option, uname -r showed I'm in "17." But then it did seem like there might be some 6.5 xxx offerings to mess with. I'm in LMDE right now, but not exactly feeling "frisky" on trying out the "18" option, or jumping up to 6.5???

The kernel with LMDE 6 is 6.1, but there is also the option to backport newer kernels. I believe the current newest is 6.5.

I'm not sure if there is an exact match of kernels across ALL linux systems, but I think in my openSUSE TW install that is running 6.7 xxx?? So, I'm not entirely averse to jumping over "18" . . . but then who knows if that will bring smooth sailing or just freshened dysfunctions???

A number of distros which are not rolling releases use their own kernels so they will not be exactly the same as what is available on kernel.org. Neither Debian nor Ubuntu are rolling releases. I would presume openSUSE TW (tumbleweed) is because a tumbleweed keeps rolling in the wind.

[este.el.paz]

Yes, it keeps on "tumbling" sometimes 1500 packages to upgrade at a time . . . or more . . . can be a bit time consuming.

So, back to LMDE . . . not out of the woods as I had hoped with regaining its location. This afternoon, after I posted the previous edit, I suspended it, then a couple hours later . . . did not revive. I've had this problem in a number of my other installs . . . with the non-revival from suspend.

That might be a motivation to try the newer kernel options . . . maybe go to 6.5???

[SMG]

That might be a motivation to try the newer kernel options . . . maybe go to 6.5???

Might be time to provide your system information so we can see your hardware and how LMDE views it. Please open the System Reports app and click the System Information tab on the left. Your computer's information should come up in the right pane. Then click the Copy button in the lower right and paste the results into a reply window here so we can see how Linux Mint views your hardware.

By the way, many Nvidia GPUs have problems returning from suspend when using the nouveau driver.

[este.el.paz]

That might be a motivation to try the newer kernel options . . . maybe go to 6.5???

Might be time to provide your system information so we can see your hardware and how LMDE views it. Please open the System Reports app and click the System Information tab on the left. Your computer's information should come up in the right pane. Then click the Copy button in the lower right and paste the results into a reply window here so we can see how Linux Mint views your hardware.

By the way, many Nvidia GPUs have problems returning from suspend when using the nouveau driver.

@SMG:

I'm away from that machine right now . . . working late, I'll post that data when I get there.

As far as the "many Nvidia GPUs have that problem with using nouveau driver," I have historically found many more problems going proprietary, especially when using beta or rolling distros, particularly with this non-revival from suspend . . . .

Even posting inquiries with the Nvidia linux forum the guy there basically said, "We don't care about liinux enough to keep pace with it." (paraphrased).

So, yes there are issues with kernels that seem to bring out this problem, perhaps it's problematic to go with Nvidia GPUs, but I do like the crispy rendering that they provide . . . nouveau seems to be the avenue of least resistance in the Nvidia GPU and linux realm.

[SMG]

As far as the "many Nvidia GPUs have that problem with using nouveau driver," I have historically found many more problems going proprietary, especially when using beta or rolling distros, particularly with this non-revival from suspend

My comments are specifically based on helping people on this forum with their Linux Mint installs with the drivers provided by the Linux Mint distros which are neither beta nor rolling.