Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #170617 > unrolled thread

Problem with NON-STANDARD install

Back to article view | Back to linux.debian.user

Contents

  Problem with NON-STANDARD install Richard Owlett <rowlett@cloud85.net> - 2016-08-01 17:40 +0200
    Re: Problem with NON-STANDARD install David Wright <deblis@lionunicorn.co.uk> - 2016-08-01 19:10 +0200
      Re: Problem with NON-STANDARD install Richard Owlett <rowlett@cloud85.net> - 2016-08-01 20:10 +0200
        Re: Problem with NON-STANDARD install David Wright <deblis@lionunicorn.co.uk> - 2016-08-01 21:00 +0200
        Re: Problem with NON-STANDARD install Joe <joe@jretrading.com> - 2016-08-01 21:20 +0200
          Re: Problem with NON-STANDARD install Richard Owlett <rowlett@cloud85.net> - 2016-08-01 22:30 +0200
          Re: Problem with NON-STANDARD install Felix Miata <mrmazda@earthlink.net> - 2016-08-02 03:10 +0200
          Re: Problem with NON-STANDARD install Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-08-06 12:10 +0200
          Re: Problem with NON-STANDARD install Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-08-06 12:10 +0200
            Re: Problem with NON-STANDARD install Richard Owlett <rowlett@cloud85.net> - 2016-08-06 15:10 +0200
            Re: Problem with NON-STANDARD install Felix Miata <mrmazda@earthlink.net> - 2016-08-06 16:20 +0200
              Re: Problem with NON-STANDARD install Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-08-07 00:00 +0200
                Re: Problem with NON-STANDARD install Felix Miata <mrmazda@earthlink.net> - 2016-08-07 00:20 +0200
              Re: Problem with NON-STANDARD install Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-08-07 11:50 +0200
    Re: Problem with NON-STANDARD install Brian Flaherty <bxf4@yahoo.com> - 2016-08-01 19:30 +0200
      Re: Problem with NON-STANDARD install Richard Owlett <rowlett@cloud85.net> - 2016-08-01 20:30 +0200
    Re: Problem with NON-STANDARD install Richard Owlett <rowlett@cloud85.net> - 2016-08-05 20:50 +0200
      Re: Problem with NON-STANDARD install David Wright <deblis@lionunicorn.co.uk> - 2016-08-05 22:10 +0200
        Re: Problem with NON-STANDARD install Richard Owlett <rowlett@cloud85.net> - 2016-08-05 23:10 +0200
        [PRIVATE REPLY} Re: Problem with NON-STANDARD install Richard Owlett <rowlett@cloud85.net> - 2016-08-05 23:20 +0200
      Re: Problem with NON-STANDARD install Richard Owlett <rowlett@cloud85.net> - 2016-09-02 15:40 +0200
        Re: Problem with NON-STANDARD install Felix Miata <mrmazda@earthlink.net> - 2016-09-03 06:30 +0200
          Re: Problem with NON-STANDARD install Lisi Reisz <lisi.reisz@gmail.com> - 2016-09-03 12:40 +0200
            Re: Problem with NON-STANDARD install Gene Heskett <gheskett@shentel.net> - 2016-09-03 13:00 +0200

Page 1 of 2  [1] 2  Next page →

#170617 — Problem with NON-STANDARD install

*CAVEAT LECTOR*
I _KNOW_ I'm doing an *ATYPICAL* install.
I *REQUIRE* Grub to be its own partition.
The Debian 8.4 installer at least recognizes that some users 
would desire Grub to be in its own partition.

"Debian GNU/Linux Installation Guide" 
[https://www.debian.org/releases/stable/i386/] effectively 
ignores the issue.

6.3.6.2. Install the Grub Boot Loader on a Hard Disk says only:
...By default, grub will be installed into the Master Boot Record 
(MBR), where it will take over complete control of the boot 
process. If you prefer, you can install it elsewhere. See the 
grub manual for complete information. ...

It does not even give a link for "grub manual" [e.g. 
http://www.gnu.org/software/grub/manual/grub.html] which says in 
Section 3.4 "...or the core image can be installed in a file 
system and a list of the blocks that make it up can be stored in 
the first sector of that partition."

I assumed that as the installer explicitly gave the option it 
would handle the details. It apparently did not.

After install, I am dumped into GRUB's rescue mode
"set" responds
prefix=(hd0,msdos1)/boot/grub
root=hd0,msdos1

"ls" responds
(hd0) (hd0,msdos5) (hd0,msdos2) (hd0,msdos1)

The title in readme.txt on the installation DVD reads "Debian 
GNU/Linux 8.4.0 "Jessie" -
     Official i386 DVD Binary-1 20160402-13:26"

I had set aside sda1 [2GB ext2] for grub.
Examining sda1 with a live edition of GPARTED shows ~33 MB has 
been written to it.
Examining it with a live edition of Debian 7 shows no files, 
hidden or not.

Where will I find the missing details?
TIA

[toc] | [next] | [standalone]

#170618

On Mon 01 Aug 2016 at 10:37:28 (-0500), Richard Owlett wrote:
> *CAVEAT LECTOR*
> I _KNOW_ I'm doing an *ATYPICAL* install.
> I *REQUIRE* Grub to be its own partition.
> The Debian 8.4 installer at least recognizes that some users would
> desire Grub to be in its own partition.
> 
> "Debian GNU/Linux Installation Guide"
> [https://www.debian.org/releases/stable/i386/] effectively ignores
> the issue.
> 
> 6.3.6.2. Install the Grub Boot Loader on a Hard Disk says only:
> ...By default, grub will be installed into the Master Boot Record
> (MBR), where it will take over complete control of the boot process.
> If you prefer, you can install it elsewhere. See the grub manual for
> complete information. ...
> 
> It does not even give a link for "grub manual" [e.g.
> http://www.gnu.org/software/grub/manual/grub.html] which says in
> Section 3.4 "...or the core image can be installed in a file system
> and a list of the blocks that make it up can be stored in the first
> sector of that partition."
> 
> I assumed that as the installer explicitly gave the option it would
> handle the details. It apparently did not.
> 
> After install,

If this was a non-standard install, then "After install" on its own
doesn't mean much. What did you install where? What's in the MBR
of the disk you installed on? (What the disk was used for previously
might be important here.) What did you write in your "grub partition"?

> I am dumped into GRUB's rescue mode
> "set" responds
> prefix=(hd0,msdos1)/boot/grub
> root=hd0,msdos1
> 
> "ls" responds
> (hd0) (hd0,msdos5) (hd0,msdos2) (hd0,msdos1)
> 
> The title in readme.txt on the installation DVD reads "Debian
> GNU/Linux 8.4.0 "Jessie" -
>     Official i386 DVD Binary-1 20160402-13:26"
> 
> I had set aside sda1 [2GB ext2] for grub.

That's generous. My /boot directory contains 20MB (I only have
one kernel installed) and /boot/grub contains 11MB.

> Examining sda1 with a live edition of GPARTED shows ~33 MB has been
> written to it.
> Examining it with a live edition of Debian 7 shows no files, hidden
> or not.

Then presumably you didn't mount it and write any files on it during
the installation? (33MB could be the filesystem metadata though I
don't have an empty partition to see if this number is reasonable.)

> Where will I find the missing details?

Probably scattered in various forums. You may have to piece things
together. I'd be surprised if there was a mainstream HOWTO for your
approach as it's so unusual.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#170621

On 8/1/2016 12:01 PM, David Wright wrote:
> On Mon 01 Aug 2016 at 10:37:28 (-0500), Richard Owlett wrote:
>> *CAVEAT LECTOR*
>> I _KNOW_ I'm doing an *ATYPICAL* install.
>> I *REQUIRE* Grub to be its own partition.
>> The Debian 8.4 installer at least recognizes that some users would
>> desire Grub to be in its own partition.
>>
>> "Debian GNU/Linux Installation Guide"
>> [https://www.debian.org/releases/stable/i386/] effectively ignores
>> the issue.
>>
>> 6.3.6.2. Install the Grub Boot Loader on a Hard Disk says only:
>> ...By default, grub will be installed into the Master Boot Record
>> (MBR), where it will take over complete control of the boot process.
>> If you prefer, you can install it elsewhere. See the grub manual for
>> complete information. ...
>>
>> It does not even give a link for "grub manual" [e.g.
>> http://www.gnu.org/software/grub/manual/grub.html] which says in
>> Section 3.4 "...or the core image can be installed in a file system
>> and a list of the blocks that make it up can be stored in the first
>> sector of that partition."
>>
>> I assumed that as the installer explicitly gave the option it would
>> handle the details. It apparently did not.
>>
>> After install,
>
> If this was a non-standard install, then "After install" on its own
> doesn't mean much.

I meant after the Installer had asked me all its questions and I 
gave go ahead to complete install.
The only strangeness should have been where grub was installed.
I emphasized the atypical nature because back in Squeeze days 
here was much "Don't do that" concerning putting grub in its own 
partition. When the installer APPEARED to offer me a desirable 
option, I chose it. Also I've lost the link to the instructions I 
had used then. Not sure if they would match the current version 
of Grub in any case.

>  What did you install where? What's in the MBR
> of the disk you installed on? (What the disk was used for previously
> might be important here.)

I used GPARTED Live to delete all existing partitions.
I then created a Ext2 partition at the beginning of the drive and 
flagged it as bootable. [This is partition I reserved for grub].
The remainder of drive was set up as extended partition.
Created a 3 GB Linux Swap at the end of the extended partition.
Created a 10 GB partition at the beginning of the extended 
partition for this install of Debian.

>  What did you write in your "grub partition"?

Me nothing ;) I assumed that when the installer asked me where to 
manually place grub it would do so. I had followed the installer 
formatting examples saying /dev/sda1 .

>> I am dumped into GRUB's rescue mode
>> "set" responds
>> prefix=(hd0,msdos1)/boot/grub
>> root=hd0,msdos1
>>
>> "ls" responds
>> (hd0) (hd0,msdos5) (hd0,msdos2) (hd0,msdos1)
>>
>> The title in readme.txt on the installation DVD reads "Debian
>> GNU/Linux 8.4.0 "Jessie" -
>>      Official i386 DVD Binary-1 20160402-13:26"
>>
>> I had set aside sda1 [2GB ext2] for grub.
>
> That's generous. My /boot directory contains 20MB (I only have
> one kernel installed) and /boot/grub contains 11MB.
>
>> Examining sda1 with a live edition of GPARTED shows ~33 MB has been
>> written to it.
>> Examining it with a live edition of Debian 7 shows no files, hidden
>> or not.
>
> Then presumably you didn't mount it and write any files on it during
> the installation? (33MB could be the filesystem metadata though I
> don't have an empty partition to see if this number is reasonable.)
>
>> Where will I find the missing details?
>
> Probably scattered in various forums. You may have to piece things
> together.

I suspected as much.

>  I'd be surprised if there was a mainstream HOWTO for your
> approach as it's so unusual.

If I'm successful that will change.
My goal is to learn enough about *nix too have the detail control 
of Slackware or "Linux from Scratch" with the advantages of 
Debian standard repositories.

If retirement is not for learning, what use is it?

>
> Cheers,
> David.
>
>

[toc] | [prev] | [next] | [standalone]

#170623

On Mon 01 Aug 2016 at 13:06:16 (-0500), Richard Owlett wrote:
> On 8/1/2016 12:01 PM, David Wright wrote:
> >On Mon 01 Aug 2016 at 10:37:28 (-0500), Richard Owlett wrote:
> >>*CAVEAT LECTOR*
> >>I _KNOW_ I'm doing an *ATYPICAL* install.
> >>I *REQUIRE* Grub to be its own partition.
> >>The Debian 8.4 installer at least recognizes that some users would
> >>desire Grub to be in its own partition.
> >>
> >>"Debian GNU/Linux Installation Guide"
> >>[https://www.debian.org/releases/stable/i386/] effectively ignores
> >>the issue.
> >>
> >>6.3.6.2. Install the Grub Boot Loader on a Hard Disk says only:
> >>...By default, grub will be installed into the Master Boot Record
> >>(MBR), where it will take over complete control of the boot process.
> >>If you prefer, you can install it elsewhere. See the grub manual for
> >>complete information. ...
> >>
> >>It does not even give a link for "grub manual" [e.g.
> >>http://www.gnu.org/software/grub/manual/grub.html] which says in
> >>Section 3.4 "...or the core image can be installed in a file system
> >>and a list of the blocks that make it up can be stored in the first
> >>sector of that partition."
> >>
> >>I assumed that as the installer explicitly gave the option it would
> >>handle the details. It apparently did not.
> >>
> >>After install,
> >
> >If this was a non-standard install, then "After install" on its own
> >doesn't mean much.
> 
> I meant after the Installer had asked me all its questions and I
> gave go ahead to complete install.

So which partitions did you ask it to create filesystems on, and what
were the mount points?

> The only strangeness should have been where grub was installed.
> I emphasized the atypical nature because back in Squeeze days here
> was much "Don't do that" concerning putting grub in its own
> partition. When the installer APPEARED to offer me a desirable
> option, I chose it. Also I've lost the link to the instructions I
> had used then. Not sure if they would match the current version of
> Grub in any case.
> 
> > What did you install where? What's in the MBR
> >of the disk you installed on? (What the disk was used for previously
> >might be important here.)
> 
> I used GPARTED Live to delete all existing partitions.
> I then created a Ext2 partition at the beginning of the drive and
> flagged it as bootable. [This is partition I reserved for grub].
> The remainder of drive was set up as extended partition.
> Created a 3 GB Linux Swap at the end of the extended partition.
> Created a 10 GB partition at the beginning of the extended partition
> for this install of Debian.
> 
> > What did you write in your "grub partition"?
> 
> Me nothing ;) I assumed that when the installer asked me where to
> manually place grub it would do so. I had followed the installer
> formatting examples saying /dev/sda1 .

See above. I don't know what you mean by "installer formatting
examples".

> >>I am dumped into GRUB's rescue mode
> >>"set" responds
> >>prefix=(hd0,msdos1)/boot/grub
> >>root=hd0,msdos1

Well, it would appear to me that grub was probably installed in the
MBR by a formerly existing OS that had /boot as part of / and that
was mounted from the first partition, hence the prefix...

> >>"ls" responds
> >>(hd0) (hd0,msdos5) (hd0,msdos2) (hd0,msdos1)

...and those are your newly created partitions.

There's probably another copy of grub at the start of the first
partition which you just wrote during the installation and is
being ignored by the one in the MBR as it doesn't know it's there.

You could probably confirm all this (or otherwise) by running
bootinfoscript.

> If I'm successful that will change.
> My goal is to learn enough about *nix too have the detail control of
> Slackware or "Linux from Scratch" with the advantages of Debian
> standard repositories.

Back to your reading then,

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#170624

On Mon, 1 Aug 2016 13:06:16 -0500
Richard Owlett <rowlett@cloud85.net> wrote:


> 
> If I'm successful that will change.
> My goal is to learn enough about *nix too have the detail control 
> of Slackware or "Linux from Scratch" with the advantages of 
> Debian standard repositories.
> 
> If retirement is not for learning, what use is it?
> 

There are two chunks of storage for grub: the files, stored in a normal
filesystem and available under /boot, and the bootloader itself, which
generally lives in the drive MBR, but can also live in a partition. The
bootloader is machine code which is stored outside any filesystem.

During expert installation, there are two relevant options: if during
the partition allocation stage, you ask for a separate /boot partition,
you will get this and the grub files will be stored there. You will
later be asked whether you want to install the bootloader in the MBR, or
in the root partition, or not at all, and it will be pointed out that
you will need to make your own arrangements for booting if you choose
the last.

In the early days of grub, the developers didn't pay too much attention
to the idea of a separate /boot partition, and there were at least
three occasions when a grub upgrade lost the capability of dealing with
it. After the first time, I knew what to do... it's been several years
since that last happened.

A separate boot partition was useful if you were multi-booting Linux
installations, but while that is less common today, it is also advised
(and may be mandatory) if you use LVM. Grub does know about LVM, as it
must in order to mount an LVM-based /, but it's one more thing to go
wrong in a boot and to make life a little harder if you need to fix a
broken system.

Installing the bootloader somewhere other than the MBR is useful if you
dual-boot with Windows, as the Windows bootloader *must* be in the MBR
and it can execute another bootloader at the beginning of a partition.
Oh, yes, it's only Windows which requires the partition 'bootable' flag
to be set, Linux pays no attention to it and will boot from any
partition.

To rebuild the grub.cfg file, which controls most aspects of booting,
run update-grub from within the target system (boot by other means and
chroot into it if it's broken). Then run grub-install /dev/sdX, where X
is either the complete drive, or a partition of the drive, to install
the bootloader. If you need to fix grub with a separate /boot, make sure
this is actually mounted when you do it, and if you've arrived into a
chroot, you will need to do this manually, along with /dev, /sys
and /proc. There are various how-tos on the Net.

If you need to work from a rescue OS, you must use one of the same
architecture, and I would strongly advise using exactly the same grub
version as is installed on the broken system. I wasted a lot of time
before I learned that, I can remember trying every CD-based Linux I
could find around the house (at least half a dozen) until I found one
which would work to repair my (old) broken Debian stable. The same
kernel is probably also a good idea if you need to use chroot, which
will still be using the boot system's kernel and its modules.

Good luck, and try not to swear at grub as much as I have over the
years...

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#170628

On 8/1/2016 2:15 PM, Joe wrote:
> On Mon, 1 Aug 2016 13:06:16 -0500
> Richard Owlett <rowlett@cloud85.net> wrote:
>
>
>>
>> If I'm successful that will change.
>> My goal is to learn enough about *nix too have the detail control
>> of Slackware or "Linux from Scratch" with the advantages of
>> Debian standard repositories.
>>
>> If retirement is not for learning, what use is it?
>>
>
> There are two chunks of storage for grub: the files, stored in a normal
> filesystem and available under /boot, and the bootloader itself, which
> generally lives in the drive MBR, but can also live in a partition. The
> bootloader is machine code which is stored outside any filesystem.
>
> During expert installation, there are two relevant options: if during
> the partition allocation stage, you ask for a separate /boot partition,
> you will get this and the grub files will be stored there. You will
> later be asked whether you want to install the bootloader in the MBR, or
> in the root partition, or not at all, and it will be pointed out that
> you will need to make your own arrangements for booting if you choose
> the last.

Those two paragraphs nudge a whole bunch of things. Into place 
correctly I hope ;/
I'll have to re-read a few references to be sure.

I have a laptop set aside for my "education". That "education" 
has included intentionally wiping all 70GB of the hard drive 3 or 
4 times in one week. It has *NO* connection to the internet, I 
purchase complete sets of installation DVD's.

> [snip]
>
> Good luck, and try not to swear at grub as much as I have over the
> years...

May I sputter at it occasionally? Got some reading and grocery 
shopping to do. Later.

[toc] | [prev] | [next] | [standalone]

#170632

Joe composed on 2016-08-01 20:15 (UTC+0100):

> Installing the bootloader somewhere other than the MBR is useful if you
> dual-boot with Windows,

And if you multiboot with >2. Every installation cannot own a single MBR. 
Better that none do, so that potential for conflict is entirely avoided[1]. 
Windows bootloaders can "chainload" Grub little differently than Grub can 
load Windows' bootloader.

> as the Windows bootloader *must* be in the MBR
> and it can execute another bootloader at the beginning of a partition.
> Oh, yes, it's only Windows which requires the partition 'bootable' flag
> to be set...

That was inherited from DOS, so DOS requires it too. And before Windows, OS/2 
too inherited it from DOS, and since OS/2 has successors, e.g. eComStation, 
they all require it, and require it on one and only primary partition, and on 
at least one BIOS HD. If a Linux tool sets the flag on more than one primary, 
it's created a cannot boot DOS/Win/OS2 configuration.

OS/2's MBR code is nominally different from Windows, but Windows' installers 
accept it and will not overwrite it as they will when they find the totally 
alien Grub code there.

[1] 
http://old-en.opensuse.org/Bugs/grub#How_does_a_PC_boot_.2F_How_can_I_set_up_a_working_GRUB.3F
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#170774

Le 06/08/2016 à 12:01, Pascal Hambourg a écrit :
>
> The first chunk is the "boot image" and must be stored into a MBR (whole
> disk boot sector) or PBR (partition boot sector). As it must fit into a
> 512-sector size

Oops. I meant 512-byte sector size.

[toc] | [prev] | [next] | [standalone]

#170775

Le 01/08/2016 à 21:15, Joe a écrit :
>
> There are two chunks of storage for grub:

Actually three, or even four.

> the files, stored in a normal filesystem and available under /boot,

Actually /boot/grub. GRUB does not store anything directly in /boot.

> and the bootloader itself, which
> generally lives in the drive MBR, but can also live in a partition. The
> bootloader is machine code which is stored outside any filesystem.

The files in /boot/grub are also part of the bootloader. GRUB cannot 
display its menu or boot any OS without them.

The first chunk is the "boot image" and must be stored into a MBR (whole 
disk boot sector) or PBR (partition boot sector). As it must fit into a 
512-sector size, all it does is load the next chuck using a hardcoded 
block list.

If the boot image is in a PBR, the BIOS won't load it directly so it 
must be chainloaded by another (primary) bootloader. The primary 
bootloader can be a standard MBR boot code (MSDOS style) which just 
loads and boot the PBR of the primary partition which has the "boot" 
flag set, or another bootloader such as LILO or another GRUB instance 
installed in the MBR.

The second chunk is the "core image". For historical technical reasons 
its size is about 30 kB, sometimes a bit more. It has three possible 
locations :
- on an MSDOS-partitionned disk, in the unallocated space between the 
MBR and the first partition (MBR gap). This space used to be 31 KiB when 
partitions were aligned on cylinder boundaries, but is now ~1 MB since 
partitions are aligned on 1 MiB boundaries ;
- on a GPT-partitionned disk, in a dedicated unformatted "BIOS boot" 
partition ;
- or as a regular file in a filesystem appearing as 
/boot/grub/i386-pc/core.img (or /boot/grub/core.img with older versions 
of GRUB such as the one in Wheezy). This option is not recommended as 
the filesystem may move the blocks around and the location of the core 
image is hardcoded into the boot image. Also this option is not possible 
when /boot/grub is not on the same disk as the boot image or not on a 
plain partition, e.g. on LVM, some software RAID levels, encrypted volume...

The first two locations (not in /boot/grub) are called "embedded".

Now, the confusion comes when you select the device to install GRUB. 
Actually this only selects the location of the boot image, i.e. in an 
MBR (if selecting a whole disk /dev/sdX) or a PBR (when selecting a 
partition /dev/sdXN). The location of the core image will be chosen 
automatically : embedded if possible, as a file otherwise.

Embedding is not possible if the core image is larger than the MBR gap 
on an MSDOS disk, if there is no BIOS boot partition on a GPT disk, or 
if the boot image is stored in a PBR.

In any case, AFAIK the boot image and the core image must be on the same 
disk.

The third chunk is the files in /boot/grub. In order to be able to read 
them, the core image will include the required modules to read the 
partition table and filesystem and optionally software RAID, LVM if 
needed. Not sure about encryption. I never managed to boot with 
/boot/grub on an encrypted volume.

The fourth chunk is the kernel and initrd/initramfs files that GRUB 
loads to boot an OS, as they are part of the boot process (but not part 
of GRUB itself). It can be located anywhere GRUB with all its modules 
can read. It is usually in /boot.

If the boot image fails to load the core image, you'll get an error and 
can do nothing but reboot. This happens when the core image was not 
embedded and either filesystem blocks were moved around or the partition 
containing /boot/grub was deleted.

If the core image fails to find the modules in /boot/grub/i386-pc/, it 
will drop into a rescue shell with limited capabilities, allowing to 
display known devices and correct the $prefix variable. This typically 
happens after the partition which contained /boot/grub has been deleted.

If it fails to find the /boot/grub/grub.cfg file, it will drop into a 
full-featured shell (the same you start by pressing 'c' in the boot 
menu) instead of displaying the boot menu.

So, what did you mean exactly by "install GRUB on its own partition" ?

[toc] | [prev] | [next] | [standalone]

#170776

On 8/6/2016 5:01 AM, Pascal Hambourg wrote:
> [snip details of where GRUB files are which I'm going have to study closely]
>
> So, what did you mean exactly by "install GRUB on its own
> partition" ?

I suspect my visualization of GRUB and the entire boot process is 
flawed. Some of my early reading may have been over simplified 
leading to some things I "know" just don't match reality. As I've 
said before "If retirement isn't for learning, what use is it?"

Thank you.

[toc] | [prev] | [next] | [standalone]

#170780

Pascal Hambourg composed on 2016-08-06 12:01 (UTC+0200):
...
> If the boot image is in a PBR, the BIOS won't load it directly

It will if the PBR is on a primary partition on the same disk. It's how all 
my systems boot if I'm not using IBM Boot Manager as the primary bootloader.

...
> - or as a regular file in a filesystem appearing as
> /boot/grub/i386-pc/core.img (or /boot/grub/core.img with older versions
> of GRUB such as the one in Wheezy). This option is not recommended as
> the filesystem may move the blocks around and the location of the core
> image is hardcoded into the boot image.

This "not recommended" philosophy corresponds almost perfectly with the 
practice universally complained about that Windows' installer replaces Grub 
code that it finds in the MBR with its own legacy/generic boot code, code 
which is just as capable of loading Grub code from a primary partition's PBR 
as it is loading Windows code from a primary partition's PBR, which is how 
Windows normally boots. When Grub is installed to a primary partition's PBR 
in the first place, Windows "hijacking" the MBR is a non-issue.[1]

As a practical matter, moving core image blocks around is uncommon, and just 
as easily fixed if and when it does occur as is reinstalling Grub to the MBR.

[1]
<http://old-en.opensuse.org/Bugs/grub#How_does_a_PC_boot_.2F_How_can_I_set_up_a_working_GRUB.3F>
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#170788

Le 06/08/2016 à 16:18, Felix Miata a écrit :
> Pascal Hambourg composed on 2016-08-06 12:01 (UTC+0200):
> ...
>> If the boot image is in a PBR, the BIOS won't load it directly
>
> It will if the PBR is on a primary partition on the same disk.

On the same disk as what ?

Do you mean that the BIOS can load directly the boot sector of a primary 
partition instead of the MBR ?

> It's how
> all my systems boot if I'm not using IBM Boot Manager as the primary
> bootloader.

What do you call "IBM Boot Manager" ? Is it the boot manager used by 
OS/2, or the generic/legacy boot code in the MBR used by MSDOS and 
Windows, which loads the PBR of the primary partition with the boot flag ?

Also, what does your MBR contains ? Only the partition table, no boot 
code at all ?

After reading your reply I made a quick test on three different PCs.
I installed a generic MBR boot code on a USB stick and checked that it 
could boot on each PC and load the PBR of the primary partition with the 
boot flag.
Then I erased the boot code (first 440 bytes in the MBR) with zeroes and 
observed that the boot hanged on all my test PCs, so I concluded that 
the BIOS still tried to load and execute the MBR because of the boot 
signature at the end of the MBR. Then I also removed the boot signature 
in the MBR and observed that the BIOS said the device was not bootable, 
as expected.

[toc] | [prev] | [next] | [standalone]

#170789

Pascal Hambourg composed on 2016-08-06 23:59 (UTC+0200):

> Felix Miata:

>> Pascal Hambourg composed on 2016-08-06 12:01 (UTC+0200):

I misread what you wrote. If I knew how to edit or delete a list posting as 
is typically possible in forums, I would. It shouldn't have been written, 
much less sent. :-(

>> ...
>>> If the boot image is in a PBR, the BIOS won't load it directly

>> It will if the PBR is on a primary partition on the same disk.

> On the same disk as what ?

> Do you mean that the BIOS can load directly the boot sector of a primary
> partition instead of the MBR ?

>> It's how
>> all my systems boot if I'm not using IBM Boot Manager as the primary
>> bootloader.

> What do you call "IBM Boot Manager" ? Is it the boot manager used by
> OS/2, or the generic/legacy boot code in the MBR used by MSDOS and
> Windows, which loads the PBR of the primary partition with the boot flag ?

> Also, what does your MBR contains ? Only the partition table, no boot
> code at all ?

> After reading your reply I made a quick test on three different PCs.
> I installed a generic MBR boot code on a USB stick and checked that it
> could boot on each PC and load the PBR of the primary partition with the
> boot flag.
> Then I erased the boot code (first 440 bytes in the MBR) with zeroes and
> observed that the boot hanged on all my test PCs, so I concluded that
> the BIOS still tried to load and execute the MBR because of the boot
> signature at the end of the MBR. Then I also removed the boot signature
> in the MBR and observed that the BIOS said the device was not bootable,
> as expected.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#170799

Le 06/08/2016 à 16:18, Felix Miata a écrit :
> Pascal Hambourg composed on 2016-08-06 12:01 (UTC+0200):
>
(location of GRUB's core image)
>> - or as a regular file in a filesystem appearing as
>> /boot/grub/i386-pc/core.img (or /boot/grub/core.img with older versions
>> of GRUB such as the one in Wheezy). This option is not recommended as
>> the filesystem may move the blocks around and the location of the core
>> image is hardcoded into the boot image.
>
> This "not recommended" philosophy corresponds almost perfectly with the
> practice universally complained about that Windows' installer replaces
> Grub code that it finds in the MBR with its own legacy/generic boot
> code, code which is just as capable of loading Grub code from a primary
> partition's PBR as it is loading Windows code from a primary partition's
> PBR, which is how Windows normally boots. When Grub is installed to a
> primary partition's PBR in the first place, Windows "hijacking" the MBR
> is a non-issue.[1]

I'm not sure I get your point and how it relates to the above.

> As a practical matter, moving core image blocks around is uncommon, and

Indeed, but it may become less uncommon with modern filesystems such as 
ext4 and btrfs. Of course you can stick to good old ext2 for /boot if 
you can afford a separate partition for it.

I also thought about setting the "i" flag (immutable file) with chattr, 
but the manpage does not mention that it prevents the filesystem handler 
from moving the file blocks around for garbage collection, 
defragmentation or whatever.

I once had a boot failure on a system with the core image in /boot/grub. 
The only explaination which came into my mind was that the core image 
blocks had been moved around. FWIW, the filesystem was ext4.

However it might be worth noting that writing GRUB's core image as a 
regular file is perfectly safe if it is not the primary bootloader but 
is chainloaded by another instance of GRUB with the "multiboot" command 
(taking the core image location as argument) instead of the usual 
"chainloader" command (taking the boot sector location as argument).

> just as easily fixed if and when it does occur as is reinstalling Grub
> to the MBR.

Easily fixed only if you can get your hands on the machine and boot a 
rescue system, e.g. by physical/KVM access or network boot.

[toc] | [prev] | [next] | [standalone]

#170620

[Multipart message — attachments visible in raw view] — view raw

On Monday, August 1, 2016 8:38 AM, Richard Owlett <rowlett@cloud85.net> wrote:


 
 > *CAVEAT LECTOR*
> I _KNOW_ I'm doing an *ATYPICAL* install.
> I *REQUIRE* Grub to be its own partition.
> The Debian 8.4 installer at least recognizes that some users 
> would desire Grub to be in its own partition.
Not sure if this is helpful, but could you redo the install in expert-mode, during which you get to pick and choose among the installation steps. Then, at the step for installing grub, you could do that in a shell or, perhaps expert mode gives more access to the commands being executed?




   

[toc] | [prev] | [next] | [standalone]

#170622

On 8/1/2016 12:20 PM, Brian Flaherty wrote:
> On Monday, August 1, 2016 8:38 AM, Richard Owlett
> <rowlett@cloud85.net> wrote:
>
>
>
>> *CAVEAT LECTOR*
>> I _KNOW_ I'm doing an *ATYPICAL* install.
>> I *REQUIRE* Grub to be its own partition.
>> The Debian 8.4 installer at least recognizes that some users
>> would desire Grub to be in its own partition.
>
> Not sure if this is helpful, but could you redo the install in
> expert-mode, during which you get to pick and choose among the
> installation steps. Then, at the step for installing grub, you
> could do that in a shell or, perhaps expert mode gives more
> access to the commands being executed?
>

The problem is that the grub manual [e.g. 
http://www.gnu.org/software/grub/manual/grub.html] only says 
[Section 3.4 ] "...or the core image can be installed in a file 
system and a list of the blocks that make it up can be stored in 
the first sector of that partition."

 From on list and off list responses, I have a weird idea. If it 
works it will demonstrate that there are people stranger than I - 
*nix manual authors ;/

more later.

[toc] | [prev] | [next] | [standalone]

#170752

On 8/1/2016 10:37 AM, Richard Owlett wrote:
> *CAVEAT LECTOR*
> I _KNOW_ I'm doing an *ATYPICAL* install.
> I *REQUIRE* Grub to be its own partition.
> The Debian 8.4 installer at least recognizes that some users
> would desire Grub to be in its own partition.
> [massive SNIP]

I've been thinking ;/
My original introduction started with a "solution" rather than a 
"problem report".

I'm having problems writing a readable and comprehensible problem 
description.

In the meantime here a links which cover some faces of the 
problem. Note that some links are dated, but show others have 
seen similar problems/environments.


http://www.gnu.org/software/grub/manual/grub.html
http://www.gnu.org/software/grub/manual/multiboot/multiboot.html
http://fm.no-ip.com/PC/install-doz-after.html
https://old-en.opensuse.org/Bugs/grub#How_does_a_PC_boot_.2F_How_can_I_set_up_a_working_GRUB.3F
http://web.archive.org/web/20150122211446/http://members.iinet.net.au/~herman546/p20/GRUB2%20Bash%20Commands.html#Dedicated_GRUB_Partition
http://web.archive.org/web/20100819160337/http://grub.enbug.org/grub.cfg
https://wiki.archlinux.org/index.php/Multiboot_USB_drive
http://www.stevesdebianstuff.org/lilo.htm
http://lists.gnu.org/archive/html/help-grub/2011-01/msg00017.html
https://help.ubuntu.com/community/Grub2"
https://lists.gnu.org/archive/html/grub-devel/2013-02/msg00032.html
https://lists.debian.org/debian-user/2014/04/msg00194.html
http://dedoimedo.com/computers/grub-2.html
http://fm.no-ip.com/PC/partitioningindex.html

[toc] | [prev] | [next] | [standalone]

#170759

On Fri 05 Aug 2016 at 13:44:54 (-0500), Richard Owlett wrote:
> On 8/1/2016 10:37 AM, Richard Owlett wrote:
> >*CAVEAT LECTOR*
> >I _KNOW_ I'm doing an *ATYPICAL* install.
> >I *REQUIRE* Grub to be its own partition.
> >The Debian 8.4 installer at least recognizes that some users
> >would desire Grub to be in its own partition.
> >[massive SNIP]
> 
> I've been thinking ;/
> My original introduction started with a "solution" rather than a
> "problem report".
> 
> I'm having problems writing a readable and comprehensible problem
> description.

How about trying to do
http://forums.justlinux.com/showthread.php?147959-How-to-install-and-boot-145-operating-systems-in-a-PC
but using grub2 instead...or perhaps just a subset.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#170761

On 8/5/2016 3:03 PM, David Wright wrote:
> On Fri 05 Aug 2016 at 13:44:54 (-0500), Richard Owlett wrote:
>> On 8/1/2016 10:37 AM, Richard Owlett wrote:
>>> *CAVEAT LECTOR*
>>> I _KNOW_ I'm doing an *ATYPICAL* install.
>>> I *REQUIRE* Grub to be its own partition.
>>> The Debian 8.4 installer at least recognizes that some users
>>> would desire Grub to be in its own partition.
>>> [massive SNIP]
>>
>> I've been thinking ;/
>> My original introduction started with a "solution" rather than a
>> "problem report".
>>
>> I'm having problems writing a readable and comprehensible problem
>> description.
>
> How about trying to do
> http://forums.justlinux.com/showthread.php?147959-How-to-install-and-boot-145-operating-systems-in-a-PC
> but using grub2 instead...or perhaps just a subset.
>

Richter 10^1000 *ROFL* event ;/
That man may be stranger than I.
I've only spent a few minutes browsing the site [and *SOME* 
referenced links].
The information may be dated, *BUT* it _WILL_ guide me to asking 
useful/relevant/??? questions.

!!!! *THANK YOU* !!!!

[toc] | [prev] | [next] | [standalone]

#170762 — [PRIVATE REPLY} Re: Problem with NON-STANDARD install

On 8/5/2016 3:03 PM, David Wright wrote:
> [snip]
> How about trying to do
> http://forums.justlinux.com/showthread.php?147959-How-to-install-and-boot-145-operating-systems-in-a-PC [snip]

forums.justlinux.com has a display problem.
As suggested I went to FAQ.
I clicked on "Contact Us".
Their 'bot filter asked me for n'th letter of problem forum.
NO forum problem. *SITE* problem.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web