Dual-booting, initramfs, busybox, and life!

Alright, here’s one for you.

I have Manjaro and MXLinux installed on an internal SSD. That’s my boot drive.

I also have an internal HDD which I use for media storage. That’s my data drive.

sda and sdb.

Curious issue.

As we know, drive designations are assigned arbitrarily on boot, so my install drive can be either sda or sdb depending on the weather. This generally isn’t a problem as both grub and my fstab use UUID only.

However, if I install updates or run update-grub in Manjaro on a rainy day when my boot drive happens to be sdb, MX won’t boot. Or rather, grub points me to the kernel without issue but once MX begins to boot I’m dropped into a initramfs/busybox shell (with which I have no familiarity but have bookmarked and will be reading up on in due course). I won’t be able to boot into MX again until I run update-grub in Manjaro on a sunny day when my boot drive happens to be sda.

This isn’t really a problem, more of an annoyance and I’d like to find out what’s causing it for my own personal enlightenment.

I’ve dug around a bit but come up mostly empty, that or the results I’m looking for are being lost in the sea of unfortunate souls who can’t figure out how to dual-boot Windows and Ubuntu. The closest match I found was somebody who was using a dodgy ext2 extension (in 2017 no less!) to access their Ubuntu partition from windows and consequently corrupting their file system.

I would like to stress that this is not a help request, if it were I’d post over at the debian or MX forum. I’m just curious whether anybody else has encountered or heard of the same issue before with a multi-boot system.

I’ll probably remove MXLinux or install something else over it once I get this figured out. I don’t care for it at all but to remove it now would be to admit defeat.


That won't happen, unless any one of these happen.
o installed or had installed (meaning installed and removed) grub-customizer in either manjaro or MX
o use of disastrously modified grub (by distro)
o willfully disabled use of UUID in grub (GRUB_DISABLE_LINUX_UUID=true)
o if bios-legacy, grub-install to the non-primary disk mbr, in which case the grub menu will not appear (not an entry which won't boot).

You said..

That implies a bios-legacy boot setting mbr to the non-primary disk (sdb) in which case, as the last point er...pointed out, you should not get to any grub menu, unless you had before 'set grub to mbr' to the other disk.

Since this is not a help request...

I would not expect any further queries from you nor need further explanations from me. :woozy_face:

Cheers. Take care.

[edit] BTW, This was my first reply, but this forum won't allow replies of less than 5 characters. :rofl:









Much digging last night.

Something about Manjaros grub saying 'mxpateo on /dev/sdb' (informational, still uses uuid) causes debian's kernel to freak out and scream 'whoa corruption! Here, have a busybox prompt'

I can only infer that because I installed on a sunny day there is a line of text somewhere in mx's boot process that has logged that it was installed on sda, being passed to the kernel from a grub entry that contains the line 'on sdb' foxes it.

Mx does not use systemd by default, probably unrelated but noted for my reading list.

More digging required, may have to wait until after the weekend because I have to work on my stupid degree.

Getting a pretty idea of the 'what' just need to figure out the 'why'

This is fun.

This issue occurs on debian based distributions using sysvinit when boot is being managed by another distributions grub.

First install Manjaro and MX on a uefi virtual machine and try to reproduce the issue.

Enable systemd in MX and try to reproduce the issue again (is it a quirk with how sysvinit handles the boot process?)

Replace Manjaro grub with grub vanilla and try to reproduce the issue once again. (is it specifically Manjaro's grub that causes the issue?)

If I'm able to reproduce the issue across those three use cases try again to do it with another distribution managing grub.

Great work indeed!

Busy week so just getting round to this. Reproduced in a VM. Tomorrow I'll try to narrow things down.

Forum kindly sponsored by