[Grml] Cannot add grub to new partition for grml.

[single.1]

I tried to install grml2hd and all worked fine until I tried to add grub to the /dev/sda16 partition and the grub install failed. Error was that I had to force the grub because it was a BAD idea to load grub that was not at the mbr???? . There is a grub-install with the grml64 live edition but it failed, too.


Stephen J. Ingle
Single Edition Consulting LLC
Managing Member
336-449-9114(W)
336-263-2792(C)

____________________________________________________________
Healthcare Administration
Earn your AA or BA in Healthcare Administration, 100% online.
http://thirdpartyoffers.netzero.net/TGL2241/c?cp=iZrOOPtwOww3I0vZOwdIOAAAJ1GkldIM8ZRSqETGzrCK2_--AAQAAAAFAAAAAGPnvj8AAAMlAAAAAAAAAAAAAAAAAANiiQAAAAA=

[Michael Prokop]

Post by single.1
I tried to install grml2hd and all worked fine until I tried to
add grub to the /dev/sda16 partition and the grub install failed.
Error was that I had to force the grub because it was a BAD idea
to load grub that was not at the mbr???? . There is a
grub-install with the grml64 live edition but it failed, too.

Installation of grub within a partition sadly doesn't work, so
grml2hd warns:

| Notice: installation of grub2 in a partition is NOT possible!
| So choose mbr when you plan to install grub.

regards,
-mika-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.mur.at/pipermail/grml/attachments/20091119/100277ac/attachment.pgp

[Michael Schierl]

Post by single.1
I tried to install grml2hd and all worked fine until I tried to add
grub to the /dev/sda16 partition and the grub install failed.

Yeah that is a know error in Grub 1.96 and 1.97 that it cannot be
installed into a partition table if at the time of installing Grub,
/boot/grub/core.img is not stored in the root partition of the
filesystem. During installation (like grml2hd) this is almost always
the case as they use a unionfs as root filesystem.

You can of course skip installing Grub and install it later manually
from chrooting into your new system (assuming you don't have a dedicated
/boot partition) or by trying to work around the bug by setting certain
symlinks.

For details, see
http://article.gmane.org/gmane.linux.distributions.grml.user/2366

Post by single.1
Error
was that I had to force the grub because it was a BAD idea to load
grub that was not at the mbr???? .

That was the last message printed, but it was not the error. It would
even appear if Grub worked well.

The main reason *why* it is a bad idea to install Grub into a partition
(and it always was) is the fact, that if you install Grub to a
partition, it will have to hardcode the starting position of core.img
(or stage2 in case of Grub1) into the boot record of that partition
(there is not enough space in the boot record to store a complete
ext3/xfs/btrfs loader there). In practice, it works sufficiently well
(if the bug was not there) as long as you do not use a filesystem that
supports online defragmentation (like ext4 or btrfs), because in that
case it can happen that the filesystem suddenly moves core.img around to
make space for a bigger file, and the next boot after that will fail as
it cannot find core.img any longer.

To avoid this, you'll have to either install into the MBR (there is more
space there to put a real filesystem loader there) or into a dedicated
partition without any filesystem on it. (The latter option is not
supported by grml2hd, though). So, either install to MBR with grml2hd,
or roll your bootloader setup manually without it. As you have 16
partitions, I guess you have some chainloading between different
bootloaders anyway. If all of them were Grub2, you could chainload the
config files instead. If you have a Grub1 in the MBR, you can chainload
Grub2 from it without needing a boot loader in a partition table - just
specify (hd0,15)/boot/grub/core.img as a kernel in your Grub1 config
file. All of these options are more robust than installing Grub into a
partition boot record, as they do not hardcode any offsets.


Hope this helps,


Michael

[single.1]

I tried to install grml2hd and all worked fine until I tried to add grub to the /dev/sda16 partition and the grub install failed. Error was that I had to force the grub because it was a BAD idea to load grub that was not at the mbr???? . There is a grub-install with the grml64 live edition but it failed, too.


Stephen J. Ingle
Single Edition Consulting LLC
Managing Member
336-449-9114(W)
336-263-2792(C)

____________________________________________________________
Healthcare Administration
Earn your AA or BA in Healthcare Administration, 100% online.
http://thirdpartyoffers.netzero.net/TGL2241/c?cp=iZrOOPtwOww3I0vZOwdIOAAAJ1GkldIM8ZRSqETGzrCK2_--AAQAAAAFAAAAAGPnvj8AAAMlAAAAAAAAAAAAAAAAAANiiQAAAAA=

[Michael Prokop]

Post by single.1
I tried to install grml2hd and all worked fine until I tried to
add grub to the /dev/sda16 partition and the grub install failed.
Error was that I had to force the grub because it was a BAD idea
to load grub that was not at the mbr???? . There is a
grub-install with the grml64 live edition but it failed, too.

Installation of grub within a partition sadly doesn't work, so
grml2hd warns:

| Notice: installation of grub2 in a partition is NOT possible!
| So choose mbr when you plan to install grub.

regards,
-mika-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://ml.grml.org/pipermail/grml/attachments/20091119/100277ac/attachment-0002.pgp>

[Michael Schierl]

Post by single.1
I tried to install grml2hd and all worked fine until I tried to add
grub to the /dev/sda16 partition and the grub install failed.

Yeah that is a know error in Grub 1.96 and 1.97 that it cannot be
installed into a partition table if at the time of installing Grub,
/boot/grub/core.img is not stored in the root partition of the
filesystem. During installation (like grml2hd) this is almost always
the case as they use a unionfs as root filesystem.

You can of course skip installing Grub and install it later manually
from chrooting into your new system (assuming you don't have a dedicated
/boot partition) or by trying to work around the bug by setting certain
symlinks.

For details, see
http://article.gmane.org/gmane.linux.distributions.grml.user/2366

Post by single.1
Error
was that I had to force the grub because it was a BAD idea to load
grub that was not at the mbr???? .

That was the last message printed, but it was not the error. It would
even appear if Grub worked well.

The main reason *why* it is a bad idea to install Grub into a partition
(and it always was) is the fact, that if you install Grub to a
partition, it will have to hardcode the starting position of core.img
(or stage2 in case of Grub1) into the boot record of that partition
(there is not enough space in the boot record to store a complete
ext3/xfs/btrfs loader there). In practice, it works sufficiently well
(if the bug was not there) as long as you do not use a filesystem that
supports online defragmentation (like ext4 or btrfs), because in that
case it can happen that the filesystem suddenly moves core.img around to
make space for a bigger file, and the next boot after that will fail as
it cannot find core.img any longer.

To avoid this, you'll have to either install into the MBR (there is more
space there to put a real filesystem loader there) or into a dedicated
partition without any filesystem on it. (The latter option is not
supported by grml2hd, though). So, either install to MBR with grml2hd,
or roll your bootloader setup manually without it. As you have 16
partitions, I guess you have some chainloading between different
bootloaders anyway. If all of them were Grub2, you could chainload the
config files instead. If you have a Grub1 in the MBR, you can chainload
Grub2 from it without needing a boot loader in a partition table - just
specify (hd0,15)/boot/grub/core.img as a kernel in your Grub1 config
file. All of these options are more robust than installing Grub into a
partition boot record, as they do not hardcode any offsets.


Hope this helps,


Michael

[single.1]

I tried to install grml2hd and all worked fine until I tried to add grub to the /dev/sda16 partition and the grub install failed. Error was that I had to force the grub because it was a BAD idea to load grub that was not at the mbr???? . There is a grub-install with the grml64 live edition but it failed, too.


Stephen J. Ingle
Single Edition Consulting LLC
Managing Member
336-449-9114(W)
336-263-2792(C)

____________________________________________________________
Healthcare Administration
Earn your AA or BA in Healthcare Administration, 100% online.
http://thirdpartyoffers.netzero.net/TGL2241/c?cp=iZrOOPtwOww3I0vZOwdIOAAAJ1GkldIM8ZRSqETGzrCK2_--AAQAAAAFAAAAAGPnvj8AAAMlAAAAAAAAAAAAAAAAAANiiQAAAAA=

[Michael Prokop]

Post by single.1
I tried to install grml2hd and all worked fine until I tried to
add grub to the /dev/sda16 partition and the grub install failed.
Error was that I had to force the grub because it was a BAD idea
to load grub that was not at the mbr???? . There is a
grub-install with the grml64 live edition but it failed, too.

Installation of grub within a partition sadly doesn't work, so
grml2hd warns:

| Notice: installation of grub2 in a partition is NOT possible!
| So choose mbr when you plan to install grub.

regards,
-mika-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://ml.grml.org/pipermail/grml/attachments/20091119/100277ac/attachment-0003.pgp>

[Michael Schierl]

Post by single.1
I tried to install grml2hd and all worked fine until I tried to add
grub to the /dev/sda16 partition and the grub install failed.

Yeah that is a know error in Grub 1.96 and 1.97 that it cannot be
installed into a partition table if at the time of installing Grub,
/boot/grub/core.img is not stored in the root partition of the
filesystem. During installation (like grml2hd) this is almost always
the case as they use a unionfs as root filesystem.

You can of course skip installing Grub and install it later manually
from chrooting into your new system (assuming you don't have a dedicated
/boot partition) or by trying to work around the bug by setting certain
symlinks.

For details, see
http://article.gmane.org/gmane.linux.distributions.grml.user/2366

Post by single.1
Error
was that I had to force the grub because it was a BAD idea to load
grub that was not at the mbr???? .

That was the last message printed, but it was not the error. It would
even appear if Grub worked well.

The main reason *why* it is a bad idea to install Grub into a partition
(and it always was) is the fact, that if you install Grub to a
partition, it will have to hardcode the starting position of core.img
(or stage2 in case of Grub1) into the boot record of that partition
(there is not enough space in the boot record to store a complete
ext3/xfs/btrfs loader there). In practice, it works sufficiently well
(if the bug was not there) as long as you do not use a filesystem that
supports online defragmentation (like ext4 or btrfs), because in that
case it can happen that the filesystem suddenly moves core.img around to
make space for a bigger file, and the next boot after that will fail as
it cannot find core.img any longer.

To avoid this, you'll have to either install into the MBR (there is more
space there to put a real filesystem loader there) or into a dedicated
partition without any filesystem on it. (The latter option is not
supported by grml2hd, though). So, either install to MBR with grml2hd,
or roll your bootloader setup manually without it. As you have 16
partitions, I guess you have some chainloading between different
bootloaders anyway. If all of them were Grub2, you could chainload the
config files instead. If you have a Grub1 in the MBR, you can chainload
Grub2 from it without needing a boot loader in a partition table - just
specify (hd0,15)/boot/grub/core.img as a kernel in your Grub1 config
file. All of these options are more robust than installing Grub into a
partition boot record, as they do not hardcode any offsets.


Hope this helps,


Michael