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

[este.el.paz]

I am using the 6.1.0-18 kernel with a low-end nvidia card in LMDE6 but with "standard" nouveau drivers, without any problems.

@axisofevil:

Good to know, so there is "hope" that someday Faye will figure her identity out and all will be well??

I too, should be using "nouveau" but that doesn't seem to be getting the system around the problems it keeps seeming to hit, and then . . . not hit on the way to the GUI . . . .

[este.el.paz]

@et al:

Realizing that I might be flogging the inert horse . . . but today again was, in theory, "Faye day" . . . gave it two cold boots and each time it went to "initramfs" shell . . . in which commands are not recognized . . . . I moved on to Trixie, Trixie self-identifies and boots cleanly.


So, might have mentioned before that in the dmesg that is blasting by, at the end there are phrases like, "can't find init" . . . and other mentions of "init" and further up something about "searching for btrfs" and likely not finding it . . . .

Based upon a recent discussion on the openSUSE factory list-serve in which the benefits and issues with "btrfs" vs "ext4" were briefly reviewed . . . in which the btrfs folks are mentioning "booting init3" or if that fails "booting init5" to get into a working GUI . . . .

Is LMDE a system that wants to have btrfs formatting, and since I have formatted all of my systems ext4 for many years, LMDE is looking for something that btrfs offers to provide a working system, but ext4 fails to provide that requirement?? hence the "looking for init, but we can't find it"?????

The dmesg is not showing any large lettered ***FAILED*** in front of that "init" data, but it goes to the non-working shell . . . as the sign of failure. Asking for a friend on the off chance that when LMDE7 becomes available he, um, I mean, they, might try formatting in btrfs and see if that gets into a consistent working GUI . . . .

[axisofevil]

It would be worth installing LMDE6 as a VM, possibly on a working LMDE6 system.
You could then try new kinds of things, such as BTRFS on the VM version in a non-destructive way.

The default install for LMDE uses ext4, the normal install seems to include the btrfs-progs package

This package contains utilities (mkfs, fsck) used to work with btrfs
and an utility (btrfs-convert) to make a btrfs filesystem from an ext3.

This isn't enough to run a btrfs file system, though.

[este.el.paz]

It would be worth installing LMDE6 as a VM, possibly on a working LMDE6 system.
You could then try new kinds of things, such as BTRFS on the VM version in a non-destructive way.

The default install for LMDE uses ext4, the normal install seems to include the btrfs-progs package

This package contains utilities (mkfs, fsck) used to work with btrfs
and an utility (btrfs-convert) to make a btrfs filesystem from an ext3.

This isn't enough to run a btrfs file system, though.

@axisofevil:

OK, thanks for the thoughts on it . . . haven't done much with VMs as of late . . . . Essentially what you are saying would be to do a new "installation" of LMDE in the VM, at which time it could be formatted as btrfs . . . to then test the difference???

Might be worth fiddling with, not sure if just running a reinstall of "/" in the hard metal install, formatting as btrfs, would be any more time-consuming?? It's all about "time" in my world these days . . . .

So, just to mess with me a bit more, today, which would usually be "Trixie day," . . . but Faye sits just above in the grub listing, spontaneously I decided to try Ms Faye again . . . and . . . Faye decided to play . . . so either Saturday is the day that Faye wants to kick up her heels, OR, it's "third times the charm"???? Although sometimes it's the 4th or 5th time . . . ???

I'll try to run an apt and check some of the suggestions here in the thread . . . .

[edit:] I ran an apt, and ordinarily I would be happy with just two packages to upgrade, but, in terms of trying to apt my way out of a problem . . . not much changes . . . . Did run @xenopeek's suggestion . . . sdc9 should be the correct partition . . . . We'll see how that goes.

Code: Select all

sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.1.0-18-amd64
WARNING: Unknown key type PC_SUPER_LEVEL2
WARNING: Unknown key type PC_SUPER_LEVEL2
WARNING: Unknown key type PC_SUPER_LEVEL2
WARNING: Unknown key type PC_SUPER_LEVEL2
WARNING: Unknown key type PC_SUPER_LEVEL2
WARNING: Unknown key type PC_SUPER_LEVEL2
WARNING: Unknown key type PC_SUPER_LEVEL2
WARNING: Unknown key type PC_SUPER_LEVEL2
WARNING: Unknown key type PC_SUPER_LEVEL2
WARNING: Unknown key type PC_SUPER_LEVEL2
WARNING: Unknown key type PC_SUPER_LEVEL2
WARNING: Unknown key type PC_SUPER_LEVEL2
WARNING: Unknown key type PC_SUPER_LEVEL2
WARNING: Unknown key type PC_SUPER_LEVEL2
WARNING: Unknown key type PC_SUPER_LEVEL2
WARNING: Unknown key type PC_SUPER_LEVEL2
I: The initramfs will attempt to resume from /dev/sdc9
I: (UUID=ee6d03c4-27ea-4218-8b30-36329d26cdd0)
I: Set the RESUME variable to override this.

[/edit]

[este.el.paz]

Think I figured out one of the problems . . . /etc/fstab data seems to show /efi/boot as "sdc1" . . . rather than sda5 where I had pointed it on install . . . .

Going to try to edit the data there to see if that provides the fix?? I thought I had checked /etc/fstab previously in the thread . . . don't know if the "initramfs" command brought in those changes, or when it occurred . . . ???

I'll post back on it when there is something to post about it.

[edit] Might have gotten it . . . /etc/fstab had a few /efi/boot listings, from each of the internal drives . . . and the sdc1 was the "named" choice in the fstab list . . . different than where grub is updating from . . . . Rebooted over to TW for grub updating, shut down, and on cold boot Faye went through her dmesg routine . . . first time.

So, I'll monitor it a bit more, but might finally be out of the woods on it. [/edit]

[edit2] Nope. Changing the /etc/fstab data did not seem to prevail in getting a consistent boot to Faye . . . just tried a few minutes ago and it again found the "Leap 15.6" system in the dmesg and again went to ER shell . . . . Back to the drawing board. If I can get Faye to boot tomorrow, I'll try to check to see if again the fstab data was changed?? Otherwise . . . out of ideas on it. [/edit2]

[este.el.paz]

Following up, more or less a month later . . . so, for a few weeks I could boot to Faye, usually not on first boot, but, perhaps on the second. Today, I tried to boot it three times, each time it hung on a different aspect . . . 1st time "clock source," . . . 2nd time "/run/init????" . . . 3rd time seemed more serious, "Stack Trace," and "sending MMI from CPU3 to CPUs7" . . . then "Call Trace"????

I shut it down and cold booted to tomorrow's system . . . quickly booted up and typing this in a foreign system, a system that LMDE is a stack on. I had been hoping that with the kernel upgrade Faye would figure it out . . . seems again to be "lost."

The other 6 systems are running fine on the same machine. Perhaps when LMDE7 becomes available a simple "full-upgrade" might suffice?

[axisofevil]

You could try running a Live boot of LMDE6 from USB...
Running a package update in live would let you stress the system a bit.

If you still get serious problems perhaps it could point towards hardware?

[este.el.paz]

You could try running a Live boot of LMDE6 from USB...
Running a package update in live would let you stress the system a bit.

If you still get serious problems perhaps it could point towards hardware?

@axisofevil:

I do have the "live" usb drive of LMDE . . . but, how is that going to help out with the bare metal install?? Or, you are meaning I would boot that and then select "boot from drive"?? And that would in theory boot LMDE?? Not sure if I have done that move over the years, sure, "live booting" but in this case this is "multi-boot" . . . so a number of systems to choose from. Anyway, when I get an idle moment I'll see what happens with that.

As far as "hardware" goes, I thought I covered that one with, "the other six systems have no problem with booting up"??? It does seem like LMDE is "having problems with the system," seemingly not finding a cpu to boot up from the "Quadcore" cpu . . . not seeing issues in the other systems, same machine, even same drive . . . . I may hang on with Faye to test 7, if it isn't that far away . . . .

[SMG]

I may hang on with Faye to test 7, if it isn't that far away . . . .

It's more than a year away.

... in this case I did not install a boot loader for LMDE, because I have another system handling grub...

. . . in my case that is complicated by 7 other linux installs, and a number of OSX's . . . .

You seem to be the only one having this issue and your system is not booting using what is normally provided by LMDE so it would seems something in your install/setup is likely the issue.

[este.el.paz]

@SMG:

Alrighty, thanks for the "7 is a year away" answer, that is helpful. But, whether I am "the only one" having this problem, I am having a problem, and the forum is supposed to be a place where "help" is provided . . . rather than deferred.

If I was a brand new user of linux I would accept your opinion as "truth" and delete the post, etc. But, I'm not a new user. The "live" system booted and ran fine on my machine (1st test) . . . since it passed that test, I ran the install. The installed system ran OK for a period of time (2nd test) . . . but then, "after a few package upgrades LMDE boots to ER shell." And since then sometimes it boots and sometimes not. It seemed like moving the kernel up "fixed" it for a couple weeks, but now not.

If, at some point some other Mac user stumbles into using LMDE and then "has a problem" this thread might give some hints to them. If I didn't have two other Debian installs running on the same machine I might think, as you do, "It's on me," . . . . But "Sid" and "Trixie" are running fine, Faye continues to be "Sid-like" in behavior.

Might try another install of / to see if that gets it fixed.

[SMG]

@SMG:

Alrighty, thanks for the "7 is a year away" answer, that is helpful. But, whether I am "the only one" having this problem, I am having a problem, and the forum is supposed to be a place where "help" is provided . . . rather than deferred.

Help has not been deferred. You've had several people attempting to help you.

However, you have never stated what is bootloader is, what is in control of it, or how you set up LMDE 6 to work with it. Doing that had to be part of your install, but you have made no mention of it at all in this topic. I went back through the posts to see if you had. That would seem to be a pretty important piece you left out especially since you originally said Faye was sdb8 but then here you mention sdc9 should be the correct partition.

Then you mentioned:

Think I figured out one of the problems . . . /etc/fstab data seems to show /efi/boot as "sdc1" . . . rather than sda5 where I had pointed it on install . . . .

I'm not sure how you expect others to follow along and help when what you think you did on install isn't what appears to have happened. You do not have a simple one or two OS install you are trying to troubleshoot. You have a different OS for every day of the week and then a few more. There is no "brand new user of linux" with that type of issue.

But "Sid" and "Trixie" are running fine, Faye continues to be "Sid-like" in behavior.

If Faye is "Sid-like" and "Sid" is running fine, then how are we supposed to understand what you are saying if you are telling us how Faye does not work consistently and there must be something wrong with Faye.

Perhaps you might find going back and reading through all the posts in this topic to be helpful. There might be mention of things which now might have more meaning as you have progressed through the investigation. I have often found reading through a topic again from the start to be helpful to catch things which didn't seem important at the time but later are or to catch things which may have been missed entirely.

[este.el.paz]

The name "Sid" was given to Debian's "unstable" release, because it was historically . . . "unstable" . . . from the character "Sid" in??? Toy Story?? But as of late "Sid" has been "well-behaved" in comparison to some of the other characters that I have running . . . . At one point several years ago I had a Sid-based install that running an apt reached across two partitions and erased data, in them . . . that is "Sid-like" behavior.

The **problem** with Faye is the inconsistency of it . . . this morning I picked Faye in grub and the dmesg ran through w/o a problem. I'm not sure what that "sdc9" was about, as at one point Faye did rewrite the /etc/fstab data and I had to edit that back to the right partitions. sdb8 is the correct partition for /.

Faye was not installed with bootloader, as TW is the grub wrangler . . . took me many years to find out that each system does not need a bootloader, but some systems, like apparently Virginia did not provide a way to not install it, but LMDE did . . . hence my selection of it in my multi-boot story . . . .

I have had systems "implode" . . . where running an update brings in packages that blow up a system . . . that then is very clear--it doesn't boot at all. In this case, it seems like "4th time is a charm" . . . Faye comes and goes . . . . The "why" of it is the question . . . but many times "there are no answers."

[axisofevil]

The reference to

I: The initramfs will attempt to resume from /dev/sdc9
I: (UUID=ee6d03c4-27ea-4218-8b30-36329d26cdd0)
I: Set the RESUME variable to override this.

is an indication that no swap partition is specified in GRUB, but that /dev/sdc9 is suitable and will be used.

I've got a tiny netbook with Windows (not used) + Mint 21.3 on it.
It always issues this message for a kernel update and I've never bothered to fix it.

[este.el.paz]

The reference to

I: The initramfs will attempt to resume from /dev/sdc9
I: (UUID=ee6d03c4-27ea-4218-8b30-36329d26cdd0)
I: Set the RESUME variable to override this.

is an indication that no swap partition is specified in GRUB, but that /dev/sdc9 is suitable and will be used.

I've got a tiny netbook with Windows (not used) + Mint 21.3 on it.
It always issues this message for a kernel update and I've never bothered to fix it.

@axisofevil:

Thanks for the insight . . . yes, likely sdc9 is a swap partition, in some installs I "tag" a number of them, but I think the installer will "find" them whether "tagged" or not, and that would relate more to "revival from suspend" than for booting the system???

But, back to my question to you about "running apt from live system" . . . what are the details of doing that??

[axisofevil]

To run a Live system:-
You boot from the LMDE6 disk - but do NOT choose the install option.
This should give you a full working version that runs in RAM, and provides a full file system for /, /home etc
It does not write anything to disk (indeed you don't even need any disks).

It will run much more slowly - but you will have the original issue software, issued from some months ago.
If you run apt it will install all the updates (into RAM) which have accumulated since the original date.
But you should still be able to run an "official" version of LMDE6 - even if all updates only take place in memory.

[este.el.paz]

To run a Live system:-
You boot from the LMDE6 disk - but do NOT choose the install option.
This should give you a full working version that runs in RAM, and provides a full file system for /, /home etc
It does not write anything to disk (indeed you don't even need any disks).

It will run much more slowly - but you will have the original issue software, issued from some months ago.
If you run apt it will install all the updates (into RAM) which have accumulated since the original date.
But you should still be able to run an "official" version of LMDE6 - even if all updates only take place in memory.

@axisofevil:

Alrighty, yes, I am familiar with running "live" . . . however, I do recall that the system ran well in the live system . . . . The issue with trying this is that the problem is this intermittent condition of "booting" or "not booting" . . . . Once in the Faye install, all runs well. It's getting there that has been the problem.

I guess the learning from the live approach would be if the booting there would also be intermittent?? I think I tried it a couple of times before running the install . . . "third time" seems to be problematic??

[axisofevil]

The implication is that if a "standard" LMDE6 works, then there is a non-LMDE6 problem.

Do you alter the configuration in some very non-standard way?
For example installing Ubuntu DEB packages on what is essentially a Debian bookworm distro (with some Mint modifications).

It could be useful to run inxi -r to check that faye is only seeing correct repositories and that any extra ones are suitable for Debian 12 (ie "Debian Stable")

[este.el.paz]

The implication is that if a "standard" LMDE6 works, then there is a non-LMDE6 problem.

Do you alter the configuration in some very non-standard way?
For example installing Ubuntu DEB packages on what is essentially a Debian bookworm distro (with some Mint modifications).

It could be useful to run inxi -r to check that faye is only seeing correct repositories and that any extra ones are suitable for Debian 12 (ie "Debian Stable")

@axisofevil:

For the most part nothing is non-standard in any of my installs . . . I have three multi-boot machines of various age and ilk, so, for the most part my hands are full just running them as they are installed . . . . In the case of Faye, it's relatively new, I think the repos are the basic "two lines from mint" and three lines from Debian?? minimal repos . . . . I've moved on to another system that needed attention, but when I get back to Faye I can run the inxi -r command . . . shouldn't be any surprises there . . . . They must be somewhere else??

[axisofevil]

In my clean LMDE6 VM, I have:-

user@debian12:~$ inxi -r
Repos:
No active apt repos in: /etc/apt/sources.list
Active apt repos in: /etc/apt/sources.list.d/official-package-repositories.list
1: deb https://mirror.vinehost.net/linuxmint/packages faye main upstream import backport
2: deb https://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
3: deb https://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
4: deb http://security.debian.org/ bookworm-security main contrib non-free non-free-firmware
5: deb https://deb.debian.org/debian bookworm-backports main contrib non-free non-free-firmware

My host machine has a couple of non-debian extras, so it's not quite so clean!

[este.el.paz]

@axisofevil:

Looks like my repos are the same as yours . . . . I was able to restart from my Sunday system and select Faye w/o issue today . . . .

Code: Select all

$ inxi -r
Repos:
  No active apt repos in: /etc/apt/sources.list
  Active apt repos in: /etc/apt/sources.list.d/official-package-repositories.list
    1: deb http://packages.linuxmint.com faye main upstream import backport
    2: deb https://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
    3: deb https://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
    4: deb http://security.debian.org bookworm-security main contrib non-free non-free-firmware
    5: deb https://deb.debian.org/debian bookworm-backports main contrib non-free non-free-firmware