Boot into failsafe mode

[ohmysql]

Sigh, well, this worked for a couple of tries. Now it's broken again. I've been trying to fix it but apparently I don't have the tools.

For instance, when I try to boot Mageia I'm getting a message that uuid 894e96b8-etc. doesn't exist before crashing into dracut shell. Yet, when I do lsinitrd on all the initrd's in my boot folder, none of them have that ID. It's very odd.

Code: Select all

menuentry 'Mageia 4 latest tip' {
   insmod part_msdos
   insmod ext2
        search --no-floppy --fs-uuid --set=root   894e96b8-3836-41d2-b887-1d7355ac62f6
   linux   /boot/vmlinuz-desktop root=UUID=894e96b8-3836-41d2-b887-1d7355ac62f6 ro nokmsboot profile rd.hostonly=0 3
   initrd  /boot/initrd-desktop.img
   
##      initrd options
#initrd initrd-3.12.25-desktop-3.mga4.img
#initrd initrd-3.13.0-46-generic.img.bak1
#initrd initrd-3.14.24-desktop-1.mga4.img.bak1
#initrd initrd-3.19.2-1-ARCH.img
#initrd initrd-3.2.0-34-generic.img
#initrd new-initrd.imgm

        #systemd.unit=multi-user
        #rd.hostonly=0
}


initrd-desktop.img is a link pointing to "/boot/initrd-3.19.2-1-ARCH.img"

Suffice it to say, I am still buggered in dracut shell.

But:

Code: Select all

 lsinitrd /boot/initrd-desktop.img | grep -e uuid
lrwxrwxrwx   1 root     root           16 Mar 24 17:04 usr/lib64/libuuid.so.1 -> libuuid.so.1.3.0
-rwxr-xr-x   1 root     root        15864 Mar 24 17:04 usr/lib64/libuuid.so.1.3.0

and

Code: Select all

lsinitrd /boot/initrd-3.19.2-1-ARCH.img | grep -e uuid
lrwxrwxrwx   1 root     root           16 Mar 24 17:04 usr/lib64/libuuid.so.1 -> libuuid.so.1.3.0
-rwxr-xr-x   1 root     root        15864 Mar 24 17:04 usr/lib64/libuuid.so.1.3.0

I'm quite confused but I'm getting better at this, thanks to your help!

OMS!!!

PS Here's my Mage boot folder in case this is helpful:

Code: Select all

ls /boot/ | grep initrd
initrd-3.12.25-desktop-3.mga4.img
initrd-3.13.0-46-generic.img.bak1
initrd-3.14.24-desktop-1.mga4.img.bak1
initrd-3.19.2-1-ARCH.img
initrd-3.2.0-34-generic.img
initrd-desktop.img@
initrd.img.bak1@
new-initrd.img


[doktor5000]

You are using Cauldron, right? Since when does that happen, and what did you change? Also, that UUID, what does it refer to? Can you please show the output as root of

Code: Select all

lsblk -fl

The issue is that the system drops to an emergency shell when something from /etc/fstab cannot be mounted, This is sadly the default behaviour of systemd for everything that should be mounted during boot and is not marked as "nofail" See also errata for that: https://wiki.mageia.org/en/Mageia_4_Err ... rrect_UUID
And some more links:
http://www.mageialinux-online.org/wiki/ ... d-not-boot
viewtopic.php?f=7&t=7093
viewtopic.php?f=8&t=8987

[gohlip]

The issue is that the system drops to an emergency shell when something from /etc/fstab cannot be mounted, This is sadly the default behaviour of systemd for everything that should be mounted during boot and is not marked as "nofail"

Default behaviour of systemd?
As per viewtopic.php?f=7&t=7093&sid=32ee4ec617f010929e44384eb26f444c#p53327
I said

Well, first, I am also using Manjaro (and others), which uses ...... systemd. And as I pointed out above, no problem when I change the fstab UUID entry. Only Mageia gets 'buggered'.
So maybe Mageia's systemd cannot resolve this or Manjaro's systemd can. Whatever.

Also what is there to put a "nofail" when that UUID is not even there in fstab?

I think there's something in mageia's dracut conf (or HOOKS) that insists on using original setup parameters despite changing all other settings.
If that's the case, nobody's telling (not saying you, doktor5000) . For such a catastrophic failure, that is bad support for any distro.

[doktor5000]

Also what is there to put a "nofail" when that UUID is not even there in fstab?

I think there's something in mageia's dracut conf (or HOOKS) that insists on using original setup parameters despite changing all other settings.
If that's the case, nobody's telling (not saying you, doktor5000) . For such a catastrophic failure, that is bad support for any distro.

Seems you didn't read the two abovementioned threads where that issue (related to swap UUID) and the relevant hook is explained.
Also all the relevant bug reports are linked there: viewtopic.php?p=53353#p53353

So what do you mean by "nobody's telling"? I did.

[gohlip]

(not saying you, doktor5000)

Said enough. Not continuing dialog which I cannot expect a good outcome.

[ohmysql]

lol thanks everyone! I really appreciate your continued support. This was quite a flameout.

I think it's mostly working now--- instead of dracut -f I did dracut -f --regenerate-all like this thread suggested:

http://www.mageialinux-online.org/wiki/ ... d-not-boot

(La chance que je parle français !)

It's hard to tell but perhaps the problem was that I deleted everything in /etc/dracut.conf.d/51-mageia-resume.conf rather than replacing the errant UUID. Anyway, after all those changes and dracutting galor, I'm barely able to access Mageia. I'll save for another thread the fact that every time it restarts I have to startx through the terminal (the login greeter seems completely fried). I guess for the moment this is once again resolved!

And FYI I'm using Mageia 4, whatever was the latest production build a few months ago. Too bad about that bug!

And indeed, the problem obviously began because I have a shared swap partition that occasionally got formatted so that the UUID was changed.

[waferhead]

The current system is delicate beyond belief (MGA4 or MGA5) will fail to boot and drop you to a relatively useless debug shell even if windows partition is hibernated.
There is no fast/easy way to fix this short of reinstalling the OS, recreating initrd from chroot doesn't work quite right, although there is probably a way to get there from here given a few hours of research, you can reinstall//update in 20 minutes.

Nonessential module or filesystem failures never prevented booting, that was a solved engineering problem in ~Linux 1.0 era, and is a ridiculous issue to see in 2015.

Between systemd braindamage and this sort of garbage, after getting on this train at Mandrake 6, I think I'll spend some time with Wheezy for awhile.

[doktor5000]

So you seem to have ignored the previous post of the OP saying that regenerating the initrd as documented worked just fine, but just want to complain and troll around?

Feel free to spend some more time with Debian please.

[waferhead]

Na, Debian has its own issues, just frustrated that the current system has so many operational regressions.
Bluetooth is in a similar situation, all the distros merrily upgraded to bluez5 even though there was no working infrastructure to use it fully, hasn't't fully worked since mageia 3.

AFAICT only Arch kept bluez4 as an option so SPP profile etc still work.
(Needed for serial emulation, PPP Tethering via cellphone or actual BT serial use.

You act as if this fixed anything, when it's a horrible system level bug.
Typing in a page of commands to fix a system that should have booted regardless is not a fix, esp if you are working and need it working now and have no net access.

Forcing me to use windows is unforgivable

Pretending it's fixed or not a bug helps no one, and happens regularly

[doktor5000]

If you are frustrated or not doesn't matter, this is no reason to spam threads of other people with stuff that doesn't help or is totally unrelated.
How is bluetooth even related to this at all? The bug that this thread is about has been fixed for Mageia 5 in various forms:

https://bugs.mageia.org/show_bug.cgi?id=10179
https://bugs.mageia.org/show_bug.cgi?id=12305
https://bugs.mageia.org/show_bug.cgi?id=12566
https://bugs.mageia.org/show_bug.cgi?id=12631

I'm not pretending, I cared enough to report one of those bugs and helped track them so that they have been fixed for Mageia 5.

If you continue like this, thread will be locked as the OP already replied that he has fixed it himself.

[waferhead]

I wasted an hour trying to fix it via following the above threads before throwing in the towel.
(fortunately Google translate works well on French, but trying to use an iphone for web access while trying get your PC to boot is not recommended)

My current Cauldron install on the same drive was just as broken: Nothing has been "fixed" here, but thank you for trying.

Reinstalled and was back up fully in ~20 min once I had a net connection again.

The Bluetooth issue was just an example of the same sort of "lack of planning" idiocy.
Mageia is not alone in that respect, everyone dropped Bluez4 like a hot potato with no userland tools fully supporting Bluez5 to date.
(It has been what, ~2 years now?)

As to systemd, I'm so impressed with it I'm about to see how functional openrc is so far.
(Systemd seems to be great for boot times and fast shutdowns, my only real issue with it is bad error handling and the almost useless debug shell)