[Solved] Can't boot mabox anymore

I have an essential problem since recently updating my mabox system.

I am running a triple boot system with opensuse tumbleweed, mabox and windows 11. grub resides on the tumbleweed boot partition. The grub menu at start-up shows all three OS. But when I’m choosing mabox, I’m ending up in kind of an emergency shell (in which I don’t know, what to do), that says „mount:/new_root: cant find UUID=…” The UUID names the partition on which the mabox system data are located.

os-prober (executed in konsole within tumbleweed) finds the windows an mabox OS. But only opensuse and windows will start up. Is there anything „quiet simple” I can do to get back to my mabox system? I am not an Linux expert at all …

Oh, by the way: Choosing one of the „fallback” snapshots (advanced options of the boot menu) results in a kernel-panic. Choosing mabox via the boot menu of my PC (pressing F11 during start-up) results in a black screen.

Thank you in advance

Hi Carsten / @avwasser ,
Try first in opensuse

grub2-mkconfig -o /boot/grub2/grub.cfg

ls -l /dev/disk/by-uuid/
lists the uuids and you may check it in /boot/grub2/grub.cfg
If it is not enough

cd /root
dracut --regenarate-all --force
grub2-mkconfig -o /boot/grub2/grub.cfg

No guarantee…

Hi zolw,
thanx for inspecting my issue… I rebuilt grub with grub2-mkconfig(…) several times before. Always mabox was found and written to grub.cfg. Today I looked into grub.cfg to follow your advice: The UUID, that can not be found during boot, is mentioned several times; as well as the UUID where opensuse resides. But when I rebooted – I ended up in this emergency shell with the same message as yesterday.

To be honest, I am a little frightend to apply your command in /root… Can it damage something I am not able to repair?

Hi @avwasser ,
As the problem is due to the changed UUID in Mabox
boot a live mabox from USB
open a terminal

sudo su -
manjaro-chroot -a

here you can select Mabox from a list
take note the mabox root partition
ls -l /dev/disk/by-uuid/
select the UUID of your (actual) mabox partition or open a new terminal and
nano /etc/fstab
if the UUID differs replace it with the actual above
ctrl +O
ctrl +X
It makes no harm if these commnands are also executed

cd /root
mkinitcpio -P

The hardest part to modify the UUID-s (to the actual) of mabox in Opensuse
there are more than one. Make copy of grub.cfg at first.
And of course you may save your precious files in live mode after manjaro-chroot
It is based on Aragorn I have tested patially.

Thanks a lot again – I followed your steps (and read also Aragorn’s hints) but I had no success. The UUID, which the emergency shell says couldn’t be found is the one, that is written in the fstab of my mabox installation and it appears several times in /boot/grub2/grub.cfg in opensuse tumbleweed. No difference in the expression. Its everywhere exactly the same. … I’m lost :frowning:

The UUID, which the emergency shell says couldn’t be found is the one, that is written in the fstab of my mabox installation

That is the problem. Carefully identifify the UUID of your mabox partition in chroot ‘environment’
with this
ls -l /dev/disk/by-uuid/
and you have to overwrite with that UUID in fstab
Have you modified fstab?
as an example

# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=D28F-8124                            /boot/efi      vfat    umask=0077 0 2
UUID=0fd1afb8-1fa8-4b41-8ac1-bf7b21914bc3 /              ext4    defaults,noatime 0 1
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0

In my case sda4 is my / root and UUID 0fd1…c3 must be the same as after manjaro-chroot
ls -l /dev/disk/by-uuid/

total 0

rwxrwxrwx 1 root root 10 ápr    5 23.09 03F0-B72B -> ../../sdb1
lrwxrwxrwx 1 root root 15 ápr    5 23.09 0608ebb9-fd43-4f01-b149-24b842b0d369 -> ../../nvme0n1p8
lrwxrwxrwx 1 root root 10 ápr    5 23.09 0fd1afb8-1fa8-4b41-8ac1-bf7b21914bc3 -> ../../sda4

If they are different that causes the boot failure
make a copy of fstab and modify UUID to that you see after manjaro-chroot
Did you identify the mabox partition?

  1. Do you have a USB with mabox iso and booted in live mode?
  2. Open two terminals.
  3. in terminal #1
    sudo su -
    manjaro-chroot -a
  4. Did you select Mabox from the list? And what is the partion name?
    to be continued.


You use ext4 not btrfs I guess. I don’t know how much work you put in to your mabox configuration.
Consider backing up the home directory. You reach it from opensuse or from a live mabox after manjaro-chroot https://www.pragmaticlinux.com/2021/05/how-to-backup-your-home-directory-in-linux/
If the following procedure is too tedious, check the backup of your home and reinstall mabox and restore home. Packages should be reinstalled manually.

What I whuld do : make a separate efi partition for mabox

  1. from opensuse use gparted to resize mabox partiton and create a 512 MB fat32 partition with boot and efi flags
    in my case it is sdb4 and mabox is sdb3
    sudo mount /mnt/sdb4 /mnt
    sudo mkdir -p /mnt/boot/efi
  2. boot mabox live, connect to net, manjaro-chroot -a select your mabox by a number
    you are root, take care what are you doing.
    if df -h shows /boot/efi umount /boot/efi
    make a copy of /etc/fstab
    fdisk -l (shows all your partions)
    mkdir -p /install/boot/efi
    mount /dev/sdb3 /install
    mount /dev/sdb4 /install/boot/efi
    grub-install --target=x86_64-efi --efi-directory=/install/boot/efi --bootloader-id=mymabox --boot-directory=/install/boot --recheck --debug

ls -l /dev/disk/by/uuid/
find your new efi UUID and mabox UUID and rewrite both of them in fstab. Save it.
During reboot press F12 or whatever wich makes it possible to select ‘mymabox’.
Greetings from That guy

Yes I already thought about reinstalling mabox too…

May be I expressed my issue somewhat too clumsy and long-winded. I’m not a native English speaker. In my last post I wanted to point out, that no matter ”where I am” (chrooted environment, mabox fstab, suse grub.cfg) the UUID of the partition, on which my mabox system resides, is UUID=123456-example. Nevertheless the message in the emergency shell says „UUID=123456-example could not be found”.

So – during Easter I will be „afk” (as my son would say :slight_smile: ). Next week I will have a few days off; that’s a good time to think, wether I should reinstall or follow your more sophisticated procedure… I will report, how it will have come out.

Happy Easter :slight_smile:

Just keep asking if something is unclear in the description. By the way what could have caused the change of UUID. Was something replaced in your laptop?
The fastest fix boot
a live mabox
manjaro-chroot -a
select your mabox parition by a number from the list
ls -l /dev/disk/by-uuid/
search the real UUID of your partions from the ave list and replace the UUID-s in /etc/fstab. Simple duplicate the
/ (root) and efi lines and put a # to comment out the old ones.
If this is not enough replace the UUID-s in /boot/grub/grub.cfg
Max. mkinitcpio -P is needed which rebuilds images in /boot

Away from keyboard. (afk) I guess. It’s your system. No reason to hurry. Happy Easter.

Without knowing exactly how you managed this but I just edit grub directly during boot and update grub once booted. You have to know wich partition mabox is booted from.

So you can try this. No warranties :slight_smile:

  • turn on your machine, and get to the GRUB menu
  • choose mabox entry and hit the e key to enter edit mode
  • use the arrow keys to locate “quiet splash”
  • find the UUID=xxxx at the beginning of that same line
  • change the entire UUID=xxxx portion to /dev/sda1 or whatever partition your mabox installation is on. You need to know this. You don’t need to know your uuid’s but sudo blkid will show you uuid AND device info . Do that from opensuse. Which you will find the correct partition to edit in grub.
  • control+x or F10 to continue to boot after the edit
  • once booted, sudo update-grub, then reboot

Example here how to edit in grub:

From this
linux   /boot/vmlinuz-4.4.0-146-generic root=UUID=47d9205b-00a8-40e5-88d6-e8b9571799a7 ro  quiet splash $vt_handoff 

To this

linux   /boot/vmlinuz-4.4.0-146-generic root=/dev/sda1 ro  quiet splash $vt_handoff 

/dev/sda1 is an example. You need to know where your root partition is.

GRUB ain’t dangerous, just a txt file :wink:

1 Like

Maybe I overcomplicated. In a similar (?) case switching off RAID in BIOS solved the problem.
Look into this.
Edit: Before full Easter ‘afk’ I modified the UUID in fstab in mabox first root, then efi and only efi was fatal
but NOT with eroor message “mount:/new_root: cant find UUID=”
So good luck to debugging tumbleweed grub

Hi again – the good news, proceeding as Boxer suggested did the trick. I am writing from within my mabox installation right now. But: After updating grub in mabox and updating grub in opensuse the issue is the same as before.

My steps were these:

  • I started my machine
  • In (opensuse’s) grub menu I chose my mabox installation
  • hitting “e” takes me to an entry, where I replaced the UUID with sdc4 (where my mabox system resides)
  • hitting F10 boots my machine into mabox

There I ran a terminal and installed updates with command “yay”. After that I ran update-grub. This is how the mabox entry looks like in /boot/grub/grub.cfg

menuentry ‘Mabox Linux’ --class mabox --class gnu-linux --class gnu --class os $menuentry_id_option ‘gnulinux-simple-bd5e7ebc-7f64-4745-ba00-6329b39159fd’ {
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod ext2
set root=‘hd2,msdos4’
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd2,msdos4 --hint-efi=hd2,msdos4 --hint-baremetal=ahci2,msdos4 bd5e7ebc-7f64-4745-ba00-6329b39159fd
search --no-floppy --fs-uuid --set=root bd5e7ebc-7f64-4745-ba00-6329b39159fd
linux /boot/vmlinuz-5.12-x86_64 root=UUID=bd5e7ebc-7f64-4745-ba00-6329b39159fd rw quiet udev.log_priority=3
initrd /boot/amd-ucode.img /boot/initramfs-5.12-x86_64.img

And this is my fstab on mabox:

UUID=bd5e7ebc-7f64-4745-ba00-6329b39159fd / ext4 defaults,noatime 0 1
UUID=0f6d291d-9b19-42ad-bf65-7dff0ffb35b3 /home ext4 defaults,noatime 0 2
UUID=60477a50-f5fe-43e6-bed0-81317c243f72 /media/db_Digikam ext4 defaults,noatime 0 1
UUID=9cbb87bf-00c9-47e6-a52e-120e64ce2872 /media/Karton ext4 defaults,noatime 0 1
UUID=394e4ed9-fdbd-4aa5-b5c6-e3f09c37f434 /media/Backup_Homes ext4 defaults,noatime 0 1

This is /boot/grub2/grubcfg with regards to mabox in opensuse

menuentry ‘Mabox Linux (23.03) (on /dev/sdc4)’ --class maboxlinux --class gnu-linux --class gnu --class os $menuentry_id_option ‘osprober-gnulinux-simple-bd5e7ebc-7f64-4745-ba00-6329b39159fd’ {
insmod part_msdos
insmod ext2
set root=‘hd2,msdos4’
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd2,msdos4 --hint-efi=hd2,msdos4 --hint-baremetal=ahci2,msdos4 bd5e7ebc-7f64-4745-ba00-6329b39159fd
search --no-floppy --fs-uuid --set=root bd5e7ebc-7f64-4745-ba00-6329b39159fd
linux /boot/vmlinuz-5.12-x86_64 root=UUID=bd5e7ebc-7f64-4745-ba00-6329b39159fd rw quiet udev.log_priority=3
initrd /boot/amd-ucode.img /boot/initramfs-5.12-x86_64.img

UUID bd5e7ebc-7f64-4745-ba00-6329b39159fd is the one, that, as to the message in the emergency shell, could not be found when I try to boot into mabox from opensuse grub menu.

Tocomplete some information: No, I did not change any hardware in my desktop PC. I did not change anything in fstab (mabox or opensuse). The issue appeared “all of a sudden”. The only thing I can remember is, that I updated mabox, rebooted – and the problem occurred.

Oh, and as far as I can see, RAID is disabled in my BIOS.

I always thought (and have been using so) that if I select a ‘master’ system that updates the grub.cfg.
and finds the updated kernels of the other ‘slaves’. There is no need to run update-grub or grub-mkconfig -o /boot/grub/grub.cfg. It makes sense only if they work with separate efi partions and can be selected from BIOS.

zolw is right. No need to update grub after updates.

But: After updating grub in mabox and updating grub in opensuse the issue is the same as before.<

Don’t update grub in both opensuse and mabox - update only in mabox- The entry for opensuse will be written and if you update linux grub will be updated . Just restart.

So log into mabox and run yay -S linux linux-headers and check that your /dev/sdc4 is in the mabox menyentry in grubcfg before you reboot. Change it if necessary.

Don’t update grub from every os. Just leave it when you get it to work and you will be able to boot into both systems.

I followed your steps… with no success. But perhaps I did something wrong. Therefor two questions:

  • After reinstalling the linux headers I changed the entries in grub.cfg, that look like the entries I saw after hitting “e” in boot menu. I. e. I changed the UUID=blablabla to /dev/sdc4 in mabox grub.cfg. But there are a lot more instances of the UUID. Do I have to replace them all, in every line I find one?
  • When I checked the mabox entry in the boot menu after following your suggestions, it still shows the UUID instead of /dev/sdc4. So, don’t I have to modify the opensuse grub2.cfg instead of mabox grub.cfg?

I am going to step back. Boxer will lead you out of this ‘mess’ I hope.
It is dangerous and not recommended to edit /boot/grub/grub.cfg.
Once you get into mabox. Install grub-editor. Yes, there are several NO-NO-s like grub-customizer, etc.
but it is a so simple GUI app. that it may help. Plus there is a possibility to make snapshots (copies) at a given time. So,
yay -S grub-editor

1 Like

You are booting from opensuse grub2 system? That is also where you edit the entry for mabox? If thats the case then boot into opensuse and post the output of lsblk -s and blkid.

Also post this from terminal : lsblk -s | sed -nr ‘/[[:blank:]]+/$/,/disk[[:blank:]]*$/p’

This will query root disk.

I suspect you installed grub in mabox in a partition you made? Like /dev/sda4 and not in root disk? Root disk will in this case be /dev/sda. Thats why opensuse boots fine because that is installed correctly . When you install another system you choose the same disk to install grub in. It will overwrite grub but it will work.

nvme0n1p2 259:2 0 64,2G 0 part /
nvme0n1 259:0 0 953,9G 0 disk

This is my root disk . My grub is installed in nvme0n1 wich is not an partition. It is marked with disk not part. You need to install grub in sda - NOT sda4 or whatever hard drive you are booting from.

If you can’t fix it try grub-editor or grub-customizer

Last chance is to boot a live system like this and fix it : boot-repair-disk / Home / Home

So – thank you for your help, zolw :slight_smile:

Back to business… Yes tumbleweed is the “master” OS (I tried to say that in my very first post); Windows and Mabox are kind of slaves. On start-up suse’s grub menu offers all options. For several years all went well. Now something is broken with Mabox.

lsblk -s
loop0    7:0    0 218,4M  1 loop /snap/gnome-3-34-1804/90
loop1    7:1    0   219M  1 loop /snap/gnome-3-34-1804/77
loop2    7:2    0  81,3M  1 loop /snap/gtk-common-themes/1534
loop3    7:3    0  91,7M  1 loop /snap/gtk-common-themes/1535
loop4    7:4    0 260,7M  1 loop /snap/kde-frameworks-5-core18/32
loop5    7:5    0 116,8M  1 loop /snap/core/14784
loop6    7:6    0 289,8M  1 loop /snap/kde-frameworks-5-core18/35
loop7    7:7    0 164,8M  1 loop /snap/gnome-3-28-1804/161
loop8    7:8    0  55,6M  1 loop /snap/core18/2721
loop9    7:9    0 116,8M  1 loop /snap/core/14946
loop10   7:10   0     4K  1 loop /snap/bare/5
loop11   7:11   0 164,8M  1 loop /snap/gnome-3-28-1804/194
loop12   7:12   0  55,6M  1 loop /snap/core18/2714
sda1     8:1    0 118,6G  0 part 
└─sda    8:0    0 119,2G  0 disk 
sda2     8:2    0   635M  0 part 
└─sda    8:0    0 119,2G  0 disk 
sdb1     8:17   0    80G  0 part /var
│                                /usr/local
│                                /tmp
│                                /opt
│                                /srv
│                                /root
│                                /boot/grub2/x86_64-efi
│                                /boot/grub2/i386-pc
│                                /.snapshots
│                                /snap
│                                /
└─sdb    8:16   0 232,9G  0 disk 
sdb2     8:18   0    40G  0 part /home
└─sdb    8:16   0 232,9G  0 disk 
sdb3     8:19   0   8,1G  0 part [SWAP]
└─sdb    8:16   0 232,9G  0 disk 
sdb4     8:20   0   2,5G  0 part /boot/efi
└─sdb    8:16   0 232,9G  0 disk 
sdb5     8:21   0  58,6G  0 part /drives/db_Digikam
└─sdb    8:16   0 232,9G  0 disk 
sdb6     8:22   0  43,7G  0 part /drives/Karton
└─sdb    8:16   0 232,9G  0 disk 
sdc1     8:33   0  58,6G  0 part 
└─sdc    8:32   0 465,8G  0 disk 
sdc2     8:34   0 232,9G  0 part 
└─sdc    8:32   0 465,8G  0 disk 
sdc3     8:35   0 135,2G  0 part 
└─sdc    8:32   0 465,8G  0 disk 
sdc4     8:36   0  39,1G  0 part 
└─sdc    8:32   0 465,8G  0 disk 
sdd1     8:49   0 298,1G  0 part 
└─sdd    8:48   0 298,1G  0 disk 
/dev/loop1: TYPE="squashfs"
/dev/sdd1: LABEL="Backup_Homes" UUID="394e4ed9-fdbd-4aa5-b5c6-e3f09c37f434" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="cfbd418a-01"
/dev/loop8: TYPE="squashfs"
/dev/sdb4: UUID="C43C-EF04" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="66f2fdb8-aa7f-45b6-b4f7-6b7714b1d30e"
/dev/sdb2: UUID="68a89f76-30ec-468a-b92e-627f3c900d4e" BLOCK_SIZE="512" TYPE="xfs" PARTUUID="79e01f9d-557f-455d-8f5f-a5537a95fcab"
/dev/sdb5: LABEL="db_Digikam" UUID="60477a50-f5fe-43e6-bed0-81317c243f72" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="db_Digikam" PARTUUID="da52adb5-80b5-4b3e-a0e5-40d9c70f5a56"
/dev/sdb3: UUID="91555ea7-604c-42e0-bb9a-0322ea43fc1b" TYPE="swap" PARTUUID="ca1269d6-7846-4400-801d-d7ddad3a3e63"
/dev/sdb1: UUID="a2e79ec2-6ff7-4a5c-b6d0-ce339dae8f72" UUID_SUB="19f0bf60-e0e8-4ae1-a9b1-2897f670af6c" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="e0f4378d-0b66-4396-acd9-d57673f54ce1"
/dev/sdb6: LABEL="Karton" UUID="9cbb87bf-00c9-47e6-a52e-120e64ce2872" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Karton" PARTUUID="f7b73e20-6418-4d1e-bc89-ddad69f89348"
/dev/loop6: TYPE="squashfs"
/dev/loop4: TYPE="squashfs"
/dev/loop11: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop0: TYPE="squashfs"
/dev/loop9: TYPE="squashfs"
/dev/sdc2: LABEL="WNDWS_Games" BLOCK_SIZE="512" UUID="748CEBE50746B333" TYPE="ntfs" PARTUUID="69c3c599-02"
/dev/sdc3: LABEL="LNX_DTN" UUID="45de859b-0a86-4813-86da-fae1940e22cd" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="69c3c599-03"
/dev/sdc1: LABEL="Mabox_Home" UUID="0f6d291d-9b19-42ad-bf65-7dff0ffb35b3" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="69c3c599-01"
/dev/sdc4: LABEL="Mabox_Sys" UUID="bd5e7ebc-7f64-4745-ba00-6329b39159fd" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="69c3c599-04"
/dev/loop7: TYPE="squashfs"
/dev/sda2: BLOCK_SIZE="512" UUID="82AA13DDAA13CD13" TYPE="ntfs" PARTUUID="16ece2ba-7f03-4bb8-9b73-61faabf10012"
/dev/sda1: LABEL="BOOTCAMP" BLOCK_SIZE="512" UUID="E6F6DE30F6DE00AB" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="8e932edf-3c3d-42fe-ae39-ef20664146bd"
/dev/loop5: TYPE="squashfs"
/dev/loop12: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"
/dev/loop10: TYPE="squashfs"

Unfortunately I am unable to apply the last command. It results in:
sed: -e Ausdruck #1, Zeichen 1: Unbekannter Befehl: »�«
which means: sed: -e expression #1, character 1: unknown command: »�«

meanwhile I found the correct command line:
lsblk -s | sed -nr '/[[:blank:]]+\/$/,/disk[[:blank:]]*$/p'
BTW are you on Btrfs as I see?

Yes, Btrfs is opensuse’s standard for system partitions; /home normally is xfs-formated.

Here’s the output:

ceos@linux-ctqv:~> lsblk -s | sed -nr '/[[:blank:]]+\/$/,/disk[[:blank:]]*$/p'
│                                /
└─sdb    8:16   0 232,9G  0 disk