Manjaro not booting again

Wollie is again generally correct.
But must add that it is important to 'create partition table' (msdos for bios-legacy) before doing the installation. I also suspect that we should not use 'erase disk' at the installer as (I suspect) this clears the partitioning table.

Fully agree gohlip, full partitioning best to be done by GParted before installation and skipping the formatting part during istallation of Manjaro.

1 Like

It is late here and I had quite a hectic day. I may log off soon but please carry on with others.
And ... when all is done, later on, please tell us why your forum profile is hidden. I use this to check previous topics of the user and see if there are relevant issues affecting the topic at hand. You, in fact had several topics affecting this issue and it is a hassle trying to go through them with your hidden profile. If there is a good reason, and if it is personal please PM me. But (funnily), if it is personal enough, you don't have to PM me.

Model: SanDisk Cruzer Blade (scsi)
Disk /dev/sde: 8004MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 2      2143MB  2148MB  4194kB  primary               esp

Model: ATA Samsung SSD 840 (scsi)
Disk /dev/sdf: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End    Size   Type     File system  Flags
 1      1049kB  106MB  105MB  primary  ntfs         boot
 2      106MB   250GB  250GB  primary  ntfs

Model: ATA Samsung SSD 860 (scsi)
Disk /dev/sdi: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End    Size    File system     Name  Flags
 1      2097kB  317MB  315MB   fat32                 boot, esp
 2      317MB   491GB  490GB   ext4
 3      491GB   500GB  9449MB  linux-swap(v1)

Model: ATA TOSHIBA DT01ACA1 (scsi)
Disk /dev/sdg: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name                          Flags
 1      17.4kB  134MB   134MB                Microsoft reserved partition  msftres
 2      135MB   1000GB  1000GB  ntfs         Basic data partition          msftdata

Model: ATA ST4000DM000-2AE1 (scsi)
Disk /dev/sdh: 4001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name                          Flags
 1      17.4kB  134MB   134MB                Microsoft reserved partition  msftres
 2      135MB   4001GB  4001GB  ntfs         Basic data partition          msftdata

a,b,c,d are just placeholders for the usb sd card reader. e is the USB live media, f is the drive with windows on it, i is the drive with manjaro on it, g is my backup disk and h is my films disk.

Sounds like this might be my problem then, but am I right in that gpt with uefi is the more up to date method? If so I don't really want to put my new permanent Linux system into the old partition method just for the short while I intend to have Windows around for. I'm not anticipating a dual boot system, just want a little 'transition time' as it were. So really, I'm looking for some way to keep manjaro on gpt/uefi. I'd rather Windows was limping along in the wrong mode, if that's possible?


# /etc/fstab: static file system information.
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=9DF9-4D99                            /boot/efi      vfat    defaults,noatime 0 2
UUID=033b44b8-3e08-4303-b114-319d041f860a /              ext4    defaults,noatime,discard 0 1
UUID=57c120dd-6a88-49b9-8510-c2ad220f8401 swap           swap    defaults,noatime,discard 0 2
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0

So much easier than chrooting! Thanks

As mentioned to gohlip, really I'd rather ditch Windows and keep Linux on the gpt/uefi, if I can just get it back somehow?

I have to go too, so will pick this back up tomorrow. Thanks everyone.

One important but often overlooked point.
Needs confirmation.

Is your manjaro drive (ATA Samsung SSD 860) an external drive ?
I think not, but needs confirming.
And even if it is an internal drive, have you disconnected the sata cables to it and then finding out it cannot boot?

Please try to boot up Manjaro installed OS using this first post.. Start up computer in uefi mode. And if [Simple First Start] doesn't boot up, use [More Complicated Setup].
You had mentioned somewhere you failed to boot manjaro using this method. This time tell us more clearly where/what error message/which stage it fails. If you cannot use this method, you will need to try to chroot (but seriously, there is no reason why this method would fail if chroot can succeed). And it is easier and safer than chroot.

If booted up, at that link, do the grub-install commands and the 2 [Additional UEFI commands].
And provide output of 'efibootmgr' after completing everything.
If in the event the process succeeds but fails to reboot normally, boot up again using same method and print again 'efibootmgr' and check the [Asus Difficult setup] section of that link.

Good night.

As to the other questions on gpt/uefi vs msdos/bios-legacy, one can argue that gpt/uefi is 'better' or 'up-to-date' but I personally think that for practical purposes, the difference is not significant. Multibooting with many OS's and drives may be easier though with gpt/uefi.

if you dont care much about the windows install but would prefer not to lose it because you want to go full uefi. theres a windows program mbr2gpt that converts your MBR windows install into a UEFI windows without losing anything

disclaimer: i've never used it, this is not a suggestion to use it and just an option for you to check out further should you want to.

No, it's internal.

Not knowingly. I suppose in theory a cable could have come loose, but then it would have had to re-attach itself, so unless we're suggesting gremlins... Which at this stage I'm seriously considering.

OK. I managed to boot into my installed OS using your simple method (steps 1-3) by configuring my CSM to "UEFI first" (though not when in "UEFI only", which is curious). All other drives go away from the boot options leaving only the UEFI SanDisk (the live USB). I boot to that, follow your first set of instructions and it boots to my installed OS.

I carried out step 4, tried to boot again but now the UEFI bios control screen just freezes when I try to select any boot device. I turn the computer off, enable full CSM, and both Windows, and the LiveUSB will boot fine.

Why on earth is CSM required to boot what should be a UEFI boot?

Also, interestingly, step 4 seemed to work fine in the simple version despite the fact that I definitely do have a separate boot partition. I didn't need the variation described.

Anyway... I'm about to try your additional commands for UEFI, but, for the sake of my continued personal growth (and to minimise future impositions on your time) I'd really like to know what it is that these commands are doing. I followed what's happening with the commands up to here (we're borrowing the liveUSB bootloader, but telling it to boot the OS that's on sda, then re-installing the grub to that drive?). But I don't really understand what these next commands are doing, and I like to learn as I go.

Thanks. Might give it a try. I'm ditching Windows eventually so I've got nothing to lose.

I would recommend to double check if you really want to use mbr2gpt as this seems to be a tool designated for Win10 installations and not Win7. There are also other suggestions for such a conversion you can find in the net but hard to say if they really will work.

Yes, I noticed when looking it up that it's only for Windows 10, the avoidance of which is no small part of the reason I'm converting to Linux, so probably not an option.

@Wollie, @gohlip

Just to update, in case it matters. Scrap the last bit I wrote about booting to my installed OS by changing the CSM settings. I've just tried to do so again and every single setting bring up the "error : no such device /etc/manjaro-release".

So I'm afraid I haven't the faintest idea why it worked once, I can't seem to replicate it.

Stuff I've checked -
secure boot is off
Live USB is in UEFI mode
search.file /etc/manjaro-release {without root} - same error.
Booted into live OS, checked devices

Have your tried
as SGS recommended?

Sort of. Coincidentally I've just finished trying to repair the bootloader using chroot following the instructions on the Manjaro wiki. All went well, recorded no errors, had to use efivarfs, but fine after that. Exited chroot, rebooted... Now my bios doesn't even show the hard drive Manjaro is on as an option. I can't even try to boot to it because it's not there. I didn't think I could actually make the situation even worse!

This thing bothers me.

Do you need this card reader?
Can you remove this and try it out.
Not having sda on the internal primary drive is never a good thing.

Your bios cannot detect the drive (The OS can, when booted up).
I think it has to do with that card reader.

You can do the things both per my link and chroot because the OS can see it.
But when you try to boot, the bios cannot.

The primary drive must be connected to the primary cable.
This I think is where your problem lies.

Now Windows won't even load, system repair reports a problem with system files.

I opened the bios... Did absolutely nothing, just looked at stuff, closed it, and restarted... Now Windows opens (after a much longer time than normal), loads a driver for the second ssd (despite it being in place for six weeks).

Excuse my French, but what the f*&# is going on! I haven't even done anything to Windows, you guys have a complete record of every command I've issued, I haven't even touched the drive with Windows on it.

The computer's internal workings are not that easy to access (various furniture related reasons), but I can try it. Before I do though, am I wrong in thinking anything which has been done by software can be undone by software? I mean Manjaro did load. I had it running, loaded some applications, altered the desktop colours, booted into Windows, booted back into Manjaro... Everything was working fine, all the while I had this card reader in place. I'm fine to ditch the card reader, but unless I know how this happened, how am I going to prevent it happening again? If Manjaro can load fine, appear to work, and then just fail to boot without being able to identify a cause, is there anything to stop this from happening in three month's time when I'm two days away from a work deadline? I'm concerned that if I take the card reader out and everything works, I still won't have identified what really caused the problem because it was obviously fine with the card reader the first time I installed. Does that make sense?

mbr + gpt = :bomb:

The cause may be in the UEFI BIOS: Not every motherboard consistently adheres to the BIOS setup setting for UEFI or BIOS boot mode.

In your case that was initially to your advantage: Although the motherboard was set to the UEFI mode, it recognized only when installing and then every time you start Windows 7 that the operating system oldie could boot only in BIOS mode - whereupon the Motherboard just started secretly in BIOS mode each time it started up, although something else was set.

But now you have booted from the Linux installation media and this can also start in UEFI mode. Therefore, the motherboard remained in this mode when starting up. And because a suitable UEFI boot entry is added during the installation of Linux in UEFI mode, the motherboard now finds a UEFI-compatible boot loader every time it is started. There is no reason to secretly switch to BIOS mode. This in turn had an effect during the installation of Linux: Because Windows 7 can not boot in the currently active UEFI mode, the Linux setup program found no further bootable Windows, so it could not integrate Windows 7.

It looks like a firmware (UEFI/BIOS) issue.
Let it rest for a while (unplug from power, remove BIOS battery) to reset settings and start over.

Let me repeat what I said but in a different way.
Your bios does not see all your drives, and grub takes only what your bios sees.
If bios does not see your manjaro drive, grub will not see that drive.

OS's, when booted up, (usually) can see all the drives. The OS does not need the bios to tell it what the drives are (but gives it a different sda, sdb ....from the bios (hd0) (hd1)...)
grub on the other hand cannot see anything. It needs the bios to tell it what the drives are.
So if the bios cannot see a drive, grub cannot boot it.
And if a grub is on the drive that the bios cannot see, there will not be a grub menu appearing; and your system obviously cannot boot that grub OS and the bios will go to the next bootloader, windows, if that is the only other one, regardless if you have tried to tell the bios to use uefi or bios-legacy (unless your bios is set to use only one mode - see your own post (post # 27) on this).

A further note - even if you do not have that card reader and say you have 6 disks connected to your internal sata, some older (>2 years) motherboard bios may not even detect all 6 disks. Some must have only the booting sata in sata0 and sata1, meaning the bios will not even see the other 4 sata drives but the OS, upon booting up can certainly see all 6 drives.

So, after taking out your card reader, make sure your manjaro and windows drives are in sata0 and sata1.

There is a common misconception that installing each OS in different drives are good. Fine, make sure then you have only 2 OS's if your motherboard is not up to speed. And here you are, you have the card reader taking up 4 'top' drive 'slots' even without anything on it.

Of course, I cannot guarantee you anything, so if you have your work dateline to worry about (or not), the decision is entirely yours. So is the liability.

1 Like

Forum kindly sponsored by