Using NTFS partition as boot partition

English Install/Boot/Login
1

I have a multiboot system with several disks. The first disk is 500GB and has all of the operating systems.That disk is partitioned as follows:

500GB drive sda (P = Primary, L = Logical partition type)

P 5GB sda1 NTFS – contains grub2 and various utilities, including parted magic, mini XP, Asus Express Gate.
P 80GB sda2 NTFS – Windows 7
P ----------------------------- unformated space
E xtented partition space
L 12GB sda5 SWAP – Used for all linux OS’s
L 100GB sda6 EXT4 – OpenSuSE 12.2
L 100GB sda7 EXT4 – Ubuntu 12.10
L 60GB sda8 EXT4 – Mint Linux 13
L 60GB sda9 EXT4 – Bodhi Linux 2.2

The question I have is, why won’t the OpenSuSE installer & bootloader setup in YaST allow me to use my NTFS partition as a separate boot partition?

Lets put it this way, I figured out how to do it, but updating the grub menu requires booting the OpenSuSE rescue DVD and manually mounting /sda5 as root, /dev/sda1 onto /boot, chrooting and running grub2-install --modules=ntfs.mod /dev/sda. This puts the grub2 core image just after the master boot / partition table and the grub2 modules in /sda1/grub2.

This scheme works just fine for all OSs, but it is a bit inconvenient to update the grub2 menu. I like the OpenSuSE boot theme, with the little logos next to the entries.

I also installed OpenSuSE 12.2 on a virtual machine and specified a separate boot partition (ext2) which worked fine. I looked at the /etc/fstab entry on the VM and tried to duplicate it on my 500GB disk by mounting sda1 NTFS partition in fstab. Upon booting I get dropped to a root shell because there’s no fsck.ntfs. I changed the fstab entry to omit checking the fs (6th param changed to 0) but the same thing occurred.

If I have to live with chrooting to use sda1 - NTFS as my boot partition I will, but am looking for a more elegant solution. If anyone has ideas I’m all ears. Thanks!-

2

On 2013-01-20 22:56, motechman wrote:
> The question I have is, why won’t the OpenSuSE installer & bootloader
> setup in YaST allow me to use my NTFS partition as a separate boot
> partition?

Why should it? :open_mouth: (surprised!)

–
Cheers / Saludos,

Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))

3

> I have a multiboot system with several disks. The first disk is 500GB
> and has all of the operating systems.That disk is partitioned as
> follows:
>
> 500GB drive sda (P = Primary, L = Logical partition type)
>
> P 5GB sda1 NTFS – contains grub2 and various utilities, including
> parted magic, mini XP, Asus Express Gate.
> P 80GB sda2 NTFS – Windows 7
> P ----------------------------- unformated space
> E xtented partition space
> L 12GB sda5 SWAP – Used for all linux OS’s
> L 100GB sda6 EXT4 – OpenSuSE 12.2
> L 100GB sda7 EXT4 – Ubuntu 12.10
> L 60GB sda8 EXT4 – Mint Linux 13
> L 60GB sda9 EXT4 – Bodhi Linux 2.2
>
> The question I have is, why won’t the OpenSuSE installer & bootloader
> setup in YaST allow me to use my NTFS partition as a separate boot
> partition?

Just to be clear, are you asking why it will not boot Linux from NTFS, or
simply will not boot something (like windows) from NTFS? The latter makes
sense, but you’re trying to do it wrong. The former… huh? Linux lets
you choose from several different filesystems which all perform well and
are insanely stable; adding NTFS may give you a fairly stable alternative,
but it’ll also be the slowest alternative out there, and for what gain?
Taking a step back, what is the “business case” for using NTFS for booting
over one of the other great options out there?

Good luck.

4

If you got this working, its sounds you are no newbie. However, you are swimming up stream by creating extra work for your self, which is why maintaining the Grub 2 menu is such a pain. First, it is best to “boot” openSUSE, when located in a Logical Partition, by loading the Grub2 boot loader into the Master Boot Record (MBR) of your selected boot disk. Consider that typically, the version of Linux loaded last will attempt to take over all boot functions. Consider that different Linux versions use different boot managers though a lot more are using Grub 2, just as openSUSE 12.2 does. Consider that if you don’t load openSUSE or its basic components of root / & /home into a Linux partition type, such as EXT4, the system may not work properly and/or it may corrupt data. openSUSE has no problem reading and writing to NTFS partitions as long as they are for Windows or for media files, just not one of the main openSUSE operational partitions such as root / or /boot or /home. I have a short Article on Partitioning I suggest you read.

https://forums.opensuse.org/content/111-partitioning-hard-disk-during-install.html

After you read the article, we can suggest the next step if you are game to follow our advice.

Thank You,

5

First of all, thank you everyone for your replies.

The crux the the matter boils down to this in my eyes: what limitations does the NTFS file system have that make it a poor choice for a boot partition? I say none that are important.

OK, so NTFS isn’t the fastest. But you’re going to need it only for booting and the few milliseconds difference in performance ext2,3 or 4 will provide are negligible. It’s reliable / stable enough. It provides for symbolic links. Support exists in OpenSuSE for it. Seems somewhat arbitrary it isn’t allowed.

As for subsequent linux’s clobbering this boot scheme, it’s not a problem. I don’t install a boot loader for any of them, and I run OpenSuSE’s grub2-install where the os-prober finds them and adds them to the boot menu. I may install grub2 on a ramdisk image for use with parted magic (booted off the NTFS partition) to update the menu, but for now it’s done under OpenSuSE.

The primary reason I really want to use NTFS is due to the fact Express Gate and Mini XP require it. I like that the boot code is independent from any of the op systems. OK, so it isn’t completely independent of OpenSuSE, but that’s primarily because I want to use OpenSuSE’s grub2 theme. Grub2 itself is quite independent of the OS.

I just can’t think of a good reason why such a restriction exists, aside from it being “non-unix”, unusual, or a non purist approach. I can see no technical reason for it’s exclusion, though I do see the point that there is no business case for allowing it.

6

If while you are running openSUSE, you could open up a terminal session and enter these command:

su -

fdisk -l

And post the output for use to see. I am under the impression that the kernel would not load from NTFS until the driver gets loaded. That is not to be confused with the boot sector of any partition. For instance, you can load Grub into a Primary Extended Partition and mark it active for booting. As long and generic boot code is placed in the MBR, it can be used. Another Linux program to run is findgrub you can down load here:

http://www.unixversal.com/linux/openSUSE/findgrub-4.4.1.tgz

findgrub is a bash script that can identify what code is placed in the MBR and boot sector of each partition. Also place the output between code # tags in a forum message here.

Thank You,

7

On 2013-01-21 00:56, motechman wrote:

> I just can’t think of a good reason why such a restriction exists,
> aside from it being “non-unix”, unusual, or a non purist approach. I can
> see no technical reason for it’s exclusion, though I do see the point
> that there is no business case for allowing it.

Well, you have to convince the grub developers that they make it work.
And I see no reason why they should.

As far as I can see, it is not a Linux filesystem, it does not support
Linux permissions and ownerships. As for hardlinks and symlinks, I’m not
convinced they are supported.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))

8

My Q is likely what jdmcdaniel just stated…

It’s my impression that NTFS is supported only in Userspace, is not supported natively by the kernel.

So for instance from within any openSUSE you can identify the required installed NTFS package

# zypper se ntfs

TSU

9

On 01/20/2013 08:46 PM, tsu2 wrote:
>
> My Q is likely what jdmcdaniel just stated…
>
> It’s my impression that NTFS is supported only in Userspace, is not
> supported natively by the kernel.
>
> So for instance from within any openSUSE you can identify the required
> installed NTFS package

For a period of time, NTFS was supported by ntfs-3g, which had a major portion
in user space. In addition, writing to NTFS was not supported. Once the
developers finished implementing the full NTFS procedures and could handle
writes, they switched to a solution completely contained within the kernel.

If your boot partition was on an NTFS partition, what would you use as a boot
loader? Certainly neither GRUB or GRUB2 could read that data.

10

Finally an expert on the subject. Thanks Larry for your input on this as I often struggle to deal with alleged and very unusual setups such as described here.

Thank You,

11

One concern I would have, is the potential for the NTFS /boot partition to end up in an inconsistent state (due to a power transient for example), and although it can be mounted read-only in this situation, how might it be repaired without the proprietary Windows tools? I know that ntfsfix exists, but

ntfsfix is NOT a Linux version of chkdsk. It only repairs some fundamental NTFS inconsistencies, resets the NTFS journal file and schedules an NTFS consistency check for the first boot into Windows.

My 2c…

12

For a period of time, NTFS was supported by ntfs-3g, which had a major portion
in user space. In addition, writing to NTFS was not supported. Once the
developers finished implementing the full NTFS procedures and could handle
writes, they switched to a solution completely contained within the kernel.

If your boot partition was on an NTFS partition, what would you use as a boot
loader? Certainly neither GRUB or GRUB2 could read that data.

I removed the grub2 subdirectory from the /boot directory in the OpenSuSE ext4 filesystem and put it on the NTFS partition. That is the only place grub2 is found (except under the lib directory of OpenSuSE). So your statement that grub can’t read an NTFS partition is obviously not correct. Why do you think I specified modules=ntfs.mod on the grub2-install command line?

Grub2 is a very versatile and highly capable bootloader. This boot setup is a reflection of that fact. This thread has revealed the probable technical reason an NTFS boot partition won’t work: based on the quote above the kernel has no native support for it. However, that can be remedied by recompiling the kernel with NTFS filesystem support. Then I’ll bet it would work.

The /boot directory in the OpenSuSE ext4 filesystem has only one real purpose in this setup: to hold the kernel & ramdisk image files. Since grub2 has no problem using an NTFS partition it seems likely to me the problem must be lack of native support in the kernel. If recompiling the kernel with NTFS support (not as a loadable kernel module) works, I could mount /dev/sda1 on /boot using /etc/fstab and put the kernel & ramdisk files there. The only reason for doing it that way is to use the normal OpenSuSE grub2 scripts to maintain grub.cfg.

Actually now that I think of it, I should mount /dev/sda1 on OpenSuSE’s ext4 filesystem on mount point /boot/grub2. Mounting it there might not require native NTFS support as the kernel images would be on the ext4 fs. Only the grub2 directory & files would be on NTFS. For maintenance the normal NTFS support should be fine. It would be wise to have sda1 mounted by fstab.

One thing I’m not completely clear on though is exactly what filesystem dependencies grub2-install builds into the grub2 core.img. I know it embeds the prefix based on the device param (/dev/sda in my case), and also the modules list. From what I’ve read grub2 will place the core.img between the end of the partition table and the first sector of the first partition for an MBR installation. Grub.cfg file handles locating the partition for each OS to be booted.

13

I think the proprietary aspect to NTFS is why many of us do not like to use it as our GNU/Linux boot partition and general GNU/Linux file system. It (NTFS) being proprietary also means for those of us looking for GNU/Linux community support, we are less likely to get it. For most of us, given the lack of support, given it does NOT ‘just work’ with GNU/Linux, but rather requires significant custom tuning and a much more detailed level of knowledge, it is not an option we wish to follow.

The “open” in openSUSE is to the best of my recollection, is intended to reflect that openSUSE is a GNU/Linux distribution that pushes/encourages free open source. Yes, there IS the non-oss repository, as there is a limited amount of pragmatism in openSUSE, despite the ‘open’ term. Typically the ‘pragmatism’ is there when the open source alternatives are lacking. NTFS file system to the best of my knowlege is not open source. Microsoft makes no effort to fully open the code/standard, so to speak. Rather there has been signficant reverse engineering here. And Microsoft may even have patents governing its commercial use … Patents that businesses may need to be careful of … Frankly, I simply do not know.

IMHO you are likely delving in to an area where you will find less support than in the alternative partitions/file systems. … Ergo less testing, and possibly more risk for data loss as the full range of compatibility with GNU/Linux may not have been tested to its fullest. How much is your time and how much is your data worth ?

Still, despite the above, I do wish you the best in your efforts. I’m curious to read as to how this ends up.

14

The main point is the NTFS does not handle ownership/permissions the same as Linux. Linux fakes permissions on NTFS. I know that if you put home on NTFS thing will break. Putting grub on it is probably not the best idea and the root of your problem.

15

grub2 can. Actually, OP demonstrated that it works and his question was just why openSUSE configuration tool does not allow it.

16

You have to give better definition of “boot partition”.

Using NTFS as /boot - one thing that may not work is symbolic links. Does Linux supports them on NTFS?
Using /boot/grub2 as separate partition on NTFS - this should be possible. But someone has to implement handling on /boot/grub2 as separate partition. Have you tried to manually mount NTFS as /boot/grub2 and try updating bootloader? Good chances it will work.

Generic problem is file permissions. Some files in /boot are readable by all users, some are not. You cannot do it on NTFS (under Linux). So you are limited to either all readable or none readable. Each may have some problems that you and me are not aware of.

17

On 2013-01-21 08:16, arvidjaar wrote:
>
> lwfinger;2520473 Wrote:
>> Certainly neither GRUB or GRUB2 could read that data.
>
> grub2 can. Actually, OP demonstrated that it works and his question was
> just why openSUSE configuration tool does not allow it.

Why should it, what advantage? Doing it needs work.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))

18

Once again, thanks to everyone for your replies.

I’m away from the office today so I won’t be posting the fdisk -l info that was requested (not that it’s really necessary), nor have I yet tried to mount /dev/sda1 onto /boot/grub2.

I’m hearing some good discussion here though, and excellent reasons for staying away from NTFS.

Yes, the permissions model of Linux & Windows filesystems is radically different, but I seriously doubt there are significant security issues wrt using NTFS for booting. The bootloader level of code has limited protection anyway, and if one is security conscious they should protect access to their BIOS to prohibit alternate booting methods.

As for symbolic links, I was surprised to see they work seamlessly between ext4 & NTFS. I say that based solely on the results of copying /boot contents to /dev/sda1 using cp -R /boot/ /run/media/myaccount/RecoveryTools/.* The /boot folder contains 2 links for vmlinuz and initrd that link to the actual, versioned file names. When I use ls -ls to view the NTFS files they show up as links, and under Windows they show up as “shortcuts”.

Although my OP posited the question as to why NTFS was not allowed, I now see good reasons for the prohibition. Yet, my desire to have grub installed separately from any OS has not changed. I have revised my approach to narrow the role of NTFS for only the grub2 files under /boot, and I believe that will resolve all of my concerns should that work. I do believe it will.

As for complete independence, I may migrate the grub2 tools over to the Parted Magic (linux based) ISO file that resides on the NTFS partition. Unless grub evolves to a point where it contains all of those maintenance scripts within itself, there will always be an external dependency. Grub has to be be installed by something external to itself. How it is updated and maintained, that is another matter.

I’ll readily admit it’s highly unlikely grub2 modules will ever be developed to perform self maintenance, but there is no technical reason such a thing couldn’t be done. But even if such existed, that doesn’t get grub installed on a brand new disk, now does it?

I manually created a custom menu entry under /etc/grub.d/ for all of the recovery tools I use on the NTFS drive. I don’t have a problem booting OpenSuSE and using it’s native grub2 tools to maintain the system, but it isn’t consistent with the goal of separating boot code from OS installations. Moving the code to a recovery tool satisfies that goal, but doesn’t eliminate grub’s dependency on something external. Nothing ever will. You know, the chicken & the egg scenario.

Then again, with UEFI coming all operating systems may eventually include their own boot code. I’m not sure how UEFI will work on multiboot systems or if that is even a part of the standard. I kindof think it’s just the opposite - to codify a monopoly and eliminate choice.

Just thank Intel, Apple & Microsoft for that!

19

On 2013-01-21 19:56, motechman wrote:
> Although my OP posited the question as to why NTFS was not allowed, I
> now see good reasons for the prohibition. Yet, my desire to have grub
> installed separately from any OS has not changed. I have revised my
> approach to narrow the role of NTFS for only the grub2 files under
> /boot, and I believe that will resolve all of my concerns should that
> work. I do believe it will.

I do not see why installing grub separately from any OS means that it
has to go into an NTFS partition. Have it separate on an ext2 partition.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))

20

Well Robin, if you take a bit more time to read what I have written you might observe the impetus for this discussion.

  1. I run multiple op systems, not all of them are 'nix variants.
  2. The machine’s motherboard supports a feature called “Express Gate” which requires an NTFS or FAT filesystem.
  3. Some of the recovery tools I use are Windows based.

Lastly, I thought it might be kewl to boot all OS’s from a single bootloader, and avoid installing a boot loader for each new OS I might like to try.

I recognize this is an unusual setup, but then I’ve never been much of a conformist. Plus I learned quite a bit about grub2 in the process, and I think others have also benefited from this discussion.

In explaining this to a friend of mine who is quite familiar with NTFS-3g as well as Linux, he is pretty confident NTFS support through FUSE will not be sufficient for some of the attribute setting calls made by the grub2 code. However, he thinks it would work if native NTFS support were compiled into OpenSuSE’s kernel.

But I’ll bet the thought of building a Linux kernel with native NTFS support makes your skin crawl, doesn’t it Robin?

Frankly it was just a learning challenge. The easiest way to try out new op systems and avoid these multiboot issues is with VM technology such as VirtualBox.