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

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

Stupid question

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

Contents

  Stupid question Hans <hans.ullrich@loop.de> - 2022-02-12 10:10 +0100
    Re: Stupid question harryweaver@tutanota.com - 2022-02-12 11:40 +0100
    Re: Stupid question rhkramer@gmail.com - 2022-02-12 15:10 +0100
      Misremembered (was: Re: Stupid question) rhkramer@gmail.com - 2022-02-14 16:10 +0100
        Re: Misremembered (was: Re: Stupid question) Bijan Soleymani <bijan@psq.com> - 2022-02-14 16:20 +0100
          Re: Misremembered (was: Re: Stupid question) David Wright <deblis@lionunicorn.co.uk> - 2022-02-15 00:30 +0100
            Re: Misremembered (was: Re: Stupid question) David <bouncingcats@gmail.com> - 2022-02-15 02:30 +0100
              Re: Misremembered (was: Re: Stupid question) Curt <curty@free.fr> - 2022-02-15 12:40 +0100
            Re: Misremembered (was: Re: Stupid question) Andrei POPESCU <andreimpopescu@gmail.com> - 2022-02-15 19:30 +0100
              Re: Misremembered John Hasler <john@sugarbit.com> - 2022-02-15 19:50 +0100
                Re: Misremembered Andrei POPESCU <andreimpopescu@gmail.com> - 2022-02-15 20:20 +0100
                  Re: Misremembered John Hasler <john@sugarbit.com> - 2022-02-15 21:50 +0100
                    Re: Misremembered Emanuel Berg <moasenwood@zoho.eu> - 2022-02-16 00:10 +0100
                    Re: Misremembered Stefan Monnier <monnier@iro.umontreal.ca> - 2022-02-16 00:10 +0100
                      Re: Misremembered gene heskett <gheskett@shentel.net> - 2022-02-16 00:50 +0100
                        Re: Misremembered "Andrew M.A. Cater" <amacater@einval.com> - 2022-02-16 10:50 +0100
                          Re: Misremembered Cindy Sue Causey <butterflybytes@gmail.com> - 2022-02-16 11:40 +0100
              Re: Misremembered Stefan Monnier <monnier@iro.umontreal.ca> - 2022-02-15 20:40 +0100
              Re: Misremembered (was: Re: Stupid question) David Wright <deblis@lionunicorn.co.uk> - 2022-02-16 21:40 +0100
    Re: Stupid question David Christensen <dpchrist@holgerdanske.com> - 2022-02-12 19:30 +0100
    Re: Stupid question Chuck Zmudzinski <brchuckz@netscape.net> - 2022-02-13 08:50 +0100
      Re: Stupid question Andrei POPESCU <andreimpopescu@gmail.com> - 2022-02-13 17:30 +0100
        Re: Stupid question "Thomas Schmitt" <scdbackup@gmx.net> - 2022-02-13 18:30 +0100
        Re: Stupid question Andrei POPESCU <andreimpopescu@gmail.com> - 2022-02-14 22:00 +0100
          Re: Stupid question David <bouncingcats@gmail.com> - 2022-02-15 02:10 +0100
            Re: Stupid question Andrei POPESCU <andreimpopescu@gmail.com> - 2022-02-15 19:40 +0100
        Re: Booting with Grub, was Re: Stupid question David Wright <deblis@lionunicorn.co.uk> - 2022-02-15 00:20 +0100
    Re: dual booting, was Re: Stupid question David Wright <deblis@lionunicorn.co.uk> - 2022-02-13 18:10 +0100
      Re: dual booting, was Re: Stupid question Hans <hans.ullrich@loop.de> - 2022-02-13 19:00 +0100
        Re: dual booting, was Re: Stupid question David Wright <deblis@lionunicorn.co.uk> - 2022-02-15 17:20 +0100
      Re: dual booting, was Re: Stupid question Andrei POPESCU <andreimpopescu@gmail.com> - 2022-02-13 19:30 +0100
        Re: dual booting, was Re: Stupid question David <bouncingcats@gmail.com> - 2022-02-14 00:20 +0100
          Re: dual booting, was Re: Stupid question David Wright <deblis@lionunicorn.co.uk> - 2022-02-15 17:20 +0100
        Re: dual booting, was Re: Stupid question David Wright <deblis@lionunicorn.co.uk> - 2022-02-15 17:20 +0100

Page 2 of 2 — ← Prev page 1 [2]

#245318

On 2/12/2022 4:04 AM, Hans wrote:
> Dear list,
>
> I am thinking of a solution of a problem. But I have an understanding problem,
> maybe you can give some background knowledge.
>
> The problem: I have one harddrive, there are two linuces installed.
>
> The partitions are as followed:
>
> kali-linux: 1st primary -> /boot
>                   2nd > /
>
>
> debian    3rd primary -> /boot
>                 4th logical > /
> 	             > swap
>                                  > /home (encrypted)
>                                  > /usr (encrypted)
>                                  > /var (encrypted)
>
>
> This is the structure, and as said before, only ONE drive.
>
> Now my question: Is it possible to configure grub that way, that I can choose
> either kali or debian to boot?
>
> What I might to know, please correct me:
> Both are running different kernels. As far as I understood grub, I can set the
> root partition ( / ) with the UUID. This is an entry in grub.cfg and maybe in
> /etc/default/grub.
>
> But how can I tell grub, to use the kernel of the second /boot?
>
> I dunno, if it is possible at all, to get a dual boot, the way I want it. With
> a combination of Windows + Linux on one harddrive this is working, however,
> just because grub does not touch the windows bootloader (as fas as I know),
> and what of course is also working, if you got two harddrives, each with
> different linux. They all can be booted from one grub installation, of course.
>
> Maybe I could find a solution, if I would have fully understood how grub is
> working, and what it is doing.
>
> Any hints are welcome, and if this does never work at all, please drop me a
> line.
>
> Best regards
>
> Hans
>
>
>
>
>
>

This is my understanding of how grub works.

It looks you are using the old MBR partitioning scheme. The logical 
partition indicates that.
So I also assume you are using the legacy booting (not UEFI). So the 
first thing that
happens is that you will have an active partition set that your BIOS 
will boot (if you have
standard bootcode installed in the first sector of the disk). The active 
partition is either 1st
primary in which case you will boot from the grub from kali, or 3rd 
primary in which
case you will boot the grub from Debian. So first you need to see which 
partition your
BIOS boots. You can view or change the partitions and which one is the 
active boot
partition using a disk partition tool such as fdisk.

If you set Debian's grub on the 3rd partition as the active boot 
partition, you should
be able to fairly easily display a menu to select either kali or Debian 
on the grub menu.
You will need to make sure os-prober is enabled, it is enabled by 
default on bullseye
and older, but I think in bookworm and sid you need to enable it by a 
setting in
/etc/default/grub). The changelog for grub on bookworm and unstable has 
an entry to
tell you how, I think. You also need to set the timeout to something 
(usually 5 or 10
seconds) to display the menu, and you can also set a default OS to boot in
/etc/default/grub to handle the case when you do not select an OS before the
timeout expires.

After that, you just run sudo update-grub from your Debian system and 
then on the next
reboot the grub menu should have entries for both kali and Debian.

Cheers,

Chuck

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

#245335

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

On Du, 13 feb 22, 02:40:27, Chuck Zmudzinski wrote:
> 
> This is my understanding of how grub works.
> 
> It looks you are using the old MBR partitioning scheme. The logical
> partition indicates that.
> So I also assume you are using the legacy booting (not UEFI). So the first
> thing that
> happens is that you will have an active partition set that your BIOS will
> boot (if you have
> standard bootcode installed in the first sector of the disk). 

Legacy BIOS doesn't have an understanding of partitions, it will just 
look for a bootloader in the MBR of the mass storage device chosen to 
boot from.

The active / bootable flag was (still is?) a Microsoft thing[1], Linux 
bootloaders never cared about it and can load operating systems 
regardless if the corresponding partition is marked active or not.

[1] as far as I recall it was used in DOS times to let the bootloader 
know which is the system partition, but it could be (ab)used for 
multi-booting ;)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#245340

Hi,

Chuck Zmudzinski wrote:
> > It looks you are using the old MBR partitioning scheme. The logical
> > partition indicates that.
> > So I also assume you are using the legacy booting (not UEFI).

Not necessarily. It is specified that the EFI System Partition may
be marked by a MBR partition table entry of type 0xEF.
In practice many EFI implementations look into any partition which
contains a FAT filesystem with the CPU-specific boot program in
directory \EFI\BOOT.

There have been seen some younger Lenovo laptops which won't consider
an MBR partition of type 0xEF unless a GPT header block is present on
the storage device.


> > So the first thing that
> > happens is that you will have an active partition set that your BIOS will
> > boot (if you have standard bootcode installed in the first sector of the
> > disk).

Andrei POPESCU wrote:

> Legacy BIOS doesn't have an understanding of partitions, it will just
> look for a bootloader in the MBR of the mass storage device chosen to
> boot from.

In theory, yes. In practice there have been seen old HP laptops which
don't consider a device if it does not have an MBR partition table with
the active/boot flag set to some of the partitions.


Have a nice day :)

Thomas

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

#245386

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

On Lu, 14 feb 22, 10:41:52, Chuck Zmudzinski wrote:
> 
> That's a good clarification that the active partition is a Microsoft thing
> implemented by the bootcode Microsoft installs in the MBR of the device
> chosen to boot from. Now for an unanswered question: What
> does bootcode installed by Debian Linux in the MBR do? 

Typically that would be the first stage of GRUB (other boot loaders 
exist). In very broad terms the first stage will then load the rest of 
GRUB from a partition and run grub.cfg if one exists.

> How does it decide which partition to boot from? I think this is what 
> the OP is asking.

I'm guessing by "boot" here you mean GRUB itself, because once it's 
fully loaded it can boot OSes from any partition it can find / support.

As far as I understand the path to search for the second stage, modules 
and grub.cfg is defined when installing the first stage in the MBR.

By default it should be /boot/grub of the OS used to run grub-install 
from, but I think the --root-directory parameter can be used to change 
that.

Changes to the path are typically done by reinstalling GRUB to the MBR.


Hope this explains,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#245396

On Tue, 15 Feb 2022 at 07:57, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> On Lu, 14 feb 22, 10:41:52, Chuck Zmudzinski wrote:

> > How does it decide which partition to boot from? I think this is what
> > the OP is asking.

> As far as I understand the path to search for the second stage, modules
> and grub.cfg is defined when installing the first stage in the MBR.

> By default it should be /boot/grub of the OS used to run grub-install
> from, but I think the --root-directory parameter can be used to change
> that.

A minor typo correction for the avoidance of doubt for any readers ...

To "change that" you would use the --boot-directory
parameter of 'grub-install' command, see 'man 8 grub-install'.

ie "--boot-directory" not "--root-directory"

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

#245435

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

On Ma, 15 feb 22, 11:59:59, David wrote:
> On Tue, 15 Feb 2022 at 07:57, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> > On Lu, 14 feb 22, 10:41:52, Chuck Zmudzinski wrote:
> 
> > > How does it decide which partition to boot from? I think this is what
> > > the OP is asking.
> 
> > As far as I understand the path to search for the second stage, modules
> > and grub.cfg is defined when installing the first stage in the MBR.
> 
> > By default it should be /boot/grub of the OS used to run grub-install
> > from, but I think the --root-directory parameter can be used to change
> > that.
> 
> A minor typo correction for the avoidance of doubt for any readers ...
> 
> To "change that" you would use the --boot-directory
> parameter of 'grub-install' command, see 'man 8 grub-install'.
> 
> ie "--boot-directory" not "--root-directory"
 
Ugh, I used manpages.debian.org to look it up and didn't notice it 
opened grub-install(8) from grub-legacy instead of grub2-common.

Apologies for any confusion.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#245389 — Re: Booting with Grub, was Re: Stupid question

On Mon 14 Feb 2022 at 10:41:52 (-0500), Chuck Zmudzinski wrote:
> On 2/13/2022 11:23 AM, Andrei POPESCU wrote:
> > On Du, 13 feb 22, 02:40:27, Chuck Zmudzinski wrote:
> > > This is my understanding of how grub works.
> > > 
> > > It looks you are using the old MBR partitioning scheme. The logical
> > > partition indicates that.
> > > So I also assume you are using the legacy booting (not UEFI). So the first
> > > thing that
> > > happens is that you will have an active partition set that your BIOS will
> > > boot (if you have
> > > standard bootcode installed in the first sector of the disk).
> > Legacy BIOS doesn't have an understanding of partitions, it will just
> > look for a bootloader in the MBR of the mass storage device chosen to
> > boot from.
> > 
> > The active / bootable flag was (still is?) a Microsoft thing[1], Linux
> > bootloaders never cared about it and can load operating systems
> > regardless if the corresponding partition is marked active or not.
> > 
> > [1] as far as I recall it was used in DOS times to let the bootloader
> > know which is the system partition, but it could be (ab)used for
> > multi-booting ;)
> 
> That's a good clarification that the active partition is a Microsoft thing
> implemented by the bootcode Microsoft installs in the MBR of the device
> chosen to boot from. Now for an unanswered question: What
> does bootcode installed by Debian Linux in the MBR do? How does it
> decide which partition to boot from? I think this is what the OP
> is asking.

By reading the grub.cfg that Grub is directed to use by the
grub-install command. In my post, I tried to keep it simple
for the OP by instructing them to run grub-install from the
installation whose /boot/grub/grub.cfg was to be read.
Of course, Grub, being Grub, and grandly universal, you don't
have to do it like that, as David ably showed. You can install
Grub by running grub-install from anywhere, and directing it
to use files from anywhere else.   man 8 grub-install.

The point is that when you install Grub into the MBR (plus the
BIOS Boot partition on GPT disks), you build a program that
can read devices and filesystems: hence it can find a
/boot/grub/grub.cfg wherever it is placed.

Both the Grub MBR and the Windows one are relatively "thick",
but not stupid. After all, there aren't many bytes in one
sector. The distinction is that Windows-MBR will jump to the
partition marked by the boot flag, whereas Grub-MBR jumps to
a fixed location (built in when you install it) where its
core-image (actually its core-iamge-loader) is located. That
image is necessarily outside any filesystem so that it can't
get moved by fs operations. (As GPT disks don't necessarily
contain any such areas, that's why you need a BIOS Boot
partition, as a playground for Grub.) It's the core image
that's really clever.

Disclaimers: Everything above assumes BIOS booting.

Windows-MBR is an oversimplification, but the distinction
between the two is what's important here. There has been
some evolution in capabilities (not much), and not all
originate from Microsoft either.

Cheers,
David.

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

#245338 — Re: dual booting, was Re: Stupid question

On Sat 12 Feb 2022 at 10:04:43 (+0100), Hans wrote:
> 
> I am thinking of a solution of a problem. But I have an understanding problem, 
> maybe you can give some background knowledge.
> 
> The problem: I have one harddrive, there are two linuces installed.
> 
> The partitions are as followed:
> 
> kali-linux: 1st primary -> /boot
>                  2nd > /

I have to assume that this is a complete linux installation here, with
the possible exception that you could unlock the /home partition (below)
and mount it with either of the systems. That's my standard practice
with two Debians on one drive. (I share swap too.)

> debian    3rd primary -> /boot
>                4th logical > /
> 	             > swap
>                                 > /home (encrypted)
>                                 > /usr (encrypted)
>                                 > /var (encrypted)

It's not generally useful to encrypt /usr if it only consists of
free software, because it's public knowledge. It would be more
useful to encrypt swap.

Sharing /usr between two almost identical /Debian/ systems could
be made to work with care and expertise. OTOH I don't see how you
could sensibly share /var/lib in any way, because it's used to
maintain the state of a system — /one/ system.

But the level of your questions here would indicate that you're
going to struggle to do anything resembling that. I don't know
anything about kali (except the coloured sherbet of my childhood).
So your layout, above, worries me as it seems to imply more than
you're actually saying here. (Not the layout of the partitions
on the disk, but the text's alignment in the layout above.)

> This is the structure, and as said before, only ONE drive.
> 
> Now my question: Is it possible to configure grub that way, that I can choose 
> either kali or debian to boot?

I'm assuming that you're booting an MBR disk in a BIOS system,
seeing that your disk looks like something that DOS or Windows
would have created years ago (three primary partitions, and an
extended partition containing five logical partitions).

So, yes. You just install the systems as normal. Each installer
should install its own grub packages, and they should configure
its own /boot/grub/ directory (a process you can repeat at any
time by running update-grub¹ on that system). Each installer
should also install Grub's boot code in the disk's MBR (which
will overwrite any previous code).

> What I might to know, please correct me:
> Both are running different kernels.

This is irrelevant, as long as the systems defined by partitions
1, 2 ± /home are not being comingled with that defined by 3, 4
± /home, and that /usr and /var are "owned" entirely by either
one system or the other.

> As far as I understood grub, I can set the 
> root partition ( / ) with the UUID. This is an entry in grub.cfg

For Debian, that is the default. It's done for you: you don't have
to transcribe any UUIDs by typing them in.

> and maybe in 
> /etc/default/grub.

In that file, one can /prevent/ the use of UUIDs by Grub, but it
makes no sense for you to do so.

> But how can I tell grub, to use the kernel of the second /boot? 

If/when you install a system "A" on the disk, its Grub configuration
will only know about that system, and boot it by default. When you
install system B, B's Grub will scan² and see both systems, adding
menu entries for both in its own grub.cfg. Grub on the MBR will
be made to point to B's grub.cfg, and that will have B listed as
the default system to boot (first in the menu).

If you want to boot A, just select it from the menu presented by B's
grub.

When you boot and run A, you can update-grub¹ and that will scan
and see both systems, writing A's grub.cfg with A as the default
system to boot /in its grub.cfg/. However, A's grub.cfg will never
be consulted, because the MBR points to B's grub.cfg. (Think of
B as the "master system".)

(Only if you run grub-install on system A will the MBR be overwritten
so that it points to A's grub.cfg, and from then on, booting would
use A's grub.cfg.)

None of this matters until you upgrade one of the systems with
a new kernel (pretty common) or a new grub (fairly uncommon).
When you upgrade, say, A (the non-master system), A's updated
grub.cfg will be brought up-to-date. But typically, upgrades
will not touch the MBR as there's no need. So, if your MBR was
pointing to B's grub.cfg, the menu items in B for booting A
will be out of date and pointing to the wrong kernel version.

You have to either:

. In A, after the upgrade, run grub-install to make the MBR point
  here, to A's grub.cfg. (A is now the "master system".)

or

. Reboot (which will still use B's grub.cfg) and select B. When
  B is running, run update-grub¹ to freshen its grub.cfg. Now,
  B's grub.cfg will have up-to-date entries for A's kernel.
  (B remains the "master system".)

Typically, one would have a primary, "master" linux system which would
be used to write an MBR pointing to itself. The other, legacy system
would have its grub.cfg kept up-to-date, but would never touch the
MBR by running grub-install.

> I dunno, if it is possible at all, to get a dual boot, the way I want it. With 
> a combination of Windows + Linux on one harddrive this is working, however, 
> just because grub does not touch the windows bootloader (as fas as I know), 
> and what of course is also working, if you got two harddrives, each with 
> different linux. They all can be booted from one grub installation, of course.

Traditionally, the simple way of dual booting linux+Windows was to
install Windows first (normally done by the manufacturer, of course)
and then install linux. The installer would write an entry to chainload
Windows from grub.cfg, and overwrite the disk's MBR to point to this
grub.cfg. A Windows entry in grub.cfg might look something like:

  menuentry 'Windows 7 (loader) (on /dev/sdb1)' --class windows … 'osprober-chain-8CA4761234769684' {
    …
    search --no-floppy --fs-uuid --set=root 8CA4761234769684
    parttool ${root} hidden-
    chainloader +1
}

But having multiple drives just complicates the issue, because the
BIOS now has to choose which /disk/ to boot, and therefore which
disk's MBR gets executed. That choice is not always unambiguous,
and is difficult to generalise about because BIOSes vary a lot.

With Windows, there's also the complication that Windows's MBR (the
one that it writes, if you let it) may require the partition to have
a "boot flag" in order to boot it.

> Maybe I could find a solution, if I would have fully understood how grub is 
> working, and what it is doing.

Just remember update-grub¹ writes grub.cfg into this system, with a list
of bootable systems on the computer, whereas grub-install makes the MBR
point to the grub.cfg on this system.

> Any hints are welcome, and if this does never work at all, please drop me a 
> line.

¹ I'm using the Debian names for the programs concerned.
  update-grub is just a wrapper round grub-mkconfig (in
  case you look at Grub documentation).

² Install os-prober if it is absent. Enable it if it is
  disabled.

Cheers,
David.

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

#245341 — Re: dual booting, was Re: Stupid question

Hi David,
yes, that is what I thought, would be working. But sadly did not.

I expected, after using update-grub, that os-prober would detect both 
partitions with the menu.lst or grub.cfg inside and create two entries in the 
boot menu.

However, this did not work, only one (the last installation, which was kali), 
was seen.

Maybe I did something wrong! 

I had had Windows-7 and Debian on the hardddrive. Then I deleted the Windows-7 
partition (good choice, eh?) and installed kali on this partition. 

With installing grub during the installation process, I expected grub to see 
both, kali and debian. But, it only recognized kali.

So my idea was, to edit kali's grub.cfg manually, so that I got two entries, 
but did not succeed (becauuse I did not know, how exactly to do).


Meanwhile I am using the whole harddrive for kali, because I discovered that 
the partition was to small for kali (34GB, but I needed 50GB).

But I think, this problem will appear in some time, when I am buying a bigger 
harddrive, where I intend to put several different operating systems on one 
harddrive. 

Thanks for the feedback, and all your help. 

If I got a solution, I will tell you.

Best regards

Hans 
> If you want to boot A, just select it from the menu presented by B's
> grub.
> 
> When you boot and run A, you can update-grub¹ and that will scan
> and see both systems, writing A's grub.cfg with A as the default
> system to boot /in its grub.cfg/. However, A's grub.cfg will never
> be consulted, because the MBR points to B's grub.cfg. (Think of
> B as the "master system".)
> 
> (Only if you run grub-install on system A will the MBR be overwritten
> so that it points to A's grub.cfg, and from then on, booting would
> use A's grub.cfg.)

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

#245422 — Re: dual booting, was Re: Stupid question

With respect to the original problem, this response is moot.

On Sun 13 Feb 2022 at 18:50:43 (+0100), Hans wrote:

> > If you want to boot A, just select it from the menu presented by B's
> > grub.
> > 
> > When you boot and run A, you can update-grub¹ and that will scan
> > and see both systems, writing A's grub.cfg with A as the default
> > system to boot /in its grub.cfg/. However, A's grub.cfg will never
> > be consulted, because the MBR points to B's grub.cfg. (Think of
> > B as the "master system".)
> > 
> > (Only if you run grub-install on system A will the MBR be overwritten
> > so that it points to A's grub.cfg, and from then on, booting would
> > use A's grub.cfg.)

> yes, that is what I thought, would be working. But sadly did not.
> 
> I expected, after using update-grub, that os-prober would detect both 
> partitions with the menu.lst or grub.cfg inside and create two entries in the 
> boot menu.
> 
> However, this did not work, only one (the last installation, which was kali), 
> was seen.
> 
> Maybe I did something wrong! 

Saying something didn't work is no help. Even the observation here
is of little use without the pasted output, and possibly requires
yet more context than that.

And saying "the menu.lst or grub.cfg inside" gives the /impression/
that you're not doing the work on your side, not even looking to
see what you're dealing with.

> I had had Windows-7 and Debian on the hardddrive. Then I deleted the Windows-7 
> partition (good choice, eh?) and installed kali on this partition. 
> 
> With installing grub during the installation process, I expected grub to see 
> both, kali and debian. But, it only recognized kali.
> 
> So my idea was, to edit kali's grub.cfg manually, so that I got two entries, 
> but did not succeed (becauuse I did not know, how exactly to do).

Again, your report is sadly lacking. No indication of what is where,
even though I had tried to guess in my first post. And no indication
of the edits you made and what the output said, just "did not succeed".

> Meanwhile I am using the whole harddrive for kali, because I discovered that 
> the partition was to small for kali (34GB, but I needed 50GB).
> 
> But I think, this problem will appear in some time, when I am buying a bigger 
> harddrive, where I intend to put several different operating systems on one 
> harddrive. 

When it does, please read some parts of these before you post:

http://www.catb.org/~esr/faqs/smart-questions.html
https://www.chiark.greenend.org.uk/~sgtatham/bugs.html

> Thanks for the feedback, and all your help. 
> 
> If I got a solution, I will tell you.

Cheers,
David.

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

#245342 — Re: dual booting, was Re: Stupid question

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

On Du, 13 feb 22, 11:01:48, David Wright wrote:
> 
> Typically, one would have a primary, "master" linux system which would
> be used to write an MBR pointing to itself. The other, legacy system
> would have its grub.cfg kept up-to-date, but would never touch the
> MBR by running grub-install.

Another option (at least with MBR, didn't try this with GPT) is to tell 
the Installer to install GRUB in the partition instead of the MBR, and 
then manually install another GRUB instance to the MBR with a 
handcrafted config that is chain-loading the GRUBs in the partitions.

This way each system's GRUB config is nicely following kernel upgrades 
automatically.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#245352 — Re: dual booting, was Re: Stupid question

On Mon, 14 Feb 2022 at 05:27, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> On Du, 13 feb 22, 11:01:48, David Wright wrote:

TLDR:
On the topic of grub automatic configuration
1) suggestions how to avoid it
2) why I prefer to do that

Disclaimer: contains generalisations and lacks full justifications of
points made. This is just a brain dump of some thoughts that some
people might find useful alternative options. I don't have time to
polish it into a nice piece of considered writing. If you disagree
with something, that's fine. I'm just offering an alternative
perspective, not trying to change your mind :)

> > Typically, one would have a primary, "master" linux system which would
> > be used to write an MBR pointing to itself. The other, legacy system
> > would have its grub.cfg kept up-to-date, but would never touch the
> > MBR by running grub-install.

> Another option (at least with MBR, didn't try this with GPT) is to tell
> the Installer to install GRUB in the partition instead of the MBR, and
> then manually install another GRUB instance to the MBR with a
> handcrafted config that is chain-loading the GRUBs in the partitions.

And yet another option for avoiding bootloader conflicts in multiboot
setups (at least with MBR, didn't try this with GPT) is to avoid
installing the os-prober and/or grub-update machinery on all but one
of the linux installs. This can be done (in the installer expert mode,
and maybe the others) by skipping the "install grub" step and choosing
"install without a boot loader". It's provided for a good reason :)

The installed OS will run fine without grub, provided that you ensure
that there is a bootloader somewhere else that can start it. That's
your job now! After booting, if you want to you can even install a
constrained version of grub that lacks the grub-update machinery, by
installing the package 'grub-pc-bin' instead of 'grub-pc'.

It too is provided for a good reason :)
As the maintainer says:

$ apt show grub-pc-bin
  [...]
It can be installed in parallel with other flavours, but will not
automatically install GRUB as the active boot loader nor automatically
update grub.cfg on upgrade unless grub-pc is also installed.
$

When grub2 first was released I avoided it for years! I do not like
the automation that generates the grub.cfg file so full of
human-unfriendly content, compared to grub version 1.

The automation is fine if it works and gives results you like, so you
can ignore it. It is a heroic programming effort and I'm sure it
handles all sorts of situations that I've never considered.

However I was/am multibooting various OS, and I didn't like
to watch helplessly while os-prober made all kinds of inappropriate
decisions on my systems and update-grub mangled my boot menus.

The idea of automation is worthy, but it seems to me with grub2 that
years later one downside is that we have moved to a situation of
learned helplessness. Now we have people in the situation like Hans,
where we have to explain the grub automation as if it is the only
possible way to do things.

And no-one dares to touch their grub.cfg anymore because it's
overwheming. Even though most of that overwhelming content is very
much not necessary, it is a primary deterrent causing people to avoid
configuring the bootloader menu themselves. People ask about how to
tinker with the tiny bit of configuration that grub exposes [1], and we
don't dare to recommend that they throw it all away because we've all
become reliant on the automation. And explaining the alternative is
too hard.

And if that automation breaks for some reason, like Stella had a while
back, then in general everyone is helpless because it's too hard to
give instruction on how to write their own grub.cfg and recover. I
suppose I could write something for the wiki but I'm too lazy or too
busy, and therefore part of the problem.

Plus multiboot is quite unfashionable, other people like to advocate
more modern methods with VM and such. I prefer not to become reliant
on infrastructure that I can avoid (I do use VM for throwaway tasks).
And these days I'm not multibooting disk partitions, I'm multibooting
logical volumes inside one huge LUKS container that I only need to
create once and provide one password for at boot. I like having
all my multiboot filesystems easily mountable from everywhere,
it helps me manage them collectively with scripts.

Eventually I dug a little bit deeper with grub2. I experimented by writing
my own simple grub.cfg. When that worked, the next step was to learn
ways to prevent that effort being blown away by the automation at
every update, as described above. Thee are other ways to do this too [2].

I persevered and I eventually learned to love grub2. It has some
amazing features. Once you can get it to stop imposing its default
behaviour on you, it's a powerful ally.

For instance, it contains a full scripting language [3]. The authors
wanted a control language, so they built a shell-like parser into it.

Do you know that you can write functions in grub!!! The autogenerated
grub.cfg files could be greatly simplified by using that feature, if
someone had time to implement that.

My grub.cfg files are quite complicated, but they are things of beauty
(to the beholder, haha) now because I use functions to contain all the
complexity. And what used to be a "stanza" for each OS is now a single
line of configuration values.

Also worth reading [4].

A couple of useful commands to get started playing
with hand-rolled grub configuration files:
  grub-script-check
  grub-emu

And this is the long story of how I learned to love grub2.
And why I love open-source software. Now, time to stop writing
this and work on other things :)

[1] I think that's in /etc/default/grub but not sure because
I don't have that file
[2] /etc/grub.d/README
[3] https://www.gnu.org/software/grub/manual/grub/grub.html#Shell_002dlike-scripting
[4] https://www.gnu.org/software/grub/manual/grub/grub.html#Multi_002dboot-manual-config

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

#245420 — Re: dual booting, was Re: Stupid question

On Mon 14 Feb 2022 at 10:18:13 (+1100), David wrote:
> On Mon, 14 Feb 2022 at 05:27, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> > On Du, 13 feb 22, 11:01:48, David Wright wrote:
> 
> TLDR:
> On the topic of grub automatic configuration
> 1) suggestions how to avoid it
> 2) why I prefer to do that
> 
> Disclaimer: contains generalisations and lacks full justifications of
> points made. This is just a brain dump of some thoughts that some
> people might find useful alternative options. I don't have time to
> polish it into a nice piece of considered writing. If you disagree
> with something, that's fine. I'm just offering an alternative
> perspective, not trying to change your mind :)

Ditto in this response.

> > > Typically, one would have a primary, "master" linux system which would
> > > be used to write an MBR pointing to itself. The other, legacy system
> > > would have its grub.cfg kept up-to-date, but would never touch the
> > > MBR by running grub-install.
> 
> > Another option (at least with MBR, didn't try this with GPT) is to tell
> > the Installer to install GRUB in the partition instead of the MBR, and
> > then manually install another GRUB instance to the MBR with a
> > handcrafted config that is chain-loading the GRUBs in the partitions.

(I've responded to this post itself.)

> And yet another option for avoiding bootloader conflicts in multiboot
> setups (at least with MBR, didn't try this with GPT) is to avoid
> installing the os-prober and/or grub-update machinery on all but one
> of the linux installs. This can be done (in the installer expert mode,
> and maybe the others) by skipping the "install grub" step and choosing
> "install without a boot loader". It's provided for a good reason :)
> 
> The installed OS will run fine without grub, provided that you ensure
> that there is a bootloader somewhere else that can start it. That's
> your job now! After booting, if you want to you can even install a
> constrained version of grub that lacks the grub-update machinery, by
> installing the package 'grub-pc-bin' instead of 'grub-pc'.
> 
> It too is provided for a good reason :)
> As the maintainer says:
> 
> $ apt show grub-pc-bin
>   [...]
> It can be installed in parallel with other flavours, but will not
> automatically install GRUB as the active boot loader nor automatically
> update grub.cfg on upgrade unless grub-pc is also installed.
> $

I must think about that with respect to my PC that has three Debians,
one booting with UEFI- and two with BIOS-mode. Of course, I can currently
boot all three in either mode, and even update-grub, but grub-install
might cause problems if run in the wrong mode.

I was considering how to convert a BIOS-mode installation into a
UEFI one (I'm posting that in another thread), but I could just
leave the two BIOS ones with no grub at all.

> When grub2 first was released I avoided it for years! I do not like
> the automation that generates the grub.cfg file so full of
> human-unfriendly content, compared to grub version 1.
> 
> The automation is fine if it works and gives results you like, so you
> can ignore it. It is a heroic programming effort and I'm sure it
> handles all sorts of situations that I've never considered.
> 
> However I was/am multibooting various OS, and I didn't like
> to watch helplessly while os-prober made all kinds of inappropriate
> decisions on my systems and update-grub mangled my boot menus.
> 
> The idea of automation is worthy, but it seems to me with grub2 that
> years later one downside is that we have moved to a situation of
> learned helplessness. Now we have people in the situation like Hans,
> where we have to explain the grub automation as if it is the only
> possible way to do things.

(I like "learned helplessness"!) True, but the upside of posting
only the "official" automated way is that you don't have to support
it. As you suggested above, a customised method would really require
a polished HOWTO, were I to recommend it.

> And no-one dares to touch their grub.cfg anymore because it's
> overwheming. Even though most of that overwhelming content is very
> much not necessary, it is a primary deterrent causing people to avoid
> configuring the bootloader menu themselves. People ask about how to
> tinker with the tiny bit of configuration that grub exposes [1], and we
> don't dare to recommend that they throw it all away because we've all
> become reliant on the automation. And explaining the alternative is
> too hard.

Yes, I've certainly used the GRUB_DEFAULT for the NextBoot
facility in the past: when fsck'ing a device took ages, NextBoot
would automatically select a forcefsck boot when the BIOS turned
the machine on (again, automatically) in the morning. And
GRUB_CMDLINE_LINUX is still useful for adding system-dependent
tweaks, like libata.force=3.00:disable on a broken machine
and video=960x540 on a laptop with unusable resolution.

But I run a shell script on any new grub.cfg that automatically
makes all the changes I want (like UUIDs → LABELs). I'll probably
stick with that until I dispose of the last non-UEFI machine,
and then consider Felix's post from a while back:

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx





> And if that automation breaks for some reason, like Stella had a while
> back, then in general everyone is helpless because it's too hard to
> give instruction on how to write their own grub.cfg and recover. I
> suppose I could write something for the wiki but I'm too lazy or too
> busy, and therefore part of the problem.
> 
> Plus multiboot is quite unfashionable, other people like to advocate
> more modern methods with VM and such. I prefer not to become reliant
> on infrastructure that I can avoid (I do use VM for throwaway tasks).
> And these days I'm not multibooting disk partitions, I'm multibooting
> logical volumes inside one huge LUKS container that I only need to
> create once and provide one password for at boot. I like having
> all my multiboot filesystems easily mountable from everywhere,
> it helps me manage them collectively with scripts.
> 
> Eventually I dug a little bit deeper with grub2. I experimented by writing
> my own simple grub.cfg. When that worked, the next step was to learn
> ways to prevent that effort being blown away by the automation at
> every update, as described above. Thee are other ways to do this too [2].
> 
> I persevered and I eventually learned to love grub2. It has some
> amazing features. Once you can get it to stop imposing its default
> behaviour on you, it's a powerful ally.
> 
> For instance, it contains a full scripting language [3]. The authors
> wanted a control language, so they built a shell-like parser into it.
> 
> Do you know that you can write functions in grub!!! The autogenerated
> grub.cfg files could be greatly simplified by using that feature, if
> someone had time to implement that.
> 
> My grub.cfg files are quite complicated, but they are things of beauty
> (to the beholder, haha) now because I use functions to contain all the
> complexity. And what used to be a "stanza" for each OS is now a single
> line of configuration values.
> 
> Also worth reading [4].
> 
> A couple of useful commands to get started playing
> with hand-rolled grub configuration files:
>   grub-script-check
>   grub-emu
> 
> And this is the long story of how I learned to love grub2.
> And why I love open-source software. Now, time to stop writing
> this and work on other things :)
> 
> [1] I think that's in /etc/default/grub but not sure because
> I don't have that file
> [2] /etc/grub.d/README
> [3] https://www.gnu.org/software/grub/manual/grub/grub.html#Shell_002dlike-scripting
> [4] https://www.gnu.org/software/grub/manual/grub/grub.html#Multi_002dboot-manual-config
> 

Cheers,
David.

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

#245419 — Re: dual booting, was Re: Stupid question

On Sun 13 Feb 2022 at 19:26:51 (+0100), Andrei POPESCU wrote:
> On Du, 13 feb 22, 11:01:48, David Wright wrote:
> > 
> > Typically, one would have a primary, "master" linux system which would
> > be used to write an MBR pointing to itself. The other, legacy system
> > would have its grub.cfg kept up-to-date, but would never touch the
> > MBR by running grub-install.
> 
> Another option (at least with MBR, didn't try this with GPT) is to tell 
> the Installer to install GRUB in the partition instead of the MBR, and 
> then manually install another GRUB instance to the MBR with a 
> handcrafted config that is chain-loading the GRUBs in the partitions.
> 
> This way each system's GRUB config is nicely following kernel upgrades 
> automatically.

There are implications in doing that. If you install Grub on a logical
partition, then some sources suggest that you get the space for its
core.img after the Extended Boot Record (EBR), but I don't see any
firm evidence for that, particularly if the partitioning was done by
non-Windows partitioners, and compounded by non-CHS disks.

I can't examine a real example as I haven't created a logical
partition since the last millennium.

As for primary partitions after the first, there's no BR for there
to be a gap after. So the core.img for Grub has to be placed in the
filesystem itself, yet it's addressed by block addresses, which are
not known to nor respected by normal filesystem utilities, and which
therefore means they can get moved.

As for GPT disks, where you have to use a BIOS Boot partition for
Grub's core.img, there's no way to manage that space other than to
juggle multiple such partitions so that each Grub instance is forced
to use a different BIOS Boot partition instance.

Cheers,
David.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web