I shut down my system before the hurricane could kill my power. When I got power back, first the mSATA boot drive couldn’t be found so I opened the case and reset it. Then it would boot into windows as Manjaro didn’t show up in UEFI. I chrooted into it from the live CD and did a grub-install. Now I get the grub menu but when it goes to boot, it drops to intramfs saying it can’t find 4e18be9d-1c64-41af-8e57-e7ca2cf5b6ee. I chrooted from the live CD again and when I try grub-mkconfig or update-grub, I get this error:
etecting snapshots …
mount: /tmp/grub-btrfs.zLtPydWVoB: special device /dev/disk/by-uuid/4e18be9d-1c64-41af-8e57-e7ca2cf5b6ee does not exist.
dmesg(1) may have more information after failed mount system call.
If I type blkid or lsblk- f, no UUID is listed for my root partition. Only if I type file -s /dev/sda4 do I get a UUID and it’s c29fdc05-ea12-4e06-8421-24cde767c946. fstab has this UUID as the root partition and that other number isn’t in fstab at all. I tried to add it to fstab to no effect.
Where is grub getting that missing UUID from and why can’t I overwrite it with the real UUID?
Edit: not home now but I’m pretty sure /boot/grub/grub.cfg had the correct UUID.
With power surges it’s best to unplug devices. Doesn’t help you now, but in the future. To fix, I’d get a ISO on a flash drive, and try to recover what ever you can from the drive, or maybe your Windows OS can see it, there are utilites that allow it to work with ext3/4 formatted drives If not it will take professional help, which is expensive and often provides only partial data.
The hardware is fine. I have an inverter and switched off the main. I turned it off to save battery for the fridge and TV. I also ran btrfs check on the partition. The grub.cfg is correct, I just need grub to use it. I thought that’s what grub-install did.
I am using the same image I installed from and chrooted from that using manjaro-chroot. I’m following the wiki on GRUB/Restore.
I don’t think the problem is with grub. I think it’s the manjaro-chroot environment. I’m going to hand edit the file at boot time with the correct UUID.
I did check and verify. Typing in the correct UUID didn’t help. It still dropped to initfs or what ever it’s called. I think that rules out grub. I installed manjaro on another partition so I don’t have to use the live CD and that clobbered grub so it now dumps to grub console.
I got rid of the error with mkconfig by removing 41_snapshot_btrfs and found out grub-probe thinks the partition is ext2. I still get the wrong UUID. A diff of the old config and the new ones show that insmod btrfs is being replace with insmod ext2. That’s why it didn’t boot even after I edited in the correct UUID at the grub menu.
Yeah, I converted to btrfs a while back. This is the first time I’ve had an issue. I think after my last update, grub identified the partition as ext2 and I don’t know where the wrong UUID came from but maybe it’s the old UUID from before I converted. I need to find someone who knows where grub-probe gets it’s information. I have os-prober disabled and the btrfs snapshot scan disabled till I can figure this out. I heard some kernals cause problems with btrfs so I’ll look into that. Thanks for helping though.
Yeah, it sounded great but I might just switch back because there is so much more to be aware of. I got some ideas to try tomorrow like putting my config for that partition in 40-custom so mkconfig doesn’t try to change it and I have to make sure btrfs is in the mkinitcpio.cfg. but then I have to edit it when the kernal is updated.
Yeah, I tried the latest iso. I’ll try that link but I think I isolated the problem and that is os-prober and grub-probe thinks my btrfs partition is ext2 and has a different UUID than it actually has.
It’s usually safe to leave os-prober enabled. One scenario where this might be desirable is when wishing to boot an OS on an external disk via Grub. Or, as @Nachlese suggested, if you multiboot with another OS; such as Windows or BSD.
Please post full system information so everyone can see what is going on under the hood
inxi -v8z
Did you have the computer and fridge plugged in to the inverter at the same time?
Thinking that a fridge switching on and off might cause momentary power drops or spikes to the system but I would not expect that to change UUID or partition format
I am not familiar with BTRFS either, but if system cannot find a a bootable partition I suspect it may not be able to find snapshots to restore the partition
I got it booting. I’m not sure what worked because I did several steps at once.
First I used gparted to remove the efi and microsoft reserve partitions and recreated the EFI partition and a boot partition. I copied the EFI and boot files to them.
Next I mounted -t btrfs /dev/sda4 /mnt, -t ext2 /dev/sda2 /mnt/boot, and -t vfat /dev/sda1 /mnt/boot/efi. I didn’t use manjaro-chroot this time, instead I did mount --bind /dev /mnt/dev, -t sysfs sysfs /mnt/sys, -t proc proc /mnt/proc, and -t efivarfs efivarfs /mnt/sys/firmware/EFI/efivars. Then chroot /mnt /bin/bash. I thought manjaro-chroot did all that but I wanted to make sure.
Next I edited fstab to add /boot and /boot/EFI. I ended up just using /dev/sdaX instead of UUIDs. I then did an update_grub and looked at the grub.cfg. It still have the wrong UUID and my custom menu which has never turned up in the grub menu was there with the correct UUID.
I didn’t think it would work but I exited and rebooted and it skipped the grub menu and booted right up.
