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


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

Dual Boot

Started byDan Norton <dnorton@mindspring.com>
First post2016-11-25 16:50 +0100
Last post2016-11-25 17:10 +0100
Articles 8 — 5 participants

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


Contents

  Dual Boot Dan Norton <dnorton@mindspring.com> - 2016-11-25 16:50 +0100
    Re: Dual Boot Hans <hans.ullrich@loop.de> - 2016-11-25 17:00 +0100
      Re: Dual Boot Jan Bakuwel <jan.bakuwel@gmail.com> - 2016-11-25 19:40 +0100
        Re: Dual Boot Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-11-25 23:10 +0100
          Re: Dual Boot Jan Bakuwel <jan.bakuwel@gmail.com> - 2016-11-27 21:10 +0100
            Re: Dual Boot Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-11-28 00:50 +0100
              Re: Dual Boot Jan Bakuwel <jan.bakuwel@gmail.com> - 2016-11-28 05:30 +0100
    Re: Dual Boot Alexandre GRIVEAUX <agriveaux@deutnet.info> - 2016-11-25 17:10 +0100

#175054 — Dual Boot

FromDan Norton <dnorton@mindspring.com>
Date2016-11-25 16:50 +0100
SubjectDual Boot
Message-ID<sHqVb-2o9-19@gated-at.bofh.it>
Net install noticed that Windows 7 was present, said it would provide a 
choice to select it in the boot menu, but failed to do that. The boot 
menu has Debian Jessie and the advanced boot option. Thinking I must 
have screwed something up, I deleted the Debian partition and 
re-installed carefully - same result. I am a Linux novice.

The windows partition can be mounted and files can be copied from it. 
Hardware is HP 3400 with 1.0 TB and the hardware boot menu states:

UEFI Boot Sources
Legacy Boot Sources
   ATAPI CD/DVD Drive
     SATA2
   Hard Drive
     SATA0
   Network Controller (etc.)

The heading on the boot menu says:

GNU GRUB version 2.02~beta2-22+deb8u1

How can the boot menu be changed to include Windows?

[toc] | [next] | [standalone]


#175056

FromHans <hans.ullrich@loop.de>
Date2016-11-25 17:00 +0100
Message-ID<sHr4R-2rt-7@gated-at.bofh.it>
In reply to#175054
Am Freitag, 25. November 2016, 10:15:09 CET schrieb Dan Norton:

Hi Dan, 

I have a similar problem with Kali-Linux and Debian. Everytime I upgrade a 
kernel in kali-linux (which is on second drive), it overwrites grub on the 
first drive.

My solution: I am booting "super-grub-disk-2" (google for it), and from this I 
can boot the old grub configuration.

When booted into debian (by using super-grub-disk-2), I am able to reinstall 
grub on the first drive again. 

You can either use "dpkg-reconfigure grub-pc" or "update-grub" or even just 
reinstall the package "grub-pc".

I also tried to use the debian installation cd in rescue mode, but I never get 
success. At all, I am really not very happy with debian installation cd in 
rescue mode. My favourites are special live rescue  cd's like Trinity-Rescue-
Kit, RIP, Knoppix and GRML.

Hope this helps a little bit.

Good luck!

Hans
> Net install noticed that Windows 7 was present, said it would provide a
> choice to select it in the boot menu, but failed to do that. The boot
> menu has Debian Jessie and the advanced boot option. Thinking I must
> have screwed something up, I deleted the Debian partition and
> re-installed carefully - same result. I am a Linux novice.
> 
> The windows partition can be mounted and files can be copied from it.
> Hardware is HP 3400 with 1.0 TB and the hardware boot menu states:
> 
> UEFI Boot Sources
> Legacy Boot Sources
>    ATAPI CD/DVD Drive
>      SATA2
>    Hard Drive
>      SATA0
>    Network Controller (etc.)
> 
> The heading on the boot menu says:
> 
> GNU GRUB version 2.02~beta2-22+deb8u1
> 
> How can the boot menu be changed to include Windows?

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


#175061

FromJan Bakuwel <jan.bakuwel@gmail.com>
Date2016-11-25 19:40 +0100
Message-ID<sHtzH-49a-13@gated-at.bofh.it>
In reply to#175056
Hi Dan, Hans,

> On 26/11/2016, at 04:51, Hans <hans.ullrich@loop.de> wrote:
> 
> Am Freitag, 25. November 2016, 10:15:09 CET schrieb Dan Norton:
> 
> Hi Dan, 
> 
> I have a similar problem with Kali-Linux and Debian. Everytime I upgrade a 
> kernel in kali-linux (which is on second drive), it overwrites grub on the 
> first drive.
> 
> My solution: I am booting "super-grub-disk-2" (google for it), and from this I 
> can boot the old grub configuration.
> 
> When booted into debian (by using super-grub-disk-2), I am able to reinstall 
> grub on the first drive again. 
> 
> You can either use "dpkg-reconfigure grub-pc" or "update-grub" or even just 
> reinstall the package "grub-pc".
> 
> I also tried to use the debian installation cd in rescue mode, but I never get 
> success. At all, I am really not very happy with debian installation cd in 
> rescue mode. My favourites are special live rescue  cd's like Trinity-Rescue-
> Kit, RIP, Knoppix and GRML.

What I do is have a small "boot/rescue" OS installed in the first partition (in my case Debian). It's boot loader is installed in the MBR. The only function of this OS is to chain load another OS (and perhaps for rescue purposes if something bad happens). In my case there's two flavors of Windows (although I never use those: using Windows in Virtualbox when I need it is more convenient) and three flavors of Linux: I don"t like throwing my old shoes away until I know I can walk on the new.

All these OSes of course need there own partitions. For reasons beyond my understanding grub complains about being installed in a partition instead of the MBR ("embedding is not supported and a BAD idea", yet it works fine). But since there likely is a logical reason for that warning, I'm moving away from grub and use extlinux instead.

The point of this is that each Linux OS can do whatever it likes (ie upgrades) with it's boot partition and boot loader: new kernel versions, new boot loader without affecting the "master boot loader".

Hopefully update-grub as Alexandre suggested will add Windows to the grub menu.

hope this helps,
Jan

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


#175072

FromPascal Hambourg <pascal@plouf.fr.eu.org>
Date2016-11-25 23:10 +0100
Message-ID<sHwQW-6mO-13@gated-at.bofh.it>
In reply to#175061
Le 25/11/2016 à 19:31, Jan Bakuwel a écrit :
>
> For reasons beyond my understanding grub complains about being
> installed in a partition instead of the MBR ("embedding is not
> supported and a BAD idea", yet it works fine).

The GRUB BIOS boot loader is split off in three main parts :
- the boot image stored in the MBR or in a partition boot sector (PBR)
- the core image stored in a special area outside a filesystem (called 
"embedding") or as a regular file in a filesystem
- modules, config files and so on stored in /boot/grub/

The only purpose of the boot image is to load the core image. The boot 
image is a very small program which must fit into a single sector, so it 
does not understand any partition table or filesystem format. It reads a 
hardcoded list of physical sectors ranges ("blocklists") which contain 
the core image.

Embedding of the core image is only (but not always) possible when the 
boot image is in the MBR and there is a big enough "embedded area" 
between the MBR and the first partition on a DOS/MBR partition table or 
a "BIOS boot" partition on a GPT partition table, or when the boot image 
is in a partition boot sector and the partition format contains a 
suitable area for embedding.

I have yet to find such a partition format, so when installing the boot 
image in the PBR of a partition with any usual contents type (ext4, LVM 
physical volume, RAID member...), embedding is not possible.

When embedding is not possible, the core image is stored as a regular 
file in /boot/grub. Then /boot/grub must be on the same drive as the 
boot image. However blocklists are not reliable with files, because the 
filesystem may move blocks containing a file around.

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


#175121

FromJan Bakuwel <jan.bakuwel@gmail.com>
Date2016-11-27 21:10 +0100
Message-ID<sIdVT-Ay-3@gated-at.bofh.it>
In reply to#175072
Hi Pascal,

Thanks for responding.

On 26/11/16 11:01, Pascal Hambourg wrote:
> Le 25/11/2016 à 19:31, Jan Bakuwel a écrit :
>>
>> For reasons beyond my understanding grub complains about being
>> installed in a partition instead of the MBR ("embedding is not
>> supported and a BAD idea", yet it works fine).
>
> The GRUB BIOS boot loader is split off in three main parts :
> - the boot image stored in the MBR or in a partition boot sector (PBR)
> - the core image stored in a special area outside a filesystem (called
> "embedding") or as a regular file in a filesystem
> - modules, config files and so on stored in /boot/grub/
>
> The only purpose of the boot image is to load the core image. The boot
> image is a very small program which must fit into a single sector, so
> it does not understand any partition table or filesystem format. It
> reads a hardcoded list of physical sectors ranges ("blocklists") which
> contain the core image.
>
> Embedding of the core image is only (but not always) possible when the
> boot image is in the MBR and there is a big enough "embedded area"
> between the MBR and the first partition on a DOS/MBR partition table
> or a "BIOS boot" partition on a GPT partition table, or when the boot
> image is in a partition boot sector and the partition format contains
> a suitable area for embedding.
>
> I have yet to find such a partition format, so when installing the
> boot image in the PBR of a partition with any usual contents type
> (ext4, LVM physical volume, RAID member...), embedding is not possible.
>
> When embedding is not possible, the core image is stored as a regular
> file in /boot/grub. Then /boot/grub must be on the same drive as the
> boot image. However blocklists are not reliable with files, because
> the filesystem may move blocks containing a file around.

I find it extremely useful (to the point where it once literally saved
me from disaster which is a story beyond the context of this thread) to
have multiple OS-es installed on any machine. I've been doing that for
years and even with grub it has - so far - always worked fine. But I
hear you that that's not a guarantee, and thus I started using extlinux.

Which brings me to the following question: what is the recommended way
to boot multiple OSes with grub, for example with a partition layout as
below. Or is there simply no sane way to do this with grub?

/dev/sda1: boot/rescue system

/dev/sda2: Windows 7
/dev/sda3: Windows 10

/dev/sda5: /boot - Linux system 1
/dev/sda6: / - Linux system 1
/dev/sda7: /var - Linux system 1
/dev/sda8: /var/log - Linux system 1

/dev/sda9: /boot - Linux system 2
/dev/sda10: / - Linux system 2
/dev/sda11: /var - Linux system 2
/dev/sda12: /var/log - Linux system 2

/dev/sda13: swap
/dev/sda14: LVM

best regards,
Jan

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


#175131

FromPascal Hambourg <pascal@plouf.fr.eu.org>
Date2016-11-28 00:50 +0100
Message-ID<sIhmN-2DD-9@gated-at.bofh.it>
In reply to#175121
Le 27/11/2016 à 21:02, Jan Bakuwel a écrit :
>
> On 26/11/16 11:01, Pascal Hambourg wrote:
>>
>> When embedding is not possible, the core image is stored as a regular
>> file in /boot/grub. Then /boot/grub must be on the same drive as the
>> boot image. However blocklists are not reliable with files, because
>> the filesystem may move blocks containing a file around.
>
> I find it extremely useful (to the point where it once literally saved
> me from disaster which is a story beyond the context of this thread) to
> have multiple OS-es installed on any machine. I've been doing that for
> years and even with grub it has - so far - always worked fine. But I
> hear you that that's not a guarantee, and thus I started using extlinux.

I think that I experienced that problem once (but not sure), and needed 
to reinstall GRUB. To be honest, the chances that the blocs containing 
the core image may be moved around are very thin if you have a separate 
ext2 /boot partition, which is rarely modified.

> Which brings me to the following question: what is the recommended way
> to boot multiple OSes with grub, for example with a partition layout as
> below. Or is there simply no sane way to do this with grub?

I would not pretend to know "the recommended way".
However I would recommend a few layouts for some configurations.

If EFI boot is an option, then install all systems for EFI boot (for 
Windows this implies a GPT partition table on the boot disk). This way 
all bootloaders can be installed in separate directories in the EFI 
system partition without overwriting one another. You can define one of 
them as the primary boot loader with higher boot priority in the EFI 
boot list.

For BIOS boot, without Windows I would recommend to install a primary 
GRUB in the MBR with embedding. Install secondary GRUBs in partitions 
boot records, without embedding. Then you have several options :

- add all entries for Windows and other Linux system kernels in the main 
GRUB menu, which can be done automatically with os-prober called by 
update-grub. The drawback is that the main boot menu must be updated 
everytime a secondary boot loader is updated.

- add entries to chainload the secondary boot loaders in the main GRUB 
menu, so that the main boot menu does not have to be updated when a 
secondary boot loader is updated. The "multiboot" command can be used to 
load a secondary GRUB core image file, so the embedding requirement does 
not apply here.

- include or load secondary GRUB config files in the main boot menu. 
This does not work well with different versions of GRUB, so I do not 
recommend it.

One must also decide whether to use the GRUB belonging to one of the 
Linux systems or an independent GRUB as the main boot loader. Of course 
there is less risk to damage an independent boot loader.

So my advice for a safe setup would be to :
- install the main GRUB in the MBR and its own partition for /boot/grub
- install each secondary GRUB in its OS partition
- chainload secondary GRUBs in the main GRUB's boot menu

Unfortunately with Windows the MBR is not a safe place because Windows 
overwrites the MBR at installation and sometimes when updating, so be 
prepared to restore a backup or reinstall GRUB. The boot record of the 
main GRUB's partition is a safer place, but it prevents embedding, so 
the risk of moving blocks comes back. However this partition should not 
be mounted and modified often, so the risk is low.

> /dev/sda1: boot/rescue system
>
> /dev/sda2: Windows 7
> /dev/sda3: Windows 10
>
> /dev/sda5: /boot - Linux system 1
> /dev/sda6: / - Linux system 1
> /dev/sda7: /var - Linux system 1
> /dev/sda8: /var/log - Linux system 1
>
> /dev/sda9: /boot - Linux system 2
> /dev/sda10: / - Linux system 2
> /dev/sda11: /var - Linux system 2
> /dev/sda12: /var/log - Linux system 2
>
> /dev/sda13: swap
> /dev/sda14: LVM

 From the missing /dev/sda4, I guess it is an extended partition and 
/dev/sda{5..14} are logical partitions in a DOS/MBR scheme. 10 logical 
partition is quite a lot. The linked list extended partition structure 
is quite fragile and rigid. A GPT partition table would be more robust, 
but it requires to reinstall reinstall Windows in EFI mode, and of 
course that the motherboard firmware is a UEFI. Otherwise, using LVM for 
most filesystems and swap is an option to reduce the number of partitions.

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


#175137

FromJan Bakuwel <jan.bakuwel@gmail.com>
Date2016-11-28 05:30 +0100
Message-ID<sIlJL-5y0-13@gated-at.bofh.it>
In reply to#175131
Hi Pascal,

On 28/11/16 12:48, Pascal Hambourg wrote:
> Le 27/11/2016 à 21:02, Jan Bakuwel a écrit :
>>
>> On 26/11/16 11:01, Pascal Hambourg wrote:
>>>
>>> When embedding is not possible, the core image is stored as a regular
>>> file in /boot/grub. Then /boot/grub must be on the same drive as the
>>> boot image. However blocklists are not reliable with files, because
>>> the filesystem may move blocks containing a file around.
>>
>> I find it extremely useful (to the point where it once literally saved
>> me from disaster which is a story beyond the context of this thread) to
>> have multiple OS-es installed on any machine. I've been doing that for
>> years and even with grub it has - so far - always worked fine. But I
>> hear you that that's not a guarantee, and thus I started using extlinux.
>
> I think that I experienced that problem once (but not sure), and
> needed to reinstall GRUB. To be honest, the chances that the blocs
> containing the core image may be moved around are very thin if you
> have a separate ext2 /boot partition, which is rarely modified.
>
>> Which brings me to the following question: what is the recommended way
>> to boot multiple OSes with grub, for example with a partition layout as
>> below. Or is there simply no sane way to do this with grub?
>
> I would not pretend to know "the recommended way".
> However I would recommend a few layouts for some configurations.
>
> If EFI boot is an option, then install all systems for EFI boot (for
> Windows this implies a GPT partition table on the boot disk). This way
> all bootloaders can be installed in separate directories in the EFI
> system partition without overwriting one another. You can define one
> of them as the primary boot loader with higher boot priority in the
> EFI boot list.

One day I'll have to bite that bullet but that day has not come yet :-)

>
> For BIOS boot, without Windows I would recommend to install a primary
> GRUB in the MBR with embedding. Install secondary GRUBs in partitions
> boot records, without embedding. Then you have several options :
>
> - add all entries for Windows and other Linux system kernels in the
> main GRUB menu, which can be done automatically with os-prober called
> by update-grub. The drawback is that the main boot menu must be
> updated everytime a secondary boot loader is updated.
>
> - add entries to chainload the secondary boot loaders in the main GRUB
> menu, so that the main boot menu does not have to be updated when a
> secondary boot loader is updated. The "multiboot" command can be used
> to load a secondary GRUB core image file, so the embedding requirement
> does not apply here.
>
> - include or load secondary GRUB config files in the main boot menu.
> This does not work well with different versions of GRUB, so I do not
> recommend it.
>
> One must also decide whether to use the GRUB belonging to one of the
> Linux systems or an independent GRUB as the main boot loader. Of
> course there is less risk to damage an independent boot loader.
>
> So my advice for a safe setup would be to :
> - install the main GRUB in the MBR and its own partition for /boot/grub
> - install each secondary GRUB in its OS partition
> - chainload secondary GRUBs in the main GRUB's boot menu

This is how I've done it (before using extlinux). I still have a few
servers on grub using this method.

>
> Unfortunately with Windows the MBR is not a safe place because Windows
> overwrites the MBR at installation and sometimes when updating, so be
> prepared to restore a backup or reinstall GRUB. 

Yep. Haven't seen Windows mucking up the MBR with an update though - yet.

> The boot record of the main GRUB's partition is a safer place, but it
> prevents embedding, so the risk of moving blocks comes back. However
> this partition should not be mounted and modified often, so the risk
> is low.

Only keeping Windows on my workstation for video editing with Windows
running on the bare metal.
Never on the servers though.

>
>> /dev/sda1: boot/rescue system
>>
>> /dev/sda2: Windows 7
>> /dev/sda3: Windows 10
>>
>> /dev/sda5: /boot - Linux system 1
>> /dev/sda6: / - Linux system 1
>> /dev/sda7: /var - Linux system 1
>> /dev/sda8: /var/log - Linux system 1
>>
>> /dev/sda9: /boot - Linux system 2
>> /dev/sda10: / - Linux system 2
>> /dev/sda11: /var - Linux system 2
>> /dev/sda12: /var/log - Linux system 2
>>
>> /dev/sda13: swap
>> /dev/sda14: LVM
>
> From the missing /dev/sda4, I guess it is an extended partition and
> /dev/sda{5..14} are logical partitions in a DOS/MBR scheme. 10 logical
> partition is quite a lot. The linked list extended partition structure
> is quite fragile and rigid. A GPT partition table would be more
> robust, but it requires to reinstall reinstall Windows in EFI mode,
> and of course that the motherboard firmware is a UEFI. Otherwise,
> using LVM for most filesystems and swap is an option to reduce the
> number of partitions.

For new servers I surely will be using more LVM and less partitions.
DOS/MBR partitions work fine for me though...

thanks,
Jan

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


#175057

FromAlexandre GRIVEAUX <agriveaux@deutnet.info>
Date2016-11-25 17:10 +0100
Message-ID<sHrex-2Lj-13@gated-at.bofh.it>
In reply to#175054
Hello,

You can try, running in terminal:
sudo update-grub2

Le 25/11/2016 à 16:15, Dan Norton a écrit :
> Net install noticed that Windows 7 was present, said it would provide
> a choice to select it in the boot menu, but failed to do that. The
> boot menu has Debian Jessie and the advanced boot option. Thinking I
> must have screwed something up, I deleted the Debian partition and
> re-installed carefully - same result. I am a Linux novice.
>
> The windows partition can be mounted and files can be copied from it.
> Hardware is HP 3400 with 1.0 TB and the hardware boot menu states:
>
> UEFI Boot Sources
> Legacy Boot Sources
>   ATAPI CD/DVD Drive
>     SATA2
>   Hard Drive
>     SATA0
>   Network Controller (etc.)
>
> The heading on the boot menu says:
>
> GNU GRUB version 2.02~beta2-22+deb8u1
>
> How can the boot menu be changed to include Windows?
>

[toc] | [prev] | [standalone]


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


csiph-web