First install beside Win7, boot fails with error: sparse file not allowed

This is my first time trying Manjaro, and I seem to have confused the installer (or myself...)

Original setup (Windows 7 Pro 64bit)
1TB NVME drive. MBR Partition table (for historical reasons)
Partition 1: System Reserved
Partition 2: C Drive

2TB HDD. GPT Partition table
Partition 1: Windows swap file and tmp (NTFS)
Partition 2: Linux swap (to be added "swapon" after basic install)
Partition 3: Backup (ext4)
Partition 4: Share (NTFS)

Added Manjaro boot disk
500GB SSD. GPT partitions
Partition 1: /boot/efi (1GB fat32)
Partition 2: /boot (1GB btrfs)
Partition 3: / (16GB btrfs,)
Partition 4: /var (100GB ext4)
Partition 5: /usr (300GB btrfs)
Partition 6: /home (70GB btrfs)

System (Asus Z97M Plus) is set to hybrid boot, UEFI then MBR. Initially I'd be happy to be able to boot manually into Win7 or Manjaro via to BIOS boot menu, then i'll worry about a boot chooser.

The Manjaro installer ran to completion, but after a reset-

  • Booting into Windows from the NVME drive is fine, as before

  • Manjaro fails to boot with error:

error: sparse file not allowed
press any key to continue

If I hit return I see error like:

ERROR: Root device mounted successfully, but /sbin/init does not exist
Bailing out, you're on your own. Good luck.

In the motherboards BIOS boot menu I notice I have two boot options on the SSD, one is called something like "boot-EFI" and the other one is called "Manjaro-"

Have I confused the installer by setting up a separate mount point for /boot/efi and /boot? (this is a setup I have use before on Debian, which is why I copied it here).

Any ideas would be great.

Yep, that's because you chose btrfs for /boot. The Manjaro version of GRUB ─ which was derived from Fedora ─ does not support btrfs.

The solution is to either format /boot as ext4, or ─ which will be easier in your case, given your additional problem below ─ to install grub-vanilla from within a chroot environment.

Yes, that's because of an already old deficit in the creation of the initramfs, which in my humble opinion should have already long been fixed ─ I am hereby going to ping @philm in the hope that he'll see this.

The default configuration of the initramfs ─ which in Manjaro is taken care of by mkinitcpio ─ does not include support for a separate /usr filesystem. Yet, even though most Manjaro users won't install their systems with a separate /usr, it would create no performance hit for anyone, nor any other kind of overhead, to include the required hooks in the default /etc/mkinitcpio.conf.

The required hooks for booting with a separate /usr filesystem are [usr], [fsck] and [shutdown]. @philm, please add these to the default configuration ─ thank you. :beer:

Nope, it's because of those two issues, i.e. to recap...:

  • The Manjaro-specific version of GRUB has no support for btrfs; and
  • The default Manjaro configuration of /etc/mkinitcpio.conf has no support for a separate /usr filesystem.

The good news is that it can all be fixed, but you're going to have to do this from within a chroot environment while booted up from your install medium ─ whether it's a CD/DVD or a USB stick.

So, make sure you boot up from the install medium, and then open up a terminal window. In said terminal window, you must mount your installation's /, /boot, /usr, /var and /boot/efi, and you have to bind-mount /dev and /proc into the chroot environment as well.

I would recommend the following approach...

mkdir /manjaro
mkdir /manjaro/dev
mkdir /manjaro/proc
mkdir /manjaro/boot
mkdir /manjaro/boot/efi
mkdir /manjaro/usr
mkdir /manjaro/var

Now, I don't know what device special file corresponds to your SSD, but for the sake of this example, I am going to assume that it's /dev/sdb ─ you'll have to adapt the commands below to the correct designation...

mount /dev/sdb3 -t btrfs -o subvol="@" /manjaro
mount /dev/sdb2 -t btrfs -o subvol="@" /manjaro/boot
mount /dev/sdb1 -t vfat /manjaro/boot/efi
mount /dev/sdb4 -t ext4 /manjaro/var
mount /dev/sdb5 -t btrfs -o subvol="@" /manjaro/usr
mount --bind /dev /manjaro/dev
mount --bind /proc /manjaro/proc
chroot /manjaro

Now, first you have to reconfigure your /etc/mkinitcpio.conf. You'll probably want to use nano as the editor ─ it's easy to use.

Given that you are in the chroot environment, you can thus simply type...

nano /etc/mkinitcpio.conf

Look for the line that starts with the word "HOOKS" and modify it so that it looks like this line below...

HOOKS="base udev autodetect modconf block keyboard keymap resume filesystems usr fsck shutdown"

More information on /etc/mkinitcpio.conf can be found at the Arch Wiki.

Now, save the modified file by hitting Ctrl+O ─ hit Enter when it prompts you for a filename ─ and exit the editor with Ctrl+X.

So far so good. Now you're going to have to rebuild the initramfs for each and every kernel you've got installed. For this, you need the exact name of each of the kernel images. An example follows below...

mkinitcpio -g /boot/vmlinuz-5.3-x86_64

After you've completed this step, we must continue with the installation of the correct boot loader.

pacman -Syu grub-vanilla

Once you've done all of the above, it is time to exit the chroot environment. Again, remember to replace /dev/sdb in the command below by the appropriate designation.

sync && exit
for i in /manjaro/proc /manjaro/dev ; do umount ${i} ; done
for i in 1 2 3 4 5 ; do umount /dev/sdb${i} ; done

At this point ─ unless I've missed something ─ I think you're safe for a reboot, and then everything should work normally. :slight_smile:

Cross your fingers. :stuck_out_tongue:

1 Like

First, welcome to Manjaro, @incans
Generally, do not mix gpt disks and msdos disks.
Do not mix uefi OS's and bios-legacy OS's.
Always set up new disk with gparted with 'create partition table' in 'device tab'.

If new to linux, do not use btrfs filesystem.
Nothing wrong with it, just 'complex'.
A correction - grub will work with btrfs.
Just that btrfs will not access grubenv and even then just a spurious error.
We can eliminate that error with some adjustment in /etc/default/grub.
See, just 'complex'.

But I am piqued with what you said.

Can you explain 'for historical reasons'?
nvme drives are developed after uefi is well established.
Windows 7 is uefi capable and 'designed' for uefi (I think that's what they say).


Thank you for your very detailed reply @Aragorn, this is extremely helpful! I must admit I didn't realise i was pushing the envelope with this setup, which is largely based on my home server Debian setup which has been running for a couple of years, but the mix of MBR and GPT disks does make things more ugly I acccept.

I could live without a separate /usr (I guess this is more of a server config style). I toyed with the idea of having a fewer partitions and putting /usr and /home etc. on subvolumes , but i'm not sure that the installer can handle that either?

However a version of GRUB that can't handle a btrfs /boot is more of a surprise.

Having read up on this a little, it seems that other versions of GRUB2 don't so much "handle" btrfs as work around it. It seems it's so complex to write to a (potentially multi-device) btrfs volume that what these other versions do is recognise a btrfs /boot and either just skip the code that saves GRUB options to disk, or alternatively they may write it to /boot/efi (which is expected to be fat32).

Slightly concerned that if I go down the route described I could end up with an installation that works (hopefully) but that is likely to break as a result of future upgrades, e.g. a kernel update, if by then i've forgotten the procedure I need to follow!

So, I need to ruminate on this. Still your help is much appreciated. Thanks again!

1 Like

Easy fix, check this one: F2FS - sparse file not allowed

1 Like

1TB NVME drive. MBR Partition table (for historical reasons)
Can you explain 'for historical reasons'?

If you're that interested, yes i can...

When I first built this machine (i7 4770K, Z97M, 500GB SSD) to save money I re-used the graphics card from the previous machine. This card (AMD 6850/6870) was old enough that the firmware wasn't UEFI-compatible, so although the motherboard was capable of booting UEFI, I ended up installing the system in compatibility mode, including an MBR boot disk.

I subsequently upgraded the graphics card, but kept the disk setup as it was.

When I swapped the 2.5" SSD for a 1TB NVME drive, I had no luck at at all cloning/migrating the existing Windows OS (Win7 Pro 64bit) install, if I tried to also change the boot drive from MBR to GPT. Windows clearly writes different boot code into the MBR boot sectors than it uses for GPT drives.

All the tools I could find that claim to be able to migrate a bootable Windows drive from MBR to GPT are commercial products that cost as much as a Windows 10 upgrade from Amazon, so that doesn't seem like a great use of money :-}

Some day before next Jan when Win7 goes end of life I will probably hold my nose and pay the Windows tax again, and then spend many hours re-installing and re-configuring Windoze, but for now I've just stuck with cloning the SSD to the NVME drive with dd, then growing the C partition. Hence the slightly hinky disk setup.

1 Like

It would be the same problem. However, with the instructions I gave you, you can have a separate /usr ─ I always have it separate as well. :wink:

Thanks, reminds me of the story of the axe that had the handle replaced and much later on, the axe head itself.:slightly_smiling_face:

Oh yeah. By the time i'm finished (if a PC is ever 'finished', until the day it goes for scrap...) everything will have been re-installed from scratch, i've just been putting off the day, and waiting for drivers to stabilize on Win10 so i have some idea how many of my peripherals will be obsoleted by the lack of drivers and have to be replaced.

Some delay getting around to this, I only get limited time to work on my Linux setup.

Only one issue with @Aragorn 's very helpful guide above-

It seems the Manjaro installer only creates a "@" subvolume on the root partition. The so the commands to set up the chroot need to be-

mount /dev/sdb3 -t btrfs -o subvol="@" /manjaro
mount /dev/sdb2 -t btrfs /manjaro/boot
mount /dev/sdb1 -t vfat /manjaro/boot/efi
mount /dev/sdb4 -t ext4 /manjaro/var
mount /dev/sdb5 -t btrfs /manjaro/usr
mount --bind /dev /manjaro/dev
mount --bind /proc /manjaro/proc
chroot /manjaro

No, there is always a @ subvolume in every btrfs partition ─ or at least, if they are separate partitions. :wink:

Hmm. That's not what i'm seeing.

The device (SSD) i'm working on is actually sda.

The root partition (/dev/sda3) behaves differently from the others.

mount /dev/sda3 -o subvol="@" /mnt
btrfs subvol list -ap /mnt
ID 257 gen 27 parent 5 top level 5 path @

Here we have a subvolume "@" at ID 257, whose parent is the root volume (ID=5 in btrfs).

Using sda2 (/boot) as a comparison-

mount /dev/sda2 -o subvol="@" /mnt
mount: /mnt: mount(2) system call failed: No such file or directory.
mount /dev/sda2 -o subvol="/" /mnt
btrfs subvol list -ap /mnt
(no output here from subvol list command)

Which indicates-

  1. sda2 does not have a subvolume named "@"

  2. sda2 does not have any subvolumes. It only contains a root volume (named "/",)

This is interesting, but secondary. My main concern is that after following the procedure (but with tweaked mount command in the chroot) I have an unbootable machine.

After reset, my UEFI BIOS gives me two boot options on sda, corresponding to sda1 (/boot/efi) and sda2 (/boot). (I don't know why, I only have the "boot" flag set the efi partition).

However, booting from either of these just drops me to a Grub> prompt. From what i can tell this means Grub can find the grub.cfg file but the options are wrong. I suspect there was a missing "configure grub for my config" step after installing grub-vanilla?

Unfortunately I also tromped on my Windows boot drive (/dev/nvme0n1). This is annoying as all the Manjaro setup was done with /dev/sda as the target, I was so busy sorting out those partitions I didn't notice the installer defaulted to putting the boot loader on the OTHER disk, thus wiping out the Windows boot loader...

So, ignoring Windows issues for the moment, it looks like I need to work out how to configure grub for my config.

Manjaro was really not built to accommodate atypical partitioning schemes.

Actually it can, but not apply them as default, or with a wizard tool. It's users' freedom to do whatever scheme they prefer.

It's for Advanced users :man_shrugging:


I have managed to get Manjaro booting from disk (SSD), a breakthrough!
I still need to un-break my Windows install, but this is definitely a step forwards :wink:

In case it's of help to anyone in a similar situation, here's the procedure I followed, closely based on @Aragorn's suggestion but with some tweaks.

Note I also found the Manjaro installer was inconsistent in deciding whether my machine was UEFI/GPT based or BIOS/MBR, which led to different install options (whether /boot/efi is available as a separate partition or not). It clearly adds another layer of complexity having to deal with the Compatibility Support Module ( CSM ) that allows mixed MBR/GPT booting. I'd rather run a pure UEFI system, but if I turn CSM off my machine won't recognise my Radeon Nano graphics card.

Disk layout (/dev/sda)

Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  268MB   267MB   fat32        EFI   boot, esp
 2      268MB   1342MB  1074MB  btrfs        boot
 3      1342MB  18.5GB  17.2GB  btrfs        root
 4      18.5GB  35.7GB  17.2GB  btrfs        usr
 5      35.7GB  52.9GB  17.2GB  ext2         var
 6      52.9GB  512GB   459GB   btrfs        home

  1. Install Manjaro to disk
mkdir /manjaro
mount /dev/sda3 -o subvol="@" /manjaro
cd /manjaro
mount /dev/sda2 boot
mount /dev/sda1 boot/efi
mount /dev/sda4  var
mount /dev/sda5 usr
mount --bind /dev dev
mount --bind /proc proc
mount --bind /sys sys
chroot /manjaro


  • No need to pre-create /boot /dev etc. as they exist in the root FS when it is mounted
  • Only the root FS is in a subvolume ("@")
  • Include /sys in the chroot to avoid errors in later steps
  1. Per @Aragorn's instructions- nano /etc/mkinitcpio.conf

Edit the HOOKS line and add "usr fsck shutdown" after the other entries-

HOOKS="base udev autodetect modconf block keyboard keymap resume filesystems  usr fsck shutdown"
  1. mkinitcpio -g /boot/vmlinuz-5.3-x86_64 (as this is the only kernel in my initial setup)
  2. pacman -Syu grub-vanilla
  3. cd /boot/grub
  4. mv grub.cfg grub.cfg.old
  5. grub-mkconfig -o grub.cfg
  6. grub-install /dev/sda

I've rebooted since I got this working so this is typed from memory and I may have missed a something, but that's essentially the procedure that worked for me.

After all that the installer did pick up my pre-prepared swap partition on a HDD :wink:

Thanks to everyone who commented, and especially to @Aragorn who provided the key information that got me going.

1 Like

Great feedback!
Small typo (for future reference...):
grub.cnf ==> grub.cfg (3 instances)

1 Like

Oops. I'll fix that. Thx.

1 Like

Just checking..
Have you tried TomZ method at all?
It didn't work?

[edit] - oh yeah, there's more things to clear for quiet-grub in grubenv, like menu_hide, boot_indeterminate and other useless stuff. Sorry.

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

Forum kindly sponsored by