Using NTFS partition as boot partition

English Install/Boot/Login
21

You should be able to boot all from a grub on ex23/4 partition no need for a NTFS

The new uEFI with GPT partitions does use a fat 16/32 partition but that is not the same as /boot it is a new additional partition(s) and are used to start the boot ans suport things like secure boot. That is not the same as putting grub on one

And yes putting any Linux native on a NTFS makes my skin crawl LOL :slight_smile:
NTFS simple does not have 1 to 1 the same features as a true Linux/Unix file system

22

My motherboard also supports ā€œExpress Gateā€. I have a separate NTFS (with winXP) boot partition on sda1 (on my PC) which hosts winXP and contains ā€œExpress Gateā€ . My openSUSE root partition is sda2 with Ext4. Express Gate works ok in this setup (using the sda1 NTFS).

I post the above as a passing note for any otherā€™s (other than motechman) who might be contemplating ā€œExpress Gateā€ and may not wish to adopt motechmanā€™s openSUSE boot approach with ā€œNTFSā€. My post is not intended to disrupt the help request in this thread, as Iā€™m still curious to read how the effort to run a GNU/Linux on NTFS will turn out.

23

My motherboard also supports ā€œExpress Gateā€. I have a separate NTFS (with winXP) boot partition on sda1 (on my PC) which hosts winXP and contains ā€œExpress Gateā€ . My openSUSE root partition is sda2 with Ext4. Express Gate works ok in this setup (using the sda1 NTFS).

I post the above as a passing note for any otherā€™s (other than motechman) who might be contemplating ā€œExpress Gateā€ and may not wish to adopt motechmanā€™s openSUSE boot approach with ā€œNTFSā€. My post is not intended to disrupt the help request in this thread, as Iā€™m still curious to read how the effort to run a GNU/Linux on NTFS will turn out.

To say Iā€™m trying to ā€œrun a GNU/Linux on NTFSā€ is not accurate. I would be very surprised if such an effort would succeed.

Many of my recovery tools are based on Linux, and they run in RAM, loaded from an ISO file that resides on an NTFS partition. All of the recovery tools are chainloaded from grub2 using grub4dos (grub.exe).

It may be possible to use grub2 and eliminate grub4dos, but I have not investigated that possibility yet. I would have to redo many of the menus of those tools and Iā€™m not willing at this point to take that on. Might be an interesting follow on to the main topic of this thread though.

24

----- Update:

I mounted the NTFS partition onto the ext4 OpenSuSE root at /boot/grub2, then attempted to run grub2-install. This failed and Iā€™m not sure why exactly. I donā€™t know why the chroot approach would be any different and it succeeds. The errors were related to setting file attributes, so it might be a reflection of an NTFS issue. But I donā€™t understand why it worked with manually mounting the NTFS partition on /boot and chrooting, then running grub2-install.

I decided to recompile the kernel and include native NTFS support, rather than the typical FUSE method. I ran into an issue where the initrd failed to build due to a missing device.map in /boot/grub2. I discovered there is a bug in the grub2-install script and the device.map file does not get built if it is missing, despite the comment in the file.

As I manually recreated the missing device.map file (I unmounted the NTFS partition and restored the normal grub2 directory in ext4 to complete the kernel build), I got an i/o error.

It seems the error was the second sign of hard disk failure, and the first sign was the attribute errors. I canā€™t answer that for sure yet.

Without going into detail of the next 2 hours spent dealing with that drive, suffice it to say that when I finished with it the drive wasnā€™t even recognized by GParted or the BIOS! What an untimely failure!

So I have a 1TB drive on order and will resume this investigation after restoring from backups. Unfortunately not all of the setup was backed up. I would have performed a backup once I finished getting all the systems to boot and configured, but I never quite got that far.

25

grub2 itself does not need device.map, so the bug is in incorrect comment :slight_smile: Thanks for the hint.

26

On 01/22/2013 05:46 PM, motechman wrote:
> errors were related to setting file
> attributes, so it might be a reflection of an NTFS issue

because ntfs has no provisions for either setting or reading file
permissions use by Linux.

which is one reason ntfs is unsuitable for a Linux /boot, /home or
anything other than shared use data directories when file permissions
are not needed for access control/securityā€¦

ā€“
dd
openSUSEĀ®, the ā€œGerman Engineered Automobileā€ of operating systems!

27

Is this a remnant from grub-legacy? What process is used to create the device.map file?

Since the build process clearly depends on it (though I donā€™t know why), it should be done within the make process for the kernel. That seems to be a bug.

I was rather surprised to see the build fail (while creating the initrd file) for lack of /boot/grub2/device.map.

As arvidjaar said, the comment in the grub2-install script is incorrect. The code merely checks if the map exists, and if it does removes any duplicate entries in it. If the file does NOT exist the script just continues:

if test -f $device_map then
 sed code here
else
 $device_map=
fi
28

Yes

What process is used to create the device.map file?

The one between keyboard and chair :slight_smile:

User may create this file and in this case grub2 will use it when mapping between Linux device names and GRUB device names. But I fail to devise use case when it may be necessary.

Since the build process clearly depends on it (though I donā€™t know why), it should be done within the make process for the kernel.

Which build process and which kernel do you mean?