Manjaro gnome 17.0.1 686 crashes during install




Running Intel Core2Duo, Intel motherboard, 4GB RAM.

I can start Manjaro Gnome 32 bit 17.0.1 from DVD.

I start the installer and it takes all input like KBD, locale, user name and pwd.
When it comes to the actual install, the window vanishes. No error messages.

I tried this several times, with same result.

I did this with the 64 bit version also, with same result.

Is there a problem with my computer?



Hi, @srikk. Sorry it’s been a while since someone answered. The most common problems are:

  • A bad download. Did you check it?
  • A bad burn. If using Windows and Rufus, you must use DD mode. In Linux, ‘dd’ works best.
  • Hardware. Tell us everything you know about yours.

Welcome to Manjaro Linux! :smiley:




Thanks for reply.

I ran gpg and sha1sum on the iso files. No errors. gpg said good signature.
And the checksum matches.

I am now running Linux Mint 32 bit. I downloaded it in this and burnt on DVD using brasero.

About the hardware:

This is from lscpu

Architecture: i686
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 15
Model name: Intel® Core™2 CPU 6420 @ 2.13GHz
Stepping: 6
CPU MHz: 2128.000
CPU max MHz: 2128.0000
CPU min MHz: 1596.0000
BogoMIPS: 4262.28
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 4096K
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow dtherm

Other Info:
description: Motherboard
product: D946GZIS
vendor: Intel Corporation
physical id: 0
version: AAD66165-501
serial: AZIS71100A4V
slot: Base Board Chassis Location

            description: VGA compatible controller
            product: G73 [GeForce 7300 GT]
            vendor: NVIDIA Corporation
            physical id: 0
            bus info: pci@0000:01:00.0
            version: a1
            width: 64 bits
            clock: 33MHz
            capabilities: pm msi pciexpress vga_controller bus_master cap_list rom
            configuration: driver=nouveau latency=0
            resources: irq:28 memory:e1000000-e1ffffff memory:d0000000-dfffffff memory:e0000000-

      description: BIOS
      vendor: Intel Corp.
      physical id: 4
      version: TS94610J.86A.0047.2006.0911.0110
      date: 09/11/2006
      size: 64KiB
      capacity: 448KiB
      capabilities: pci upgrade shadowing cdboot bootselect edd int9keyboard int14serial int17printer int10video acpi usb zipboot biosbootspecification netboot

      description: System Memory
      physical id: 17
      slot: System board or motherboard
      size: 4GiB

I am installing it on a Seagate Green 1TB disk which already has Linux Mint and Windows 7. It has grub installed.

DVD writer + other HDD

Anything else you need?


  • It may boil down to the differences in how the Intel ucode is installed.
  • Also, have you tried booting in non-free mode?
  • And finally, if at all possible burn the ISO to a USB key using ‘dd’. CD/DVDROMs sometimes have problems.

And for your edification, a treatise on why you shouldn’t do what you’re doing, from: EFI Booting, Dual-Booting

  • Recommendations

  • The following are AdamW’s General Recommendations On Managing System Boot, offered with absolutely no guarantees of accuracy, purity or safety.

  • If you can possibly manage it, have one OS per computer. If you need more than one OS, buy more computers, or use virtualization. If you can do this everything is very simple and it doesn’t much matter if you have BIOS or UEFI firmware, or use UEFI-native or BIOS-compatible boot on a UEFI system. Everything will be nice and easy and work. You will whistle as you work, and be kind to children and small animals. All will be sweetness and light. Really, do this.

  • If you absolutely must have more than one OS per computer, at least have one OS per disk. If you’re reasonably comfortable with how BIOS-style booting works and you don’t think you need Secure Boot, it’s pretty reasonable to use BIOS-compatible booting rather than UEFI-style booting in this situation on a UEFI-capable system. You’ll probably have less pain to deal with and you won’t really lose anything. With one OS per disk you can also mix UEFI-native and BIOS-compatible installations.

  • If you absolutely insist on having more than one OS per disk, understand everything written on this page, understand that you are making your life much more painful than it needs to be, lay in good stocks of painkillers and gin, and don’t go yelling at your OS vendor, whatever breaks. Whichever poor ■■■■■■■ has to deal with your OS’s support for this kind of setup has a miserable enough life already. And for the love of cookies, don’t mix UEFI-native and BIOS-compatible OS installations, you have enough pain to deal with already.

  • If you’re using UEFI native booting, and you don’t tend to build your own kernels or kernel modules or use the NVIDIA or ATI proprietary drivers on Linux, you might want to leave Secure Boot on. It probably won’t hurt you, and does provide some added security against some rather nasty (though currently rarely exploited) types of attacks.

  • If you do build your own kernels or kernel modules or use NVIDIA/ATI proprietary drivers, you’re going to want to turn Secure Boot off. Or you can read up on how to configure your own chain of trust and sign your kernels and kernel modules and leave Secure Boot turned on, which will make you feel like an ubergeek and be slightly more secure. But it’s going to take you a good solid weekend at least.

  • Don’t do UEFI-native installs to MBR-formatted disks, or BIOS compatibility installs to GPT-formatted disks (an exception to the latter is if your disk is, IIRC, 2.2+TB in size, because the MBR format can’t handle disks that big – if you want to do a BIOS compatibility install to a disk that big, you’re kinda stuck with the BIOS+GPT combination, which works but is a bit wonky and involves the infamous ‘BIOS Boot partition’ you may recall from Fedora 17).


I am copying this for future forum interactions, thanks. :grinning:

Now for something more serious, You seem to have a 32bit boot thing on a 64bit cpu.
Can you tell us what kind of hardware it is?
Also try the other options on install screen, non-free driver or other.


I would try a different ISO, maybe the newest ones, they are based on Stable branch already:


Just a pet peeve of mine in someone else’s words. It won’t stop anyone doing it, but at least we can say “I told you so.”

Yep. 32-bit is nowadays a strange-breed-of-cat. Most of us–not all, but most–are using x86_64, 64-bit ISOs on our 64-bit computers. Using a 64-bit ISO might make it easier for us to help you, I dunno. For that, I’ll defer to @eugen-b’s expertise. :smiley:

Buena Suerte!


I tried both 64 bit and 32 bit, with same result.

I will try the non-free mode.

Right now, I can only try to install the OS on the same disk along with others (Mint). I cannot remove Mint as it is my main OS now.

I tried to use a USB pendrive also. But I got the same result. The installer window just vanishes.

I do have another spare drive, and I will try to install on that.

Meantime, I am also waiting for the new release of Manjaro 17.0.2. When is the release date for the stable version (not the rc)?



Last night I recall reading a post from @philm regarding some issues Manjaro is having with i686 (which probably originated with Arch). I believe it may have been an announcement regarding Unstable updates. but am not sure.

Your plan for trying 17.02 is probably a good idea.




I got the new 17.0.2 - 64 bit and burnt it to DVD - on low speed.

I installed this on another HDD. The Live system started fine and the installation was also good.

But the problem started after that.

When i tried boot this system, it halts with this message:

kernel panic - not syncing. VFS: unable to mount root fs on unknown block(0,0).

What is the problem here?

Q1: Where should put the boot loader for this? On the same HDD or another HDD which has the other OSes?



You need to add some hook to /etc/mkinitcpio.conf, but I don’t know which one.

Plymouth is gone from Manjaro, so I don’t know which other hook might be missing.
Best thing, boot with a live medium and check /etc/mkinitcpio.conf on disk and tell ud which hooks are present.


I checked with the Live system and I found this in mkinitcpio.conf

HOOKS=“base udev autodetect modconf block filesystems keyboard fsck”

The entry in the installed system is:

HOOKS=“base udev autodetect modconf block keyboard keymap resume filesystems fsck”

Should I change this entry?



Can you check via livesystem if the uidd for any partition is the same of the fstab file ?


This is the entry in fstab

UUID=528291af-d068-4ff4-8a81-c5bf861bfca2 swap swap defaults,noatime 0 0
UUID=10f9cea2-34a5-4d8b-9db1-19761fcfba83 / ext4 defaults,noatime 0 1

The UUID is correct.

Note that the swap is on another HDD.



Looks ok.
Then it could be that you installed a UEFI system on a disk with MBR partition table insteda of GPT. Is it the case? No the system is too old for that.

My proposal would be to install with manjaro-architect. I actually always propose that if an install with Calamares fails.
To do that boot with any Manjaro Live medium, install manjaro-architect package and run
sudo manjaro-architect

Here is a tutorial with screenshots:


Tried with manjaro-architect.

Did a reformat of the partition and did normal install, following the instructions in the tutorial.

I still cannot boot it. I see the entry in the grub menu, but it halts with the same error:

kernel panic - not syncing: VFS: unable to mount root fs on unknown block (0,0)

Before quitting the installer, I did make proper changes to the fstab file.

Still no progress. :tired_face:




This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.