Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Dr Rainer Woitok]

Michael,

On Thursday, 2024-05-16 17:46:04 +0100, you wrote:

> ...
> > The homepage returned by
> > 
> >$ eix --verbose sys-boot/elilo
> >* sys-boot/elilo
> > Available versions:  ~3.16-r5
> > ...
> >$
> > 
> > hints that this package is no longer maintained ... :-(
> > ...
> 
> Oh!  I haven't ever used it, but recalled its name and found it on the tree.  
> I suppose if it's stable and it works, it works whether maintained or not.

Well,  the "~" ahead of the  version number says  it's non-stable.   And
considering that booting is rather hardware, firmware and kernel related
and dependent, I personally would stay off of such a package :-/

Sincerely,
  Rainer

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Michael]

On Thursday, 16 May 2024 17:41:20 BST Dr Rainer Woitok wrote:
> Michael,
> 
> On Thursday, 2024-05-16 09:26:39 +0100, you wrote:
> > ...
> > 
> > > > I liked lilo. And then it disappeared :-(
> > > 
> > > ...
> > > 
> > >  Still available and still working on non-uefi setups:
> > > https://packages.gentoo.org/packages/sys-boot/lilo
> > > 
> > > ...
> > 
> > There's also 'sys-boot/elilo' for EFI systems.
> 
> The homepage returned by
> 
>$ eix --verbose sys-boot/elilo
>* sys-boot/elilo
> Available versions:  ~3.16-r5
> Homepage:https://sourceforge.net/projects/elilo/
> Description: Linux boot loader for EFI-based systems such as
> IA-64 License: GPL-2
>$
> 
> hints that this package is no longer maintained ... :-(
> 
> Sincerely,
>   Rainer

Oh!  I haven't ever used it, but recalled its name and found it on the tree.  
I suppose if it's stable and it works, it works whether maintained or not.

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Dr Rainer Woitok]

Michael,

On Thursday, 2024-05-16 09:26:39 +0100, you wrote:

> ...
> > > I liked lilo. And then it disappeared :-(
> > ...
> >  Still available and still working on non-uefi setups:
> > https://packages.gentoo.org/packages/sys-boot/lilo
> > 
> > ...
> 
> There's also 'sys-boot/elilo' for EFI systems.

The homepage returned by

   $ eix --verbose sys-boot/elilo
   * sys-boot/elilo
Available versions:  ~3.16-r5
Homepage:https://sourceforge.net/projects/elilo/
Description: Linux boot loader for EFI-based systems such as 
IA-64
License: GPL-2
   $

hints that this package is no longer maintained ... :-(

Sincerely,
  Rainer

[gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Nuno Silva]

On 2024-05-16, Michael wrote:

> On Thursday, 16 May 2024 01:10:32 BST k...@aspodata.se wrote:
>> Wol:
>> > On 15/05/2024 11:40, Peter Humphrey wrote:
>> > > I think whoever named grub had delusions of grandeur.  🙂  Anyway, I
>> > > never let it near my systems.
>> > 
>> > I liked lilo. And then it disappeared :-(
>> 
>> ...
>> 
>>  Still available and still working on non-uefi setups:
>> https://packages.gentoo.org/packages/sys-boot/lilo
>> 
>> Regards,
>> /Karl Hammar
>
> There's also 'sys-boot/elilo' for EFI systems.

What about grub as in "grub1" or grub0.xx for PC BIOS, is it still
available (outside the main tree?) and working e.g. with patches, or is
there some unsolved compilation issue nowadays?

-- 
Nuno Silva

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Michael]

On Thursday, 16 May 2024 01:10:32 BST k...@aspodata.se wrote:
> Wol:
> > On 15/05/2024 11:40, Peter Humphrey wrote:
> > > I think whoever named grub had delusions of grandeur.  🙂  Anyway, I
> > > never let it near my systems.
> > 
> > I liked lilo. And then it disappeared :-(
> 
> ...
> 
>  Still available and still working on non-uefi setups:
> https://packages.gentoo.org/packages/sys-boot/lilo
> 
> Regards,
> /Karl Hammar

There's also 'sys-boot/elilo' for EFI systems.


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[karl]

Wol:
> On 15/05/2024 11:40, Peter Humphrey wrote:
> > I think whoever named grub had delusions of grandeur.  🙂  Anyway, I 
> > never let
> > it near my systems.
> 
> I liked lilo. And then it disappeared :-(
...

 Still available and still working on non-uefi setups:
https://packages.gentoo.org/packages/sys-boot/lilo

Regards,
/Karl Hammar

[gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Grant Edwards]

On 2024-05-15, Wols Lists  wrote:
> On 15/05/2024 11:40, Peter Humphrey wrote:
>> I think whoever named grub had delusions of grandeur.    Anyway, I never let
>> it near my systems.
>
> I liked lilo. And then it disappeared :-(
>
> Grub isn't that bad - it's just that insists on trying to do everything 
> itself - and if you've got at all a strange setup it makes a complete 
> hash of it.

Grub2 is a bit overblown, but it's quite usable as long as you stick
to a manually generated grub.cfg file and stay away from the
auto-magical disk-probing configuration script world-domination
scheme.

--
Grant

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Wols Lists]

On 15/05/2024 11:40, Peter Humphrey wrote:

I think whoever named grub had delusions of grandeur.    Anyway, I never let
it near my systems.


I liked lilo. And then it disappeared :-(

Grub isn't that bad - it's just that insists on trying to do everything 
itself - and if you've got at all a strange setup it makes a complete 
hash of it.


LIKE GENTOO!

I've moaned about this before, but last time SUSE updated itself, it 
trashed grub.conf and left me with an unbootable system. And then gentoo 
sees that I've got an unmounted /boot and throws a complete and utter 
hissy fit because I told it not to touch it ...


Cheers,
Wol

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Peter Humphrey]

On Wednesday, 15 May 2024 08:42:14 BST Wols Lists wrote:
> On 02/05/2024 11:46, Peter Humphrey wrote:
> > When I started using Linux, the received wisdom was to keep a separate
> > /boot, and leave it unmounted during normal operation. The idea was that
> > a successful hacker would not, supposedly, be able to corrupt the kernel
> > ready for a reboot into their system.
> 
> And you can't have /boot on your system partition if, like me, you have
> one instance of grub booting into several different OSs or distros ...
> Less so now, but having multiple distros on one system was a popular
> hobbyist pastime!

I think whoever named grub had delusions of grandeur.  :)  Anyway, I never let 
it near my systems.

-- 
Regards,
Peter.


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Wols Lists]

On 02/05/2024 11:46, Peter Humphrey wrote:

When I started using Linux, the received wisdom was to keep a separate /boot,
and leave it unmounted during normal operation. The idea was that a successful
hacker would not, supposedly, be able to corrupt the kernel ready for a reboot
into their system.


And you can't have /boot on your system partition if, like me, you have 
one instance of grub booting into several different OSs or distros ... 
Less so now, but having multiple distros on one system was a popular 
hobbyist pastime!


(One distro's system partition is another distro's data partion :-)

Cheers,
Wol

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Wols Lists]

On 02/05/2024 10:35, Michael wrote:

Besides the automation this feature affords, I find it useful to know what a
partition contains without having to mount it.  On GPT labelled disks I make
use both of the Partition Type UUID and the Partition Name.  A quick glance at
the gdisk output and if need be its 'i' option has saved my day from
formatting the wrong partition more than once!  


Iirc from the days of kernel 1.3 and 2.x, the partition type is not used 
- at all - by linux itself. Dunno about other OSs.


As you pointed out, though, it is used by other tools, which use it to 
identify what the partition is *supposed* to be used for. For example, 
auto-assemble with raid.


I'm not sure, but for example I think swap will quite happily let you 
"mount" a non-swap partiton with swap-on. You can format an allegedly 
DOS or NTFS partition with ext, and linux won't care ...


Cheers,
Wol

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Peter Humphrey]

On Thursday, 2 May 2024 00:45:29 BST Dale wrote:
> Grant Edwards wrote:
> > OK, so 'boot' is for the Linux /boot directory.  I was just curious
> > since I had never used one.

When I started using Linux, the received wisdom was to keep a separate /boot, 
and leave it unmounted during normal operation. The idea was that a successful 
hacker would not, supposedly, be able to corrupt the kernel ready for a reboot 
into their system.

Old habits die hard, though, and besides, a separate /boot has been handy in 
the copious reinstallations I've been through.

> I've used one ever since I started using Linux and it's as much habit as
> anything.  Given the size of drives nowadays, I have started putting
> /usr and /var on the root partition.  When I build my new rig tho, odds
> are /var will be on its own partition.  That way if a log file goes
> wonky, it can fill it up and not really do any harm. 

I do that too. It also helps with backups and new installations.

-- 
Regards,
Peter.


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Dale]

Michael wrote:
> On Thursday, 2 May 2024 00:45:29 BST Dale wrote:
>> Grant Edwards wrote:
>>> On 2024-05-01, Dale  wrote:
 Grant Edwards wrote:
> The partition type code for 'swap' is wrong -- it should be
> 8200. According to the gdisk help info Linux /home is supposed to be
> 8302, but I've always used the same generic "Linux filesystem" type
> for both /home and root.
>
> Is the 'boot' partition for future possible UEFI use, for Linux /boot,
> or both?  [I've never used a separate partition for Linux /boot, I
> just use a /boot directory on the root FS.]
 I noticed the other day that some new ones was added.  I always leave it
 as 8300 and it works.  It even works for swap.  I dunno. 
> In the legacy DOS partition tables the space available was limited to 32 
> bits, 
> while the GPT table specification provides 128 bytes for each block entry.  
> The extra space can be used to store information related to the intended OS 
> usage of each partition, by adding the corresponding Partition Type UUID.
>
> This has a number of benefits, described here:
>
> https://uapi-group.org/specifications/specs/
> discoverable_partitions_specification/
>
> Besides the automation this feature affords, I find it useful to know what a 
> partition contains without having to mount it.  On GPT labelled disks I make 
> use both of the Partition Type UUID and the Partition Name.  A quick glance 
> at 
> the gdisk output and if need be its 'i' option has saved my day from 
> formatting the wrong partition more than once!  ;-)


I always use labels which show up with cgdisk.  If I'm unsure how I
partitioned a drive for some reason, I just check it with cgdisk to see
what is what.  I use labels even tho a lot of the time I put UUIDs in
fstab.  I do similar when using LVM as well. 

There is more than one way to organize things tho.  ;-) 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Michael]

On Thursday, 2 May 2024 00:45:29 BST Dale wrote:
> Grant Edwards wrote:
> > On 2024-05-01, Dale  wrote:
> >> Grant Edwards wrote:
> >>> The partition type code for 'swap' is wrong -- it should be
> >>> 8200. According to the gdisk help info Linux /home is supposed to be
> >>> 8302, but I've always used the same generic "Linux filesystem" type
> >>> for both /home and root.
> >>> 
> >>> Is the 'boot' partition for future possible UEFI use, for Linux /boot,
> >>> or both?  [I've never used a separate partition for Linux /boot, I
> >>> just use a /boot directory on the root FS.]
> >> 
> >> I noticed the other day that some new ones was added.  I always leave it
> >> as 8300 and it works.  It even works for swap.  I dunno. 

In the legacy DOS partition tables the space available was limited to 32 bits, 
while the GPT table specification provides 128 bytes for each block entry.  
The extra space can be used to store information related to the intended OS 
usage of each partition, by adding the corresponding Partition Type UUID.

This has a number of benefits, described here:

https://uapi-group.org/specifications/specs/
discoverable_partitions_specification/

Besides the automation this feature affords, I find it useful to know what a 
partition contains without having to mount it.  On GPT labelled disks I make 
use both of the Partition Type UUID and the Partition Name.  A quick glance at 
the gdisk output and if need be its 'i' option has saved my day from 
formatting the wrong partition more than once!  ;-)


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Dale]

Grant Edwards wrote:
> On 2024-05-01, Dale  wrote:
>> Grant Edwards wrote:
>>
>>> The partition type code for 'swap' is wrong -- it should be
>>> 8200. According to the gdisk help info Linux /home is supposed to be
>>> 8302, but I've always used the same generic "Linux filesystem" type
>>> for both /home and root.
>>>
>>> Is the 'boot' partition for future possible UEFI use, for Linux /boot,
>>> or both?  [I've never used a separate partition for Linux /boot, I
>>> just use a /boot directory on the root FS.]
>> I noticed the other day that some new ones was added.  I always leave it
>> as 8300 and it works.  It even works for swap.  I dunno. 
> If you have an entry in /etc/fstab for swap, it might not matter if
> the partition type is set to 'Linux swap' or not. I always set the
> swap parition type to 'Linux swap', and then it doesn't seem to matter
> if there's a swap entry in the fstab or not.

I tend to put everything in fstab.  It's the way it was when I started
and I just keep doing it that way.  It could be that it isn't needed
anymore tho. 


>> The /boot is where kernels and init thingys go.  Keep in mind, this is
>> on a old rig that has no idea what UEFI is.  When I build my new rig
>> later, I'll do a install from scratch anyway.  Also, it will go on a SSD. 
> OK, so 'boot' is for the Linux /boot directory.  I was just curious
> since I had never used one. 
>

I've used one ever since I started using Linux and it's as much habit as
anything.  Given the size of drives nowadays, I have started putting
/usr and /var on the root partition.  When I build my new rig tho, odds
are /var will be on its own partition.  That way if a log file goes
wonky, it can fill it up and not really do any harm. 


>> I mostly want to post so that a person can see the layout.  Really, the
>> first one is what a person wanting to use GPT on a old BIOS system needs
>> to see.  After that, they can do partitions anyway they want.
> Right.


I'm to the good part of the install now.  With the partition layout
shown earlier, I get this. 


(chroot) livecd / # grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.
(chroot) livecd / #


When I did that before, it puked on my keyboard.  This time with that
little unformatted partition, it just installed it.  So, muddy waters
pretty clear now.  :-D 

Dale

:-)  :-) 

[gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Grant Edwards]

On 2024-05-01, Dale  wrote:
> Grant Edwards wrote:
>
>> The partition type code for 'swap' is wrong -- it should be
>> 8200. According to the gdisk help info Linux /home is supposed to be
>> 8302, but I've always used the same generic "Linux filesystem" type
>> for both /home and root.
>>
>> Is the 'boot' partition for future possible UEFI use, for Linux /boot,
>> or both?  [I've never used a separate partition for Linux /boot, I
>> just use a /boot directory on the root FS.]
>
> I noticed the other day that some new ones was added.  I always leave it
> as 8300 and it works.  It even works for swap.  I dunno. 

If you have an entry in /etc/fstab for swap, it might not matter if
the partition type is set to 'Linux swap' or not. I always set the
swap parition type to 'Linux swap', and then it doesn't seem to matter
if there's a swap entry in the fstab or not.

> The /boot is where kernels and init thingys go.  Keep in mind, this is
> on a old rig that has no idea what UEFI is.  When I build my new rig
> later, I'll do a install from scratch anyway.  Also, it will go on a SSD. 

OK, so 'boot' is for the Linux /boot directory.  I was just curious
since I had never used one. 

> I mostly want to post so that a person can see the layout.  Really, the
> first one is what a person wanting to use GPT on a old BIOS system needs
> to see.  After that, they can do partitions anyway they want.

Right.

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Dale]

Grant Edwards wrote:
> On 2024-05-01, Dale  wrote:
>
>> OK.  One last update in case someone googles and runs up on this
>> thread.  I'm using gdisk to display this, because I think it will do
>> better in email.  If I use cgdisk, it is wider and will wrap more. 
>> This is what the partition table looks like for GPT, old BIOS and no
>> uefi thingy.  Just a straight forward and simple old school setup. 
>> Once the first one is done, the rest can be anything.
>>
>>
>> Number  Start (sector)    End (sector)  Size   Code Name
>>    1    2048 10239  4.0 MiB EF02  BIOS-boot
>>    2   10240    4204543  2.0 GiB 8300  boot
>>    3 4204544  12593151    4.0 GiB 8300  swap
>>    4    12593152    327165951   150.0 GiB   8300  root
>>    5   327165952   625141759   142.1 GiB   8300  home
> The partition type code for 'swap' is wrong -- it should be
> 8200. According to the gdisk help info Linux /home is supposed to be
> 8302, but I've always used the same generic "Linux filesystem" type
> for both /home and root.
>
> Is the 'boot' partition for future possible UEFI use, for Linux /boot,
> or both?  [I've never used a separate partition for Linux /boot, I
> just use a /boot directory on the root FS.]
>
> --
> Grant

I noticed the other day that some new ones was added.  I always leave it
as 8300 and it works.  It even works for swap.  I dunno. 

The /boot is where kernels and init thingys go.  Keep in mind, this is
on a old rig that has no idea what UEFI is.  When I build my new rig
later, I'll do a install from scratch anyway.  Also, it will go on a SSD. 

I mostly want to post so that a person can see the layout.  Really, the
first one is what a person wanting to use GPT on a old BIOS system needs
to see.  After that, they can do partitions anyway they want.  I just
hope I got it right.  Right now, I'm to the stage where I do a emerge
-auDN world.  On that old rig, may take a little bit.  It's not bad
tho.  Old rig has 6 cores now. 

Dale

:-)  :-) 

[gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Grant Edwards]

On 2024-05-01, Dale  wrote:

> OK.  One last update in case someone googles and runs up on this
> thread.  I'm using gdisk to display this, because I think it will do
> better in email.  If I use cgdisk, it is wider and will wrap more. 
> This is what the partition table looks like for GPT, old BIOS and no
> uefi thingy.  Just a straight forward and simple old school setup. 
> Once the first one is done, the rest can be anything.
>
>
> Number  Start (sector)    End (sector)  Size   Code Name
>    1    2048 10239  4.0 MiB EF02  BIOS-boot
>    2   10240    4204543  2.0 GiB 8300  boot
>    3 4204544  12593151    4.0 GiB 8300  swap
>    4    12593152    327165951   150.0 GiB   8300  root
>    5   327165952   625141759   142.1 GiB   8300  home

The partition type code for 'swap' is wrong -- it should be
8200. According to the gdisk help info Linux /home is supposed to be
8302, but I've always used the same generic "Linux filesystem" type
for both /home and root.

Is the 'boot' partition for future possible UEFI use, for Linux /boot,
or both?  [I've never used a separate partition for Linux /boot, I
just use a /boot directory on the root FS.]

--
Grant

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Dale]

Dale wrote:
> One last update.  I found a video.  They were using gdisk but the
> crucial part, he got it to display the partition layout.  It was like I
> described as for as the alignment thing, tiny partition with ef02 and
> then carry on as usual from there. 
>
> I need to do this on a disk complete with notes, so I don't forget.  My
> brain is going fast.  One day, I'll forget how to turn the puter on. 
> :'(  I already forget what I went to the kitchen for, it's only 20 feet
> away.  :/
>
> Thanks again. 
>
> Dale
>
> :-)  :-)
>


OK.  One last update in case someone googles and runs up on this
thread.  I'm using gdisk to display this, because I think it will do
better in email.  If I use cgdisk, it is wider and will wrap more.  This
is what the partition table looks like for GPT, old BIOS and no uefi
thingy.  Just a straight forward and simple old school setup.  Once the
first one is done, the rest can be anything.


Number  Start (sector)    End (sector)  Size   Code Name
   1    2048 10239  4.0 MiB EF02  BIOS-boot
   2   10240    4204543  2.0 GiB 8300  boot
   3 4204544  12593151    4.0 GiB 8300  swap
   4    12593152    327165951   150.0 GiB   8300  root
   5   327165952   625141759   142.1 GiB   8300  home


I'm about to start a fresh install on this so if it isn't right, let me
know soon.  I did make it a little larger than everyone says it needs to
be since grub does seem to grow.  That should be bigger than I'll ever
need in the lifetime of this old rig anyway. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Wol]

On 28/04/2024 17:40, Grant Edwards wrote:

On 2024-04-28, Grant Edwards  wrote:


With DOS disk lables, Grub uses empty space between the boot sector
and the first partition as a location to store it's core image file.
That empty space does not exist when using GPT disk label. When using
a GPT disk label, Grub requires that you need to create a "BIOS Boot"
or "Grub Boot" partition so that Grub has somwhere to store it's core
image[1].

And it bears repeating that the bios/grub boot partition only needs to
be 1 or 2MB in size, is _not_ formatted with a filesystem, and is
_not_ the same as either

  1) The "boot" directory where the kernel images and grubs other files
 are installed within a Linux filesystem. [Which you still need
 when booting in Legacy/BIOS mode.]

   or

  2) The UEFI partition that's formated with a FAT filesystem and used
 in UEFI boot mode [which you don't need when booting in
 Legacy/BIOS mode.]

Note that, for new installs, I generally say always create a decent 
sized partition for UEFI, so if you want to change you can, although it 
sounds like in your case it probably doesn't matter :-)



Cheers,

Wol

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Dale]

Dale wrote:
> Michael wrote:
>> On Sunday, 28 April 2024 19:39:16 BST Dale wrote:
>>> Grant Edwards wrote:
 On 2024-04-28, Grant Edwards  wrote:
> With DOS disk lables, Grub uses empty space between the boot sector
> and the first partition as a location to store it's core image file.
> That empty space does not exist when using GPT disk label. When using
> a GPT disk label, Grub requires that you need to create a "BIOS Boot"
> or "Grub Boot" partition so that Grub has somwhere to store it's core
> image[1].
 And it bears repeating that the bios/grub boot partition only needs to
 be 1 or 2MB in size, is _not_ formatted with a filesystem, and is
 _not_ the same as either

  1) The "boot" directory where the kernel images and grubs other files
  
 are installed within a Linux filesystem. [Which you still need
 when booting in Legacy/BIOS mode.]
   
   or
  
  2) The UEFI partition that's formated with a FAT filesystem and used
  
 in UEFI boot mode [which you don't need when booting in
 Legacy/BIOS mode.]
>>> I think I got a grasp on this now.  Basically, partitions should be like
>>> this. 
>>>
>>>
>>> First spot is the alignment thing.  Usually a few MBs or so and unused.
>> This is created automatically by the partitioning tool, in your case cgdisk, 
>> when you create the first partition on the disk and accept the default 
>> starting sector.
>>
>>
>>> Grub boot partition with ef02 setting, not to be formatted.
>>>
>>> /boot partition for kernel and init thingy.  Usually 1GB or so, enough
>>> for memtest, bootable rescue image etc. 
>>>
>>> / or root partition that is around 150GBs or so.  Enough to expand a bit
>>> and includes /usr and /var.
>>>
>>> /home  rest of disk unless some needed for something else.
>>>
>>>
>>> Do you recall when running grub-install what that command looks like? 
>>> Lets say the Grub partition with ef02 setting is sda1, would it be
>>> grub-install /dev/sda1 or just sda and it finds the empty partition on
>>> its own?
>> The unformatted and empty /dev/sda1 'BIOS Boot Partition' will be found by 
>> GRUB when you run grub-install and it will store its core.img in there.
>>
>> You install GRUB's boot.img in the MBR and therefore you have to specify the 
>> disk, NOT a partition, e.g.:
>>
>> grub-install /dev/sda
>>
>> This command should:
>>
>> 1. Install GRUB's boot.img in the MBR of /dev/sda.
>> 2. Install GRUB's core.img in /dev/sda1 which you created as a 'BIOS boot 
>> partition', type EF02.
>> 3. Create directory /boot/grub to install all the grub fs drivers and files.
>>
>> If you have mounted /boot, all is well.  If you are repairing an 
>> installation 
>> from a liveUSB you can mount the /boot partition, e.g. /mnt/gentoo/boot and 
>> specify this in the CLI:
>>
>> grub-install --boot-directory=/mnt/gentoo/boot /dev/sda
>>
>> NOTE:  As per the link Grant helpfully posted you can create the 'BIOS boot 
>> partition' with cgdisk "... by setting the partition type to 0xEF02 and 
>> giving 
>> it a label of gptbios".
>>
>> https://wiki.gentoo.org/wiki/GRUB#BIOS_with_GPT
>>
> That's what I was thinking.  I think I got it.  I need to make notes of
> this tho.  Before I forget.  :/ 
>
> Thanks to all.
>
> Dale
>
> :-)  :-) 
>


One last update.  I found a video.  They were using gdisk but the
crucial part, he got it to display the partition layout.  It was like I
described as for as the alignment thing, tiny partition with ef02 and
then carry on as usual from there. 

I need to do this on a disk complete with notes, so I don't forget.  My
brain is going fast.  One day, I'll forget how to turn the puter on. 
:'(  I already forget what I went to the kitchen for, it's only 20 feet
away.  :/

Thanks again. 

Dale

:-)  :-)

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Dale]

Michael wrote:
> On Sunday, 28 April 2024 19:39:16 BST Dale wrote:
>> Grant Edwards wrote:
>>> On 2024-04-28, Grant Edwards  wrote:
 With DOS disk lables, Grub uses empty space between the boot sector
 and the first partition as a location to store it's core image file.
 That empty space does not exist when using GPT disk label. When using
 a GPT disk label, Grub requires that you need to create a "BIOS Boot"
 or "Grub Boot" partition so that Grub has somwhere to store it's core
 image[1].
>>> And it bears repeating that the bios/grub boot partition only needs to
>>> be 1 or 2MB in size, is _not_ formatted with a filesystem, and is
>>> _not_ the same as either
>>>
>>>  1) The "boot" directory where the kernel images and grubs other files
>>>  
>>> are installed within a Linux filesystem. [Which you still need
>>> when booting in Legacy/BIOS mode.]
>>>   
>>>   or
>>>  
>>>  2) The UEFI partition that's formated with a FAT filesystem and used
>>>  
>>> in UEFI boot mode [which you don't need when booting in
>>> Legacy/BIOS mode.]
>> I think I got a grasp on this now.  Basically, partitions should be like
>> this. 
>>
>>
>> First spot is the alignment thing.  Usually a few MBs or so and unused.
> This is created automatically by the partitioning tool, in your case cgdisk, 
> when you create the first partition on the disk and accept the default 
> starting sector.
>
>
>> Grub boot partition with ef02 setting, not to be formatted.
>>
>> /boot partition for kernel and init thingy.  Usually 1GB or so, enough
>> for memtest, bootable rescue image etc. 
>>
>> / or root partition that is around 150GBs or so.  Enough to expand a bit
>> and includes /usr and /var.
>>
>> /home  rest of disk unless some needed for something else.
>>
>>
>> Do you recall when running grub-install what that command looks like? 
>> Lets say the Grub partition with ef02 setting is sda1, would it be
>> grub-install /dev/sda1 or just sda and it finds the empty partition on
>> its own?
> The unformatted and empty /dev/sda1 'BIOS Boot Partition' will be found by 
> GRUB when you run grub-install and it will store its core.img in there.
>
> You install GRUB's boot.img in the MBR and therefore you have to specify the 
> disk, NOT a partition, e.g.:
>
> grub-install /dev/sda
>
> This command should:
>
> 1. Install GRUB's boot.img in the MBR of /dev/sda.
> 2. Install GRUB's core.img in /dev/sda1 which you created as a 'BIOS boot 
> partition', type EF02.
> 3. Create directory /boot/grub to install all the grub fs drivers and files.
>
> If you have mounted /boot, all is well.  If you are repairing an installation 
> from a liveUSB you can mount the /boot partition, e.g. /mnt/gentoo/boot and 
> specify this in the CLI:
>
> grub-install --boot-directory=/mnt/gentoo/boot /dev/sda
>
> NOTE:  As per the link Grant helpfully posted you can create the 'BIOS boot 
> partition' with cgdisk "... by setting the partition type to 0xEF02 and 
> giving 
> it a label of gptbios".
>
> https://wiki.gentoo.org/wiki/GRUB#BIOS_with_GPT
>

That's what I was thinking.  I think I got it.  I need to make notes of
this tho.  Before I forget.  :/ 

Thanks to all.

Dale

:-)  :-) 

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Michael]

On Sunday, 28 April 2024 19:39:16 BST Dale wrote:
> Grant Edwards wrote:
> > On 2024-04-28, Grant Edwards  wrote:
> >> With DOS disk lables, Grub uses empty space between the boot sector
> >> and the first partition as a location to store it's core image file.
> >> That empty space does not exist when using GPT disk label. When using
> >> a GPT disk label, Grub requires that you need to create a "BIOS Boot"
> >> or "Grub Boot" partition so that Grub has somwhere to store it's core
> >> image[1].
> > 
> > And it bears repeating that the bios/grub boot partition only needs to
> > be 1 or 2MB in size, is _not_ formatted with a filesystem, and is
> > _not_ the same as either
> > 
> >  1) The "boot" directory where the kernel images and grubs other files
> >  
> > are installed within a Linux filesystem. [Which you still need
> > when booting in Legacy/BIOS mode.]
> >   
> >   or
> >  
> >  2) The UEFI partition that's formated with a FAT filesystem and used
> >  
> > in UEFI boot mode [which you don't need when booting in
> > Legacy/BIOS mode.]
> 
> I think I got a grasp on this now.  Basically, partitions should be like
> this. 
> 
> 
> First spot is the alignment thing.  Usually a few MBs or so and unused.

This is created automatically by the partitioning tool, in your case cgdisk, 
when you create the first partition on the disk and accept the default 
starting sector.


> Grub boot partition with ef02 setting, not to be formatted.
> 
> /boot partition for kernel and init thingy.  Usually 1GB or so, enough
> for memtest, bootable rescue image etc. 
> 
> / or root partition that is around 150GBs or so.  Enough to expand a bit
> and includes /usr and /var.
> 
> /home  rest of disk unless some needed for something else.
> 
> 
> Do you recall when running grub-install what that command looks like? 
> Lets say the Grub partition with ef02 setting is sda1, would it be
> grub-install /dev/sda1 or just sda and it finds the empty partition on
> its own?

The unformatted and empty /dev/sda1 'BIOS Boot Partition' will be found by 
GRUB when you run grub-install and it will store its core.img in there.

You install GRUB's boot.img in the MBR and therefore you have to specify the 
disk, NOT a partition, e.g.:

grub-install /dev/sda

This command should:

1. Install GRUB's boot.img in the MBR of /dev/sda.
2. Install GRUB's core.img in /dev/sda1 which you created as a 'BIOS boot 
partition', type EF02.
3. Create directory /boot/grub to install all the grub fs drivers and files.

If you have mounted /boot, all is well.  If you are repairing an installation 
from a liveUSB you can mount the /boot partition, e.g. /mnt/gentoo/boot and 
specify this in the CLI:

grub-install --boot-directory=/mnt/gentoo/boot /dev/sda

NOTE:  As per the link Grant helpfully posted you can create the 'BIOS boot 
partition' with cgdisk "... by setting the partition type to 0xEF02 and giving 
it a label of gptbios".

https://wiki.gentoo.org/wiki/GRUB#BIOS_with_GPT



signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Dale]

Grant Edwards wrote:
> On 2024-04-28, Grant Edwards  wrote:
>
>> With DOS disk lables, Grub uses empty space between the boot sector
>> and the first partition as a location to store it's core image file.
>> That empty space does not exist when using GPT disk label. When using
>> a GPT disk label, Grub requires that you need to create a "BIOS Boot"
>> or "Grub Boot" partition so that Grub has somwhere to store it's core
>> image[1].
> And it bears repeating that the bios/grub boot partition only needs to
> be 1 or 2MB in size, is _not_ formatted with a filesystem, and is
> _not_ the same as either
>
>  1) The "boot" directory where the kernel images and grubs other files
> are installed within a Linux filesystem. [Which you still need
> when booting in Legacy/BIOS mode.]
>
>   or
>
>  2) The UEFI partition that's formated with a FAT filesystem and used
> in UEFI boot mode [which you don't need when booting in
> Legacy/BIOS mode.]
>


I think I got a grasp on this now.  Basically, partitions should be like
this. 


First spot is the alignment thing.  Usually a few MBs or so and unused.

Grub boot partition with ef02 setting, not to be formatted.

/boot partition for kernel and init thingy.  Usually 1GB or so, enough
for memtest, bootable rescue image etc. 

/ or root partition that is around 150GBs or so.  Enough to expand a bit
and includes /usr and /var.

/home  rest of disk unless some needed for something else.


Do you recall when running grub-install what that command looks like? 
Lets say the Grub partition with ef02 setting is sda1, would it be
grub-install /dev/sda1 or just sda and it finds the empty partition on
its own?  That's the only thing I'm not real sure of at this point.  I
think it is sda.  Maybe. ;-)

Or is all that above just plain wrong?  O-o 

Dale

:-)  :-) 

P. S.  Been on tractor with a box blade.  Did three very long driveways
and a couple short ones.  My neighbors have smooth driveways again.  :-D 

[gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Grant Edwards]

On 2024-04-28, Grant Edwards  wrote:

> With DOS disk lables, Grub uses empty space between the boot sector
> and the first partition as a location to store it's core image file.
> That empty space does not exist when using GPT disk label. When using
> a GPT disk label, Grub requires that you need to create a "BIOS Boot"
> or "Grub Boot" partition so that Grub has somwhere to store it's core
> image[1].

And it bears repeating that the bios/grub boot partition only needs to
be 1 or 2MB in size, is _not_ formatted with a filesystem, and is
_not_ the same as either

 1) The "boot" directory where the kernel images and grubs other files
are installed within a Linux filesystem. [Which you still need
when booting in Legacy/BIOS mode.]

  or

 2) The UEFI partition that's formated with a FAT filesystem and used
in UEFI boot mode [which you don't need when booting in
Legacy/BIOS mode.]

[gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Grant Edwards]

On 2024-04-27, Michael  wrote:
> On Saturday, 27 April 2024 17:53:25 BST Dale wrote:
>> Howdy,
>> 
>> I'm installing Gentoo on another old box.  To be consistent I like
>> to use cgdisk, GPT I think it is called, to partition all my
>> drives, regardless of size.
>
> GPT is the partition table structure, which is more advanced than
> the old DOS partition table structure.
>
>> Thing is, Grub works differently with GPT than it does with the old
>> DOS or whatever it is called, like fdisk does in the old days.
>
> GRUB works the same, but the disk/partition table structure is different.

No, grub doesn't work the with GPT disk labels as it did with DOS disk
labels.

With DOS disk lables, Grub uses empty space between the boot sector
and the first partition as a location to store it's core image file.
That empty space does not exist when using GPT disk label. When using
a GPT disk label, Grub requires that you need to create a "BIOS Boot"
or "Grub Boot" partition so that Grub has somwhere to store it's core
image[1].

https://wiki.gentoo.org/wiki/GRUB#BIOS_with_GPT
https://wiki.archlinux.org/title/GRUB#BIOS_systems


[1] There is an alternative installation method where Grub will record
the disk block numbers occupied by the core image files as they
reside in the normal filesystem.  That's extra work to maintain
and might not be reliable for some filesystem types, so it's not
recommended.

[gentoo-user] Re: grub-install: warning: File system `ext2' doesn't support embedding.

[Grant Edwards]

On 2020-12-14, the...@sys-concept.com  wrote:
> On 12/13/2020 09:05 PM, Grant Edwards wrote:
>> On 2020-12-14, the...@sys-concept.com  wrote:
>> 
>>> I removed "vfat" boot partition and created/change it to ext2
>>>
>>> But now when i try to install grub:
>>>
>>> grub-install /dev/nvme0n1p2
>>> Installing for i386-pc platform.
>>> grub-install: warning: File system `ext2' doesn't support embedding.
>>> grub-install: warning: Embedding is not possible.  GRUB can only be 
>>> installed in this setup by using blocklists.  However, blocklists are 
>>> UNRELIABLE and their use is discouraged..
>>> grub-install: error: will not proceed with blocklists.
>>>
>>> Is it something that is going to create problem? 
>> 
>> If you want to install grub in an ext2 partition, you'll need to use
>> the --force option to get grub2 to use blocklists. After you've done
>> that, you need to make the critical file immutable so that it can't be
>> altered or moved:
>> 
>>  # chattr +i /boot/grub/i386-pc/core.img
>> 
>> If you ever need to update grub, you'll have to unlock that file using
>> 'chattr -i'.
>
> I don't think so.

I'm sorry I screwed up and answered the question you asked. Won't
happen again.

> I just tried made typo.
> Instead of running:
> grub-install /dev/nvme0n1
>
> I did:
> grub-install /dev/nvme0n1p2

Which told Grub to install in a partition (which is evidently an ext2
filesystem). To do that, you have to use the --force option. For that
to be reliably you have to make the core.img file immutable after you
do the installation.

Re: [gentoo-user] Re: grub-install: warning: File system `ext2' doesn't support embedding.

[thelma]

On 12/13/2020 09:05 PM, Grant Edwards wrote:
> On 2020-12-14, the...@sys-concept.com  wrote:
> 
>> I removed "vfat" boot partition and created/change it to ext2
>>
>> But now when i try to install grub:
>>
>> grub-install /dev/nvme0n1p2
>> Installing for i386-pc platform.
>> grub-install: warning: File system `ext2' doesn't support embedding.
>> grub-install: warning: Embedding is not possible.  GRUB can only be 
>> installed in this setup by using blocklists.  However, blocklists are 
>> UNRELIABLE and their use is discouraged..
>> grub-install: error: will not proceed with blocklists.
>>
>> Is it something that is going to create problem? 
> 
> If you want to install grub in an ext2 partition, you'll need to use
> the --force option to get grub2 to use blocklists. After you've done
> that, you need to make the critical file immutable so that it can't be
> altered or moved:
> 
>  # chattr +i /boot/grub/i386-pc/core.img
> 
> If you ever need to update grub, you'll have to unlock that file using
> 'chattr -i'.
> 
> --
> Grant

I don't think so. I just tried made typo.
Instead of running:
grub-install /dev/nvme0n1

I did:
grub-install /dev/nvme0n1p2

It install without any errors.

I've not done any installation for some time, a lot had changed.  It is
a good practice as next PC will be a production PC; so I know to stay
away from "vfat" in boot partition.

[gentoo-user] Re: grub-install: warning: File system `ext2' doesn't support embedding.

[Grant Edwards]

On 2020-12-14, the...@sys-concept.com  wrote:

> I removed "vfat" boot partition and created/change it to ext2
>
> But now when i try to install grub:
>
> grub-install /dev/nvme0n1p2
> Installing for i386-pc platform.
> grub-install: warning: File system `ext2' doesn't support embedding.
> grub-install: warning: Embedding is not possible.  GRUB can only be installed 
> in this setup by using blocklists.  However, blocklists are UNRELIABLE and 
> their use is discouraged..
> grub-install: error: will not proceed with blocklists.
>
> Is it something that is going to create problem? 

If you want to install grub in an ext2 partition, you'll need to use
the --force option to get grub2 to use blocklists. After you've done
that, you need to make the critical file immutable so that it can't be
altered or moved:

 # chattr +i /boot/grub/i386-pc/core.img

If you ever need to update grub, you'll have to unlock that file using
'chattr -i'.

--
Grant

Re: [gentoo-user] Re: Grub and multiple distros on LVM [was duplicate gentoo system ...]

[Jack]

On 11/26/20 8:48 AM, Neil Bothwick wrote:

On Thu, 26 Nov 2020 05:01:22 -0600, Dale wrote:

I got a message from him.  At least we will know he is OK.  All his
machines was switched to Arch Linux and he wasn't using Gentoo anymore.
So, he unsubscribed and got active with Arch.

I had a feeling that what what he had done. I can't imagine him switching
to anything else.


My two desktops are both Gentoo, but both laptops started with Arch and 
switched to Artix Linux.  That's an Arch spinoff that still supports 
openrc (and other non-systemd init systems.)  Seems a better choice for 
someone who liked the choices of Gentoo.

Re: [gentoo-user] Re: Grub and multiple distros on LVM [was duplicate gentoo system ...]

[Neil Bothwick]

On Thu, 26 Nov 2020 07:35:20 -0600, Dale wrote:

> Dare I mention hal??

Please don't :-(


-- 
Neil Bothwick

I distinctly remember forgetting that.


pgphjboaJku8G.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Grub and multiple distros on LVM [was duplicate gentoo system ...]

[Neil Bothwick]

On Thu, 26 Nov 2020 05:01:22 -0600, Dale wrote:

> I got a message from him.  At least we will know he is OK.  All his
> machines was switched to Arch Linux and he wasn't using Gentoo anymore. 
> So, he unsubscribed and got active with Arch. 

I had a feeling that what what he had done. I can't imagine him switching
to anything else.


-- 
Neil Bothwick

I'm in shape ... Rounds a shape isn't it?


pgp13E18axoCR.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Grub and multiple distros on LVM [was duplicate gentoo system ...]

[Dale]

Thomas Mueller wrote:
>> I got a message from him.  At least we will know he is OK.  All his
>> machines was switched to Arch Linux and he wasn't using Gentoo anymore. 
>> So, he unsubscribed and got active with Arch. 
>> Miss the guy but glad he is OK and nothing happened to him. 
>> Dale
>> :-)  :-) 
> When I sent this message the first time, I inadvertently forgot the Subject: 
> line, hence this repeat sending.  Sorry!
>
> When you mentioned the other Allan, I thought of Allan Gottlieb, who used to 
> be on Gentoo list.
>
> I think he was younger than me by two or three months?
>
> I believe he is the same Allan Gottlieb I met years ago at The Rockefeller 
> University when he was an (assistant? associate?) professor at CUNY in New 
> York City.
>
> I don't know if he is still living.
>
> Regarding Arch, I believe Arch Linux is mainly binary-based, rather than 
> source-based as is the case with Gentoo.
>
> In May 2013, I joined Arch Linux emailing lists, asked the question about how 
> an Arch system could be updated by building from source, as can be done with 
> FreeBSD and NetBSD.
>
> Moderator rejected that message, stating that if I looked through the wiki, I 
> could find the answer inside ten minutes, which I couldn't. 
>
> FreeBSD, NetBSD and Gentoo emailing lists are not so hostile!
>
> Not wanting to feel so tongue-tied, I unsubscribed and became an infant 
> mortality on the Arch emailing lists.
>
> This was the first and only open-source OS or distro that I rejected on 
> sociological grounds.
>
> Tom

Yea, there is some good folks on this list.  Everyone tries to help in
different ways.  If one way isn't working, someone posts a alternative
method.  Some, myself included, get upset at software sometimes tho. 
Dare I mention hal??  The -user list has always been friendly.  The -dev
list is much better now but way back, it was like walking in a field of
land mines.  At one point, I unsubbed from -dev because it was more
about people going after each other than accomplishing anything.  Now, I
monitor it again to see what is coming around the next bend.  It's a
MUCH friendlier place now. 

I was referring to Alan McKinnon.  If he even thought he had a solution,
he'd post it.  Most of the time, it was a good option.  The biggest
thing, I'm just glad he is OK. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Grub and multiple distros on LVM [was duplicate gentoo system ...]

[Thomas Mueller]

> I got a message from him.  At least we will know he is OK.  All his
> machines was switched to Arch Linux and he wasn't using Gentoo anymore. 
> So, he unsubscribed and got active with Arch. 

> Miss the guy but glad he is OK and nothing happened to him. 

> Dale

> :-)  :-) 

When I sent this message the first time, I inadvertently forgot the Subject: 
line, hence this repeat sending.  Sorry!

When you mentioned the other Allan, I thought of Allan Gottlieb, who used to be 
on Gentoo list.

I think he was younger than me by two or three months?

I believe he is the same Allan Gottlieb I met years ago at The Rockefeller 
University when he was an (assistant? associate?) professor at CUNY in New York 
City.

I don't know if he is still living.

Regarding Arch, I believe Arch Linux is mainly binary-based, rather than 
source-based as is the case with Gentoo.

In May 2013, I joined Arch Linux emailing lists, asked the question about how 
an Arch system could be updated by building from source, as can be done with 
FreeBSD and NetBSD.

Moderator rejected that message, stating that if I looked through the wiki, I 
could find the answer inside ten minutes, which I couldn't. 

FreeBSD, NetBSD and Gentoo emailing lists are not so hostile!

Not wanting to feel so tongue-tied, I unsubscribed and became an infant 
mortality on the Arch emailing lists.

This was the first and only open-source OS or distro that I rejected on 
sociological grounds.

Tom

Re: [gentoo-user] Re: Grub and multiple distros on LVM [was duplicate gentoo system ...]

[Dale]

Dale wrote:
> Peter Humphrey wrote:
>> On Wednesday, 25 November 2020 15:20:41 GMT Dale wrote:
>>
>>> P. S.  I been meaning to ask this for ages now.  What happened to our
>>> other Allan?  I think he was from Africa or something and admin'd a
>>> bunch of puters there.  McKinnon or something like that was the past
>>> name.  I haven't seen him post in a long time.  I hope he is OK and all. 
>> Yes, me too. South Africa, wasn't it? Perhaps a telecomms utility, though 
>> that's a guess.
>>
>> I just assumed he'd finally grown tired of all us cloth-heads...
>>
>
> The last message I can find from him was in February of 2018.  I'm gonna
> try to send a message direct.  See if he responds. 
>
> Dale
>
> :-)  :-) 
>


I got a message from him.  At least we will know he is OK.  All his
machines was switched to Arch Linux and he wasn't using Gentoo anymore. 
So, he unsubscribed and got active with Arch. 

Miss the guy but glad he is OK and nothing happened to him. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Grub and multiple distros on LVM [was duplicate gentoo system ...]

[antlists]

On 25/11/2020 23:03, Neil Bothwick wrote:

On Wed, 25 Nov 2020 19:37:32 - (UTC), Grant Edwards wrote:


I'm not sure chainloading would work as that requires a drive
definition from which to load the boot sector.


I thought that's what LVM provided was a drive definition.


It's more like a partition definition, GRUB requires the boot
sector/MBR of a whole drive.


I'm asking about chainloading. Grub has already been loaded via MBR
and grub's partition (which can be a normal physical partition if
needed). Grub is now running and displaying its menu. Each of the menu
entries instructs grub to load the first sector of a specified
partition into RAM and execute it. That sector can contain grub, LILO,
windows boot manager, whatever.  If grub understands LVM volumes, then
can it read that first sector from an LVM volume instead of a physical
partition?


I think the only way to find out is to try it, but my gut feeling about
this is not good. However, I'd be happy for my gut to be proved wrong.


Well, it should be able to do it with raid (you can partition an md-raid 
volume), so maybe the same with LVM?


Cheers,
Wol

Re: [gentoo-user] Re: Grub and multiple distros on LVM [was duplicate gentoo system ...]

[Neil Bothwick]

On Wed, 25 Nov 2020 19:37:32 - (UTC), Grant Edwards wrote:

> >> > I'm not sure chainloading would work as that requires a drive
> >> > definition from which to load the boot sector.
> >> 
> >> I thought that's what LVM provided was a drive definition.  
> >
> > It's more like a partition definition, GRUB requires the boot
> > sector/MBR of a whole drive.  
> 
> I'm asking about chainloading. Grub has already been loaded via MBR
> and grub's partition (which can be a normal physical partition if
> needed). Grub is now running and displaying its menu. Each of the menu
> entries instructs grub to load the first sector of a specified
> partition into RAM and execute it. That sector can contain grub, LILO,
> windows boot manager, whatever.  If grub understands LVM volumes, then
> can it read that first sector from an LVM volume instead of a physical
> partition?

I think the only way to find out is to try it, but my gut feeling about
this is not good. However, I'd be happy for my gut to be proved wrong.


-- 
Neil Bothwick

Confucius say :
He who play in root, eventually kill tree!


pgp9TnIacKs6a.pgp
Description: OpenPGP digital signature

[gentoo-user] Re: Grub and multiple distros on LVM [was duplicate gentoo system ...]

[Grant Edwards]

On 2020-11-25, Neil Bothwick  wrote:
> On Wed, 25 Nov 2020 16:04:26 - (UTC), Grant Edwards wrote:
>
>> > I'm not sure chainloading would work as that requires a drive
>> > definition from which to load the boot sector.  
>> 
>> I thought that's what LVM provided was a drive definition.
>
> It's more like a partition definition, GRUB requires the boot sector/MBR
> of a whole drive.

I'm asking about chainloading. Grub has already been loaded via MBR
and grub's partition (which can be a normal physical partition if
needed). Grub is now running and displaying its menu. Each of the menu
entries instructs grub to load the first sector of a specified
partition into RAM and execute it. That sector can contain grub, LILO,
windows boot manager, whatever.  If grub understands LVM volumes, then
can it read that first sector from an LVM volume instead of a physical
partition?

--
Grant

Re: [gentoo-user] Re: Grub and multiple distros on LVM [was duplicate gentoo system ...]

[Neil Bothwick]

On Wed, 25 Nov 2020 16:04:26 - (UTC), Grant Edwards wrote:

> > I'm not sure chainloading would work as that requires a drive
> > definition from which to load the boot sector.  
> 
> I thought that's what LVM provided was a drive definition.

It's more like a partition definition, GRUB requires the boot sector/MBR
of a whole drive.


-- 
Neil Bothwick

Bug: (n.) any program feature not yet described to the marketing
department.


pgp6P9LObFzRX.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Grub and multiple distros on LVM [was duplicate gentoo system ...]

[Dale]

Peter Humphrey wrote:
> On Wednesday, 25 November 2020 15:20:41 GMT Dale wrote:
>
>> P. S.  I been meaning to ask this for ages now.  What happened to our
>> other Allan?  I think he was from Africa or something and admin'd a
>> bunch of puters there.  McKinnon or something like that was the past
>> name.  I haven't seen him post in a long time.  I hope he is OK and all. 
> Yes, me too. South Africa, wasn't it? Perhaps a telecomms utility, though 
> that's a guess.
>
> I just assumed he'd finally grown tired of all us cloth-heads...
>


The last message I can find from him was in February of 2018.  I'm gonna
try to send a message direct.  See if he responds. 

Dale

:-)  :-) 

[gentoo-user] Re: Grub and multiple distros on LVM [was duplicate gentoo system ...]

[Grant Edwards]

On 2020-11-25, Neil Bothwick  wrote:
> On Wed, 25 Nov 2020 15:20:04 - (UTC), Grant Edwards wrote:
>
>> > "GRUB 2 can read files directly from LVM and RAID devices."  
>> 
>> That was certainly the behavior described [...]
>> 
>> But that relys on the assumption that the distros all run compatible
>> versions of Grub2.  What I was wondering was whether normal
>> chainloading would work (which wouldn't rely on that assumption).
>
> I would expect all versions of GRUB2 to use the same config syntax.
> Changing the syntax between versions could mean an update rendering the
> computer unbootable, which we would probably have heard about.

In some comments about the multiple-distro setups there were rather
vague references to occasional syntax problems between different
distro's versions of grub. I don't know if it was due a change that
was introduced upstream when grub was updated or some sort of RedHat
custom-feature-backporting-bastardization.

> I'm not sure chainloading would work as that requires a drive
> definition from which to load the boot sector.

I thought that's what LVM provided was a drive definition.

--
Grant

Re: [gentoo-user] Re: Grub and multiple distros on LVM [was duplicate gentoo system ...]

[Peter Humphrey]

On Wednesday, 25 November 2020 15:20:41 GMT Dale wrote:

> P. S.  I been meaning to ask this for ages now.  What happened to our
> other Allan?  I think he was from Africa or something and admin'd a
> bunch of puters there.  McKinnon or something like that was the past
> name.  I haven't seen him post in a long time.  I hope he is OK and all. 

Yes, me too. South Africa, wasn't it? Perhaps a telecomms utility, though 
that's a guess.

I just assumed he'd finally grown tired of all us cloth-heads...

-- 
Regards,
Peter.

Re: [gentoo-user] Re: Grub and multiple distros on LVM [was duplicate gentoo system ...]

[Neil Bothwick]

On Wed, 25 Nov 2020 15:20:04 - (UTC), Grant Edwards wrote:

> > "GRUB 2 can read files directly from LVM and RAID devices."  
> 
> That was certainly the behavior described by the examples documented
> by people who were using grub to boot multiple partitions by having a
> master copy of grub with a menu that would then boot selected distros
> installed within LVM volumes by having each of the master menu entries
> load a new "distro" .cfg file from that LVM volume (each of the LVM
> volume's .cfg file was maintained by the distro package manager).
> 
> But that relys on the assumption that the distros all run compatible
> versions of Grub2.  What I was wondering was whether normal
> chainloading would work (which wouldn't rely on that assumption).

I would expect all versions of GRUB2 to use the same config syntax.
Changing the syntax between versions could mean an update rendering the
computer unbootable, which we would probably have heard about.

I'm not sure chainloading would work as that requires a drive definition
from which to load the boot sector.


-- 
Neil Bothwick

WINDOWS: Will Install Needless Data On Whole System


pgpFurz56unWZ.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Grub and multiple distros on LVM [was duplicate gentoo system ...]

[Dale]

Neil Bothwick wrote:
> On Wed, 25 Nov 2020 08:53:02 +, Wols Lists wrote:
>
>> I *think* the grub volume itself has to be plain, no lvm, mdadm etc. All
>> the stuff for that is in the initramfs, so grub loads the initramfs,
>> starts the kernel, the kernel starts pid 1 which can now start mdadm,
>> lvm etc, and then it can pivot root onto the proper root filesystem.
> That was my thinking, that the kernel/initramfs was reading the LVs but
> Grant mentioned the lvm module for GRUB so I broke the habit of a
> lifetime and read the man page :-O
>
> "GRUB 2 can read files directly from LVM and RAID devices."
>
>


That makes it sound like /boot could be on LVM to me.  That sound right
to you?  If so, I'd bet /, root, could be on LVM and grub be able to
boot without a lot of extra effort.  It may even do so without a init
thingy, if one doesn't need it. 

If that is all doable, almost makes me want to move my OS to a new drive
and use LVM for everything.  That would be really nice.  Might be the
best thing since sliced bread and frozen pizza.  ROFL

Dale

:-)  :-) 

P. S.  I been meaning to ask this for ages now.  What happened to our
other Allan?  I think he was from Africa or something and admin'd a
bunch of puters there.  McKinnon or something like that was the past
name.  I haven't seen him post in a long time.  I hope he is OK and all. 

[gentoo-user] Re: Grub and multiple distros on LVM [was duplicate gentoo system ...]

[Grant Edwards]

On 2020-11-25, Neil Bothwick  wrote:
> On Wed, 25 Nov 2020 08:53:02 +, Wols Lists wrote:
>
>> >>> I suspect not as GRUB will be reading the menu files and GRUB
>> >>> doesn't read from LVM volumes.
>> >>
>> >> Then what does grub's "lvm" module do, and how does it read the
>> >> distro's .cfg files from the LVM volumes in which the various distros
>> >> are installed?  
>
> That was my thinking, that the kernel/initramfs was reading the LVs but
> Grant mentioned the lvm module for GRUB so I broke the habit of a
> lifetime and read the man page :-O
>
> "GRUB 2 can read files directly from LVM and RAID devices."

That was certainly the behavior described by the examples documented
by people who were using grub to boot multiple partitions by having a
master copy of grub with a menu that would then boot selected distros
installed within LVM volumes by having each of the master menu entries
load a new "distro" .cfg file from that LVM volume (each of the LVM
volume's .cfg file was maintained by the distro package manager).

But that relys on the assumption that the distros all run compatible
versions of Grub2.  What I was wondering was whether normal
chainloading would work (which wouldn't rely on that assumption).

--
Grant

Re: [gentoo-user] Re: Grub and multiple distros on LVM [was duplicate gentoo system ...]

[Neil Bothwick]

On Wed, 25 Nov 2020 08:53:02 +, Wols Lists wrote:

> >>> I suspect not as GRUB will be reading the menu files and GRUB
> >>> doesn't read from LVM volumes.
> >>
> >> Then what does grub's "lvm" module do, and how does it read the
> >> distro's .cfg files from the LVM volumes in which the various distros
> >> are installed?  
> > 
> > Maybe what you want. I haven't used LVM or GRUB much n the past
> > several years, so maybe it is OK now, although a quick web search
> > before I posted implied it wasn't. RTFM time?
> > 
> >   
> I *think* the grub volume itself has to be plain, no lvm, mdadm etc. All
> the stuff for that is in the initramfs, so grub loads the initramfs,
> starts the kernel, the kernel starts pid 1 which can now start mdadm,
> lvm etc, and then it can pivot root onto the proper root filesystem.

That was my thinking, that the kernel/initramfs was reading the LVs but
Grant mentioned the lvm module for GRUB so I broke the habit of a
lifetime and read the man page :-O

"GRUB 2 can read files directly from LVM and RAID devices."


-- 
Neil Bothwick

Top Oxymorons Number 6: Pretty ugly


pgpXuHEL08CK5.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Grub and multiple distros on LVM [was duplicate gentoo system ...]

[Wols Lists]

On 24/11/20 23:39, Neil Bothwick wrote:
> On Tue, 24 Nov 2020 23:25:38 - (UTC), Grant Edwards wrote:
> 
 In grub, does chainloading an LVM virtual partition work the same as
 chainloading a "real" partition?  
>>>
>>> I suspect not as GRUB will be reading the menu files and GRUB doesn't
>>> read from LVM volumes.  
>>
>> Then what does grub's "lvm" module do, and how does it read the
>> distro's .cfg files from the LVM volumes in which the various distros
>> are installed?
> 
> Maybe what you want. I haven't used LVM or GRUB much n the past several
> years, so maybe it is OK now, although a quick web search before I posted
> implied it wasn't. RTFM time?
> 
> 
I *think* the grub volume itself has to be plain, no lvm, mdadm etc. All
the stuff for that is in the initramfs, so grub loads the initramfs,
starts the kernel, the kernel starts pid 1 which can now start mdadm,
lvm etc, and then it can pivot root onto the proper root filesystem.

Cheers,
Wol

Re: [gentoo-user] Re: Grub and multiple distros on LVM [was duplicate gentoo system ...]

[Neil Bothwick]

On Tue, 24 Nov 2020 23:25:38 - (UTC), Grant Edwards wrote:

> >> In grub, does chainloading an LVM virtual partition work the same as
> >> chainloading a "real" partition?  
> >
> > I suspect not as GRUB will be reading the menu files and GRUB doesn't
> > read from LVM volumes.  
> 
> Then what does grub's "lvm" module do, and how does it read the
> distro's .cfg files from the LVM volumes in which the various distros
> are installed?

Maybe what you want. I haven't used LVM or GRUB much n the past several
years, so maybe it is OK now, although a quick web search before I posted
implied it wasn't. RTFM time?


-- 
Neil Bothwick

After all is said and done let there not be more said than done.


pgplqXceJjpzT.pgp
Description: OpenPGP digital signature

[gentoo-user] Re: Grub and multiple distros on LVM [was duplicate gentoo system ...]

[Grant Edwards]

On 2020-11-24, Neil Bothwick  wrote:
> On Tue, 24 Nov 2020 19:04:20 - (UTC), Grant Edwards wrote:
>
>> In grub, does chainloading an LVM virtual partition work the same as
>> chainloading a "real" partition?
>
> I suspect not as GRUB will be reading the menu files and GRUB doesn't
> read from LVM volumes.

Then what does grub's "lvm" module do, and how does it read the
distro's .cfg files from the LVM volumes in which the various distros
are installed?

--
Grant

[gentoo-user] Re: Grub problems on old proliant

[mad.scientist.at.large]

sorry, it was silly of me to try to install one grub on top of another.  
managed to foul up grub, putting secondary os back in so i can do it right.  
hopefully i can just update grub manually.

mad.scientist.at.large (a good madscientist)
--
God bless the rich, the greedy and the corrupt politicians they have put into 
office.   God bless them for helping me do the right thing by giving the rich 
my little pile of cash.  After all, the rich know what to do with money.


22. Mar 2018 16:57 by mad.scientist.at.la...@tutanota.com 
:


> When I run "grub-install/dev/boot" (following the manual) I i get the error 
> "grub-install: error: cannot find a GRUB for /dev/boot.  Check your device 
> map"  I looked at the /boot partition and there is no device map.  
>
> I'm installing gentoo running debian.  I have another os so the boot 
> partition should be properly set up.  This is on an ancient hp proliant 
> dl385, Gen 1.  debian is running grub 2.02~beta3-5.  This machine does not 
> use uefi, and the raid driver is in the kernel.
>
>  Do i need to hack together the device map or?  Any help appreciated, thank 
> you.  
>
> Unfortunately i'm more familiar with grub legacy than grub2, studying manual 
> now (it's very verbose and takes a bit to absorb enough to use it.
>
> mad.scientist.at.large (a good madscientist)
> --
> God bless the rich, the greedy and the corrupt politicians they have put into 
> office.   God bless them for helping me do the right thing by giving the rich 
> my little pile of cash.  After all, the rich know what to do with money.
>

[gentoo-user] Re: grub-0.97-r16 and profile 17.0 change

[Ian Zimmerman]

On 2017-12-04 18:13, Daniel Frey wrote:

> I guess I'll have to remember to use 500M+ /boot partitions now. Sigh.

I don't get it.

 matica!7 rc$ du /boot/grub
2022/boot/grub/i386-pc
1340/boot/grub/fonts
2785/boot/grub/themes/starfield
2786/boot/grub/themes
3163/boot/grub/locale
9317/boot/grub

~10MB.  This is with grub2.

Maybe you use some heavily graphical theme?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

Re: [gentoo-user] Re: grub-0.97-r16 and profile 17.0 change

[Michael Orlitzky]

On 12/02/2017 09:18 PM, Ian Zimmerman wrote:
>>
>> You do need to run "emerge -e @world", unless you happened to be using
>> a hardened toolchain already.
> 
> But only if you in fact switch the new profile on, right?

Right.


> There seems to be another thing afoot, though.  All (or nearly so)
> python libraries are due for rebuild because of
> 
> PYTHON_TARGETS="python3_5 -python3_4"
> 
> Where does that come from?  I have never fully understood this and
> similar variables.  It seems to be kind of like USE but also separate
> from USE.  Is it something I can control, as a user?  Where is it
> configured?  Is this change tied to the above profile transition?

Totally unrelated. PYTHON_TARGETS is a so-called USE_EXPAND variable:

  https://wiki.gentoo.org/wiki/Project:Python/PYTHON_TARGETS

It is precisely a bunch of plain-old USE flags under the hood, with a
little bit of syntactic sugar on top so that you can set e.g.

  PYTHON_TARGETS=python3_5

instead of

  USE=python_targets_python3_5

In other words, it automatically namespaces a set of related USE flags.

All of the python stuff is rebuilding because (I guess) the python team
stabilized python-3.5. As a result, you're going to install python-3.5,
and therefore need to rebuild all of your python packages with support
for python-3.5.

[gentoo-user] Re: grub-0.97-r16 and profile 17.0 change

[Ian Zimmerman]

On 2017-12-02 20:14, Michael Orlitzky wrote:

> >> You're seeing a lot of reports because there is a news item telling
> >> people to switch to the new profile and run "emerge -e @world".
> > 
> > Does this mean that "emerge -e @world" should be run or that the
> > news item is wrong in this point?
> 
> You do need to run "emerge -e @world", unless you happened to be using
> a hardened toolchain already.

But only if you in fact switch the new profile on, right?

There seems to be another thing afoot, though.  All (or nearly so)
python libraries are due for rebuild because of

PYTHON_TARGETS="python3_5 -python3_4"

Where does that come from?  I have never fully understood this and
similar variables.  It seems to be kind of like USE but also separate
from USE.  Is it something I can control, as a user?  Where is it
configured?  Is this change tied to the above profile transition?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

Re: [gentoo-user] Re: grub-0.97-r16 and profile 17.0 change

[Adam Carter]

> * Select the new profile with eselect
> * Re-emerge, in this sequence, gcc, binutils, and glibc
> emerge -1 sys-devel/gcc:6.4.0
> emerge -1 sys-devel/binutils
> emerge -1 sys-libs/glibc
> * Rebuild your entire system
> emerge -e @world
>

Would emerge -e --exclude gcc --exclude bintuils --exclude glibc @world be
a little more sensible?

Re: [gentoo-user] Re: grub-0.97-r16 and profile 17.0 change

[Michael Orlitzky]

On 12/02/2017 08:07 PM, Heiko Baums wrote:
> Am Sat, 2 Dec 2017 18:33:09 -0500
> schrieb Michael Orlitzky :
> 
>> You're seeing a lot of reports because there is a news item telling
>> people to switch to the new profile and run "emerge -e @world".
> 
> Does this mean that "emerge -e @world" should be run or that the news
> item is wrong in this point?

You do need to run "emerge -e @world", unless you happened to be using a
hardened toolchain already.

So the news item is correct, but having everyone build test the whole
tree at once is unearthing some latent build system bugs.

Re: [gentoo-user] Re: grub-0.97-r16 and profile 17.0 change

[Heiko Baums]

Am Sat, 2 Dec 2017 18:33:09 -0500
schrieb Michael Orlitzky :

> You're seeing a lot of reports because there is a news item telling
> people to switch to the new profile and run "emerge -e @world".

Does this mean that "emerge -e @world" should be run or that the news
item is wrong in this point?

Heiko

Re: [gentoo-user] Re: grub-0.97-r16 and profile 17.0 change

[Michael Orlitzky]

On 12/02/2017 04:28 PM, Ian Zimmerman wrote:
> This profile change seems to have hit a few people in sensitive
> locations.
> 
> What is the upshot of this change?  Can I eyeball the diff _before_ I
> sync ?
> 

The new 17.0 profile switches the default C++ version to C++14, and
enables PIE/SSP by default with real upstream support for those
features. As a result, it requires gcc-6.x. Most build failures are due
to that -- basically ancient stable versions that never got tested with
a modern compiler/features until now.

Syncing is safe, nothing bad will happen unless you `eselect profile`
one of the new 17.0 profiles.

You're seeing a lot of reports because there is a news item telling
people to switch to the new profile and run "emerge -e @world".

Re: [gentoo-user] Re: grub-0.97-r16 and profile 17.0 change

[Mick]

On 02-12-2017 ,13:28:37, Ian Zimmerman wrote:
> This profile change seems to have hit a few people in sensitive
> locations.
> 
> What is the upshot of this change?  Can I eyeball the diff _before_ I
> sync ?

This is what the news item states:
=
~ $ eselect news read new
2017-11-30-new-17-profiles
  Title New 17.0 profiles in the Gentoo repository
  AuthorAndreas K. Hüttel 
  Posted2017-11-30
  Revision  1

We have just added (for all arches except arm and mips, these follow
later) a new set of profiles with release version 17.0 to the Gentoo
repository. These bring three changes:
1) The default C++ language version for applications is now C++14.
   This change is mostly relevant to Gentoo developers. It also
   means, however, that compilers earlier than GCC 6 are masked
   and not supported for use as a system compiler anymore. Feel
   free to unmask them if you need them for specific applications.
2) Where supported, GCC will now build position-independent
   executables (PIE) by default. This improves the overall
   security fingerprint. The switch from non-PIE to PIE binaries,
   however, requires some steps by users, as detailed below.
3) Up to now, hardened profiles were separate from the default
   profile tree. Now they are moving into the 17.0 profile
   as a feature there, similar to "no-multilib" and "systemd".

Please migrate away from the 13.0 profiles within the six weeks after
GCC 6.4.0 has been stabilized on your architecture. The 13.0 profiles
will be deprecated then and removed in half a year.

If you are not already running a hardened setup with PIE enabled, then
switching the profile involves the following steps:
If not already done,
* Use gcc-config to select gcc-6.4.0 or later as system compiler
* Re-source /etc/profile:
. /etc/profile
* Re-emerge libtool
emerge -1 sys-devel/libtool
Then,
* Select the new profile with eselect
* Re-emerge, in this sequence, gcc, binutils, and glibc
emerge -1 sys-devel/gcc:6.4.0
emerge -1 sys-devel/binutils
emerge -1 sys-libs/glibc
* Rebuild your entire system
emerge -e @world

Switching the profile from 13.0 to 17.0 modifies the settings of
GCC 6 to generate PIE executables by default; thus, you need to do
the rebuilds even if you have already used GCC 6 beforehand.
If you do not follow these steps you may get spurious build
failures when the linker tries unsuccessfully to combine non-PIE
and PIE code.

[gentoo-user] Re: grub-0.97-r16 and profile 17.0 change

[Ian Zimmerman]

This profile change seems to have hit a few people in sensitive
locations.

What is the upshot of this change?  Can I eyeball the diff _before_ I
sync ?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

[gentoo-user] Re: grub error I've never seen in many installs

[Harry Putnam]

Hinnerk van Bruinehsen  writes:

>> Has something changed regarding using that kind of technique?
>> 
>> I can't figure out why grub would be looking for a GRUB drive on
>> /dev/sda1 as the error says:
>> 
>>   grub-install: error: cannot find a GRUB drive for /dev/sda1
>
>
> Did you mount /boot from inside the chroot environment? IIRC I got a
> similar failure when mounting /boot from outside the chroot...

Egad, that is almost certainly what is going on.

However, before seeing your post I came up with what I thought might
be a way to get around the whole problem presented in the errors.

I preserved my install on the initial disk created in vbox for the
install.

Shutdown the vbox vm, created a set of new disks but this time using
whole disks rather than carving up partitions.

So instead of 1 disk carved up... I now had 4 disks in the same sizes
as the original partitions.

Booted the install media.. copied the installed OS over to the new
disks.  But this time I was asking grub to intall itself on a disk
with a single whole disk partition.

It all worked, ... but I think now, after your comment, I probably
mounted boot in the proscribed way this time around.  That is, from
inside a chrooted terminal.

Probably didn't need all the disk switching and copying at all.

Thanks for your input...

I'll know not to think I remember all about how to do this and pay
more attention to the install instructions. Even though I have done
this quite a few times... its usually been separated by along enough
time period that I might will have forgotten some of the necessary
steps.

Thanks again for taking time to post your thoughts.

Re: [gentoo-user] Re: grub error I've never seen in many installs

[Hinnerk van Bruinehsen]

On Wed, Jul 12, 2017 at 05:57:58PM -0400, Harry Putnam wrote:
> Arve Barsnes  writes:
> 
> > On 10 July 2017 at 22:06, Harry Putnam  wrote:
> >
> >>  grub-install /dev/sda Installing for i386-pc platform.
> >> grub-install: error: cannot find a GRUB drive for /dev/sda1.  Check
> >> your device.map.
> >>
> >> Where might I find `device.map'... it isn't part of grub2.  At least
> >> grep doesn't find it with `qlist grub'
> >>
> >
> > As far as I understand it, grub2 will dynamically create the device.map
> > when it needs it, so it doesn't actually exist as a file. On my grub legacy
> > system it is installed as /boot/grub/device.map, with the only contents
> > being "(hd0)   /dev/sda".
> >
> > How you would feed grub this information *before* it is installed I'm not
> > sure, but maybe look into the USE=device-mapper flag, maybe it installs the
> > grub-mkdevicemap executable.
> 
> Yeah, I tried that before posting.. setting USE=device-mapper then
> reinstalled grub2... same result as without the flag.  Same error
> message.
> 
> I've always .. on many installs (over time) and mostly into a vbox vm,
> created a disk, then when booting the install media I carve it up with
> fdisk.
> /dev/sda1=boot
> /dev/sda2=swap
> /dev/sda3=home
> /dev/sda4=/
> 
> Has something changed regarding using that kind of technique?
> 
> I can't figure out why grub would be looking for a GRUB drive on
> /dev/sda1 as the error says:
> 
>   grub-install: error: cannot find a GRUB drive for /dev/sda1


Did you mount /boot from inside the chroot environment? IIRC I got a
similar failure when mounting /boot from outside the chroot...

[gentoo-user] Re: grub error I've never seen in many installs

[Harry Putnam]

Arve Barsnes  writes:

> On 10 July 2017 at 22:06, Harry Putnam  wrote:
>
>>  grub-install /dev/sda Installing for i386-pc platform.
>> grub-install: error: cannot find a GRUB drive for /dev/sda1.  Check
>> your device.map.
>>
>> Where might I find `device.map'... it isn't part of grub2.  At least
>> grep doesn't find it with `qlist grub'
>>
>
> As far as I understand it, grub2 will dynamically create the device.map
> when it needs it, so it doesn't actually exist as a file. On my grub legacy
> system it is installed as /boot/grub/device.map, with the only contents
> being "(hd0)   /dev/sda".
>
> How you would feed grub this information *before* it is installed I'm not
> sure, but maybe look into the USE=device-mapper flag, maybe it installs the
> grub-mkdevicemap executable.

Yeah, I tried that before posting.. setting USE=device-mapper then
reinstalled grub2... same result as without the flag.  Same error
message.

I've always .. on many installs (over time) and mostly into a vbox vm,
created a disk, then when booting the install media I carve it up with
fdisk.
/dev/sda1=boot
/dev/sda2=swap
/dev/sda3=home
/dev/sda4=/

Has something changed regarding using that kind of technique?

I can't figure out why grub would be looking for a GRUB drive on
/dev/sda1 as the error says:

  grub-install: error: cannot find a GRUB drive for /dev/sda1

Re: [gentoo-user] Re: grub:2 first experience with it

[Neil Bothwick]

On Thu, 16 Feb 2017 21:05:11 -0500, Harry Putnam wrote:

> > You're supposed to use a video= parameter but I find the old school
> > vga=794 works for me. The thing you have to learn with using GRUB, or
> > at least when using grub-mkconfig, is that you don't edit grub.cfg
> > but /etc/default/grub when you want to add kernel parameters.  
> 
> What does vga=794 get you?
> 
> I've used `vga=0x31b video=vesfb:mtrr:3,ywrap' with grub:0 a few yrs
> and get a nice size (1280x1024x32 [I think])

vga=794 gets you the same but in 16 bit, I find 65000 colours is enough
for bash :-) 0x31b is 795, but I tend to remember those codes in decimal,
however much it hurts my geek cred.


-- 
Neil Bothwick

"Facts are stubborn things, but statistics are more pliable."
  - Mark Twain


pgpG5zbOWZnTx.pgp
Description: OpenPGP digital signature

[gentoo-user] Re: grub:2 first experience with it

[Harry Putnam]

Neil Bothwick  writes:

> You're supposed to use a video= parameter but I find the old school
> vga=794 works for me. The thing you have to learn with using GRUB, or at
> least when using grub-mkconfig, is that you don't edit grub.cfg
> but /etc/default/grub when you want to add kernel parameters.

What does vga=794 get you?

I've used `vga=0x31b video=vesfb:mtrr:3,ywrap' with grub:0 a few yrs
and get a nice size (1280x1024x32 [I think]) console but that requires
kernel settings Graphic drivers -> Frame buffer Devices ->

│ │<*> VGA 16-color graphics support
│ │[*] VESA VGA graphics support

I'm not sure if you need the VGA one but definitely the vesa and from
what I read digging around about KMS, you cannot select drivers
under Frame buffer devices if you want to use KMS .. only the ones
under Console Display Driver Support (a bit further down in make
menuconfig)

Re: [gentoo-user] Re: grub:2 first experience with it

[Neil Bothwick]

On Thu, 16 Feb 2017 15:20:25 -0500, Harry Putnam wrote:

> What can you tell me about how to get an initial hi-res frame buffer
> during boot and after when in console mode?

KMS takes care of that with real hardware, but not so much with virtual
hardware.
 
> I know how to do it in grub:0.  But I see my first feeble attempt in
> grub:2 was total non-starter.

You're supposed to use a video= parameter but I find the old school
vga=794 works for me. The thing you have to learn with using GRUB, or at
least when using grub-mkconfig, is that you don't edit grub.cfg
but /etc/default/grub when you want to add kernel parameters.


-- 
Neil Bothwick

Employ teenagers - while they know everything.


pgpa65ZIyCfV3.pgp
Description: OpenPGP digital signature

[gentoo-user] Re: grub:2 first experience with it

[Harry Putnam]

Neil Bothwick  writes:

>> But no update-grub
>
> update-grub is an Ubuntuism, not part of standard GRUB. It's only a one
> line shell script that runs
>
> grub-mkconfig -o /boot/grub/grub.cfg
>
> Even a large proportion of Ubuntu users would be able to manage without
> it.

yeah, I saw once I looked at the script that it was just little
wrapper.

But I'm pretty sure that somewhere in all the gentoo stuff I was using
there is a little bit that says to run update-grub.

So not knowing anything about what it might do it seemed like
something was wrong.

But you are dead right that it ain't much... and certainly not a deal
breaker.

What can you tell me about how to get an initial hi-res frame buffer
during boot and after when in console mode?

I know how to do it in grub:0.  But I see my first feeble attempt in
grub:2 was total non-starter.

[gentoo-user] Re: grub-2 update

[James]

Steven Lembark lembark at wrkhors.com writes:


 Solution that works for me:

  - Compile the kernel with everything built-in leaving modules for the 
few things that really need to be reloadable. Turn everything in 
the bloody thing off. This avoids the need for a kernel-specific
filestem in the initrd.

I have to prune your posting per Gmane rules of brevity.

  - This since you don't need any modules in the initrd a 
simple, static solution with busybox and init something
like:

I like what you have posted, very much.

  - Run grub2-mkconfig once. 

  - Never touch the grub.cfg file ever again (unless you switch the
boot filesystem type). If I went from XFS - btrfs for the root
filesystem I'd have to hack the insmod xfs entries, nothing
more. 


I'm not ready to use this on my main system, atm. However, I have
been contemplating a new level of (gentoo) install that is less
than a default (basic) install with a reduced number of packages.
I even have decided to put all the tools (codes, packages etc)
onto a separate partition (usb stick) related to compiling. 
The idea is to build up from scratch what is needed; with a verified
DAG of the installed system. Your approach to kernel and boot management
is something I'm going to have to experiment with a bit before 
confidence would allow me to put this idea into my critical path.

I am very fascinated by your approach. It does look a wee bit like
bootstrapping a LFS or openVZ system. Do you have some resources for
recommended reading?

Do you use this in a virtualized approach to system management?


curiously,
James

[gentoo-user] Re: grub-2 update

[James]

Neil Bothwick neil at digimed.co.uk writes:


  So if I do this, what will I have to do to keep the system booting.

 Nothing, I installed r7 on June 26th and the system just kept booting.

 You can run grub-install if you really want to, but as this is a patch
 level update to the same version, the MBR code is likely to be the same
 anyway.


OKI'll give it a shot.

thx,
James

Re: [gentoo-user] Re: grub-2 update

[wraeth]

On Fri, Jul 17, 2015 at 08:36:51AM +0100, Neil Bothwick wrote:
 could try it on. But it's a headless MythTV backend in the loft, so
 there will be fun and games if it doesn't boot. 

Wouldn't it be more accurate to say there will be _no_ fun and games if
it doesn't boot?

-- 
wraeth wra...@wraeth.id.au
GnuPG Key: B2D9F759


signature.asc
Description: Digital signature

Re: [gentoo-user] Re: grub-2 update

[Neil Bothwick]

On Thu, 16 Jul 2015 19:54:31 -0400, Jonathan Callen wrote:

 The Gummiboot project is no longer maintained, it has been merged into
 systemd as systemd-boot (note that using any other part of Systemd
 should *not* be required to use systemd-boot, but I don't know for
 sure because I do not have any non-systemd systems).

Interesting, I missed that. I've re-emerged systemd with the gnuefi flag
and it just worked. I do have a UEFI system without systemd that I
could try it on. But it's a headless MythTV backend in the loft, so
there will be fun and games if it doesn't boot. 


-- 
Neil Bothwick

Top Oxymorons Number 11: Terribly pleased


pgpiJMGvHsJzD.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: grub-2 update

[wraeth]

On Fri, Jul 17, 2015 at 10:40:16AM +0100, Neil Bothwick wrote:
 On Fri, 17 Jul 2015 18:45:59 +1000, wraeth wrote:
 
   could try it on. But it's a headless MythTV backend in the loft, so
   there will be fun and games if it doesn't boot.   
  
  Wouldn't it be more accurate to say there will be _no_ fun and games if
  it doesn't boot?
 
 Well, with no TV to watch, I'd have to entertain the wife somehow ;-)
 

Touché

-- 
wraeth wra...@wraeth.id.au
GnuPG Key: B2D9F759


signature.asc
Description: Digital signature

Re: [gentoo-user] Re: grub-2 update

[Neil Bothwick]

On Fri, 17 Jul 2015 18:45:59 +1000, wraeth wrote:

  could try it on. But it's a headless MythTV backend in the loft, so
  there will be fun and games if it doesn't boot.   
 
 Wouldn't it be more accurate to say there will be _no_ fun and games if
 it doesn't boot?

Well, with no TV to watch, I'd have to entertain the wife somehow ;-)


-- 
Neil Bothwick

Hard work has a future payoff. Laziness pays off now.


pgpbIZYILBNMU.pgp
Description: OpenPGP digital signature

[gentoo-user] Re: grub-2 update

[James]

Alan McKinnon alan.mckinnon at gmail.com writes:


 The don't use it, grub:0 still works just fine 

It's all working fine (atm). But changes are problematic, or at least
they have been in the past

 I gave grub-2 a try earlier this week and once again couldn;t figure out
 how to install that mini-OS that bootstraps a boot loader which
 bootstraps a boot loader which loads code that loads a kernel. So back
 to grub:0 for me


I do not really want to go to back to grub-legacy. I do not what to
be bound to (u)efi booting either.  You could just lie to me
and make us both happy?


Most safe (least hassle):: I guess I should just mask it and stay on::
sys-boot/grub- 2.02_beta2-r3

It's been fine even with multiple kernel updates...


James

[gentoo-user] Re: grub-2 update

[James]

Alec Ten Harmsel alec at alectenharmsel.com writes:

Grub-2.02_beta2-r3  wants to upgrade to  grub-2.02_beta2-r7   


 It looks like he’s going from grub-2.02 to grub-2.02. I don’t think
   any action is necessary.

Notice r3-- r7
Grub 2 can be a bear in sheep's clothing



 I know that for servers it’s common to have a bunch of partitions to
prevent a rogue process from filling up the entire disk and tanking the
entire system, but I can’t imagine it’s that much more complex.

I spent days during early kernel upgrades getting grub2 happy.
The last (2) kernel updates when smooth.  I was also curious if
anyone else has upgraded to

grub- 2.02_beta2-r7   ?


James

Re: [gentoo-user] Re: grub-2 update

[Steven Lembark]

Solution that works for me:

 - Compile the kernel with everything built-in leaving modules for the 
   few things that really need to be reloadable. Turn everything in 
   the bloody thing off. This avoids the need for a kernel-specific
   filestem in the initrd.

 - This since you don't need any modules in the initrd a 
   simple, static solution with busybox and init something
   like:

#!/bin/busybox sh

/bin/busybox --install -s;
sync;

mount -t proc   none /proc;
mount -t sysfs  none /sys;

/sbin/mdadm --verbose --assemble --scan;
/sbin/vgscan--verbose;
/sbin/vgchange  --verbose -a y /dev/vg00/root;

mount /dev/vg00/root /mnt/root;
mount;

exec /sbin/switch_root /mnt/root /sbin/init;

Add whatever you need for encryped filesytems, but it 
won't have to change over time unless you change the 
boot requirements.

Add a copy of busybox, switch_root, init, a static copy of lvm 
into something like /boot/standard-init.cpio.gz.  Mine is in 
/usr/src/initrd with two sub's standard and rescue differing 
only in the init script. A second initrd the last line commented 
out as /boot/rescue-init.cpio.gz for cases where switch_root gets 
unhappy.

#!/bin/bash --login

cd $(dirname $0);

for i in */init;
do
dir=$(dirname $i);
name=$(basename $dir);

(
cd $dir;
kleenfilz;
find .  |
cpio -o -Hnewc  |
gzip -9v /boot/$name.cpio.gz) 
done

wait;

ls -lt /boot;

exit 0;

builds and installs the initrd's easily enough (kleenfilz
is a shell sub that removes editor cruft, no reason to leave
*~ files :-).

 - Add /etc/grub.d/09_custom (i.e., into the config *before* the
   junk that 10 adds in) like the one below. Note that this uses
   the symlink /boot/vmlinuz with the static init. The current
   portion comes from a second vmlinuz.stable symlink I curate
   manually to the last kernel that lived for a while and never,
   ever caused problems [not that I've ever botched a config
   siwtch. no, really...].
   
   The standard link and fixed init-script allow a static copy of the 
   grub config file with /boot/vmlinuz and /boot/standard.cpio.gz
   hardwired.

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.

menuentry 'current standard' --class gentoo --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-e18157fe-1330-4cbb-8374-125d9c26e360' {
load_video
if [ x$grub_platform = xefi ]; then
set gfxpayload=keep
fi
insmod gzio
insmod part_msdos
insmod xfs
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 
e18157fe-1330-4cbb-8374-125d9c26e360
else
  search --no-floppy --fs-uuid --set=root 
e18157fe-1330-4cbb-8374-125d9c26e360
fi
echo'Loading Linux ...'
linux   /boot/vmlinuz root=/dev/sdc1 ro
echo'Loading initrd ...'
initrd  /boot/standard.cpio.gz
}

menuentry 'current rescue' --class gentoo --class gnu-linux --class gnu --class 
os $menuentry_id_option 'gnulinux-simple-e18157fe-1330-4cbb-8374-125d9c26e360' {
load_video
if [ x$grub_platform = xefi ]; then
set gfxpayload=keep
fi
insmod gzio
insmod part_msdos
insmod xfs
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  
e18157fe-1330-4cbb-8374-125d9c26e360
else
  search --no-floppy --fs-uuid --set=root 
e18157fe-1330-4cbb-8374-125d9c26e360
fi
echo'Loading Linux ...'
linux   /boot/vmlinuz root=/dev/sdc1 ro
echo'Loading initrd ...'
initrd  /boot/rescue.cpio.gz
}


 - Run grub2-mkconfig once. 

 - Never touch the grub.cfg file ever again (unless you switch the
   boot filesystem type). If I went from XFS - btrfs for the root
   filesystem I'd have to hack the insmod xfs entries, nothing
   more. 

-- 
Steven Lembark 3646 Flora Pl
Workhorse Computing   St Louis, MO 63110
lemb...@wrkhors.com  +1 888 359 3508

Re: [gentoo-user] Re: grub-2 update

[Heiko Baums]

Am 16.07.2015 um 22:05 schrieb James:

 I spent days during early kernel upgrades getting grub2 happy.

You only need to run `grub2-mkconfig -o /boot/grub/grub.cfg` after each
kernel update. I'm using grub2 not for such a long time, but I made some
kernel upgrades since I switched from grub-legacy to grub2 and had no
problems so far.

 The last (2) kernel updates when smooth.  I was also curious if
 anyone else has upgraded to
 
 grub- 2.02_beta2-r7   ?

I don't know when or if it was updated after I switched to grub2, but I
have grub 2.02_beta2-r7 installed and had no problems with it either.

But what can happen at worst when you update a boot loader? That your
boot loader fails to boot. So you can still boot from a LiveCD and
select the option Boot from harddrive. Then you can easily fix the
boot loader.

[gentoo-user] Re: grub-2 update

[James]

Jarry mr.jarry at gmail.com writes:


 I have similar setup as you and upgraded grub without any
 problem. If beta2-r3 worked for you, beta2-r7 will as well.
 If you did not disable /boot automount, there are no special
 steps needed. Portage will mount /boot, update grub, and
 dismound afterwards...


AH   do tell me more::


/dev/sda1   /bootext2defaults,noatime 0 2
/dev/sda3   /ext4defaults,noatime 0 1
/dev/sda4   /usr/local   ext4defaults,noatime 0 1

How do I make sure it's set to automount?

changes I should make ?? I've been bitten too many times
on kernel updates to not be very cautious

James

Re: [gentoo-user] Re: grub-2 update

[Jarry]

On 16-Jul-15 22:08, James wrote:


I have similar setup as you and upgraded grub without any
problem. If beta2-r3 worked for you, beta2-r7 will as well.
If you did not disable /boot automount, there are no special
steps needed. Portage will mount /boot, update grub, and
dismound afterwards...


AH   do tell me more::

/dev/sda1   /bootext2defaults,noatime 0 2
/dev/sda3   /ext4defaults,noatime 0 1
/dev/sda4   /usr/local   ext4defaults,noatime 0 1

How do I make sure it's set to automount?


It is per default so. You can only disable it by some
variable (forgot its name). If you want to be sure, simply
mount /boot (if it is not yet) before updating grub.


changes I should make ?? I've been bitten too many times
on kernel updates to not be very cautious-- 


No changes are necessary. Config-files remain as they were.
I'have been using grub2 since it went stable and never had
any problem with it...

Jarry
___
This mailbox accepts e-mails only from selected mailing-lists!
Everything else is considered to be spam and therefore deleted.

Re: [gentoo-user] Re: grub-2 update

[Neil Bothwick]

On Thu, 16 Jul 2015 20:01:29 + (UTC), James wrote:

  I gave grub-2 a try earlier this week and once again couldn;t figure
  out how to install that mini-OS that bootstraps a boot loader which
  bootstraps a boot loader which loads code that loads a kernel. So back
  to grub:0 for me  
 
 I do not really want to go to back to grub-legacy. I do not what to
 be bound to (u)efi booting either.  You could just lie to me
 and make us both happy?

If you have UEFI, then just use Gummiboot, it's much simpler.


-- 
Neil Bothwick

If it ain't broke, break it and charge for repair.


pgpebtup_Mj5U.pgp
Description: OpenPGP digital signature

[gentoo-user] Re: grub-2 update

[Jonathan Callen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2015-07-16 17:41, Neil Bothwick wrote:
 On Thu, 16 Jul 2015 20:01:29 + (UTC), James wrote:
 
 I gave grub-2 a try earlier this week and once again couldn;t
 figure out how to install that mini-OS that bootstraps a boot
 loader which bootstraps a boot loader which loads code that
 loads a kernel. So back to grub:0 for me
 
 I do not really want to go to back to grub-legacy. I do not what
 to be bound to (u)efi booting either.  You could just lie to me 
 and make us both happy?
 
 If you have UEFI, then just use Gummiboot, it's much simpler.
 
 

The Gummiboot project is no longer maintained, it has been merged into
systemd as systemd-boot (note that using any other part of Systemd
should *not* be required to use systemd-boot, but I don't know for
sure because I do not have any non-systemd systems).

- -- 
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJVqEQ0AAoJEEIQbvYRB3mgtToP/AgKlQrdkgMq5ss8n/uO5hwl
iBMu9+iFE7NRyp8tu/KZ7QPmVTwrkNu3WtmquhNakUj12ryI+mGQ/PHdcEB/p3LD
9vlxLWemj7HI4Qk+RZZqNThOCXAYP+mc3i3T2NgKgYuceoIk/z+kwAPVfnmqSjlZ
QyYS5sveoVwM43AdqbatAvt8n2BEmYbTz9PjZ5zcrRYTpZphqltdU29NbzCvsYVU
BOf10p5kzSi9G+Aph89RBpQhowL9iwVDLalZ/NUKk588ZyQLi78JotghnCGUJ9Ig
1492fMcIsqiAkOkSuVoPtiOu0SITaHyDTOHfE20+QtOm29HM1Hm9MrV94FkQGY92
Bdl/a6BIZssbNgLiNuayo9V3OV/JoSlPjp52a4h2d/Vu+NxKyvjswwK6LFae/ka5
pf9bAqiq2jEl21yboskH35EbYDciZddG48r5VMQl0hplplkCoLrBUVlvdW8M/28a
Yu9IH19+VpqAOuahmOJvMQ5/OOHRVj7RRzJC51YGPXR2uSxcV5SDLCIts6Oiww+w
qI7aVang9JibuY166T2j4LYWGEXjeO7xE3xk7kWKO6l/608uLA4Vyrt/vaFLsJL1
XrxWzcBQ+lVnY/+g8tv6q0nINhVQ551ugUxCilTJzHmSCT/1aAa7Bx0YS+5LwyRq
qqWwjSTxzG6yl88l6ys2
=ys3e
-END PGP SIGNATURE-

Re: [gentoo-user] Re: grub doesn't autoselect a kernel

[Alexander Kapshuk]

On Fri, Jul 10, 2015 at 5:22 PM, Grant emailgr...@gmail.com wrote:
 I have grub running on many Gentoo machines but on one of them it sits
 on the kernel selection screen and doesn't autoboot even though the
 menu says:

 The highlighted entry will be booted automatically in 2 seconds.

 Nothing happens for any length of time but pressing Enter boots the
 kernel as usual.  Any ideas?

 - Grant


 Weird right?  Better to take this to the grub list?

 - Grant


While I have not experienced the trouble you're having with grub, nor
am I a grub expert, I thought it might be worth getting some more info
about the problem.

(1). What version of grub are you running?
(2). Does 'grub2-script-check(1)' reveal any grub.cfg syntax errors?
(3). Do you have GRUB_TIMEOUT set in /etc/default/grub to a value
other than the default 5 seconds?
(4). Did you try setting these options in grub.cfg?
set pager=1
set debug=all
Did that shed any light on the problem you're having?

[gentoo-user] Re: grub doesn't autoselect a kernel

[Grant]

 I have grub running on many Gentoo machines but on one of them it sits
 on the kernel selection screen and doesn't autoboot even though the
 menu says:

 The highlighted entry will be booted automatically in 2 seconds.

 Nothing happens for any length of time but pressing Enter boots the
 kernel as usual.  Any ideas?

 - Grant


Weird right?  Better to take this to the grub list?

- Grant

Re: [gentoo-user] Re: grub - gummiboot: good

[Stefan G. Weichinger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 30.01.2015 um 02:34 schrieb Jonathan Callen:

 You have mounted your ESP on /boot, so you need to tell grub *that*
 is your ESP, not /boot/efi, like so:
 
 # grub2-install --target=x86_64-efi --efi-directory=/boot
 
 Once you do that, everything should pretty much Just Work.

Yes, you are right! Such a small issue ...
And where to put grub.cfg now ...?

looks cleaner now  (grub_3 comes from testing around ...) -

# ls -RF
.:
e55a6b6a09bd2b1c50216272545a8d1f/  EFI/  grub/  loader/

./e55a6b6a09bd2b1c50216272545a8d1f:
3.18.3-gentoo/  3.18.4-gentoo/  3.19-rc6/

./e55a6b6a09bd2b1c50216272545a8d1f/3.18.3-gentoo:
initrd*  kernel*

./e55a6b6a09bd2b1c50216272545a8d1f/3.18.4-gentoo:
initrd*  kernel*

./e55a6b6a09bd2b1c50216272545a8d1f/3.19-rc6:
initrd*  kernel*

./EFI:
Boot/  EFI/  grub_3/  gummiboot/

./EFI/Boot:
BOOTX64.EFI*

./EFI/EFI:

./EFI/grub_3:
grubx64.efi*

./EFI/gummiboot:
gummibootx64.efi*

./grub:
fonts/  grubenv*  locale/  themes/  x86_64-efi/

./grub/fonts:
unicode.pf2*

./grub/locale:
de.mo*

./grub/themes:
starfield/

./grub/themes/starfield:
blob_w.png*boot_menu_se.png*  dejavu_12.pf2*
[..]


./loader:
entries/  loader.conf*

./loader/entries:
e55a6b6a09bd2b1c50216272545a8d1f-3.18.3-gentoo.conf*
e55a6b6a09bd2b1c50216272545a8d1f-3.19-rc6.conf*
e55a6b6a09bd2b1c50216272545a8d1f-3.18.4-gentoo.conf*
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJUy1d2AAoJEClcuD1V0PzmQogP/jg0D9qfidKNMAU6j/o+ZUa1
P8Q7ecFxtgHN8TmQK7vtbxK2EfGaSx/3eqQHBWBWRA7W+0fhlsBweCOcTeTAHqJN
+VMe79Pb7HXoGdR6WntETuwHRQSfWxk5M65PIcQkdMTlLaZ5fnNBXcc5QSHVfhud
YswdcyBqmlbZxkh8+aEoEzZSpahLzfg54J/MOpW1fYtZwwTZS7UhWgH/ACB1N4HP
KeBVLB9yE3tfiBo0mTQuQA/pdQ3bmVlPdDij8rG9Lx07+oDsj7modyF4/e4gWJv0
/9KVVkquV4ttUGLJ+0C3YtU2uI8NG2QgHX8iBSPYUkyQysb7JpEh0XHPSf2uqOgJ
a5wVrJB/EMt1ZsKjyKQ+eRkqkMqAnOJfAQlPLspAltflHkVYX/zfW9dAqx50bsAN
/bvuWknGKCgGWBvY37o39PyCDHMZeQugk8F7r/9b1Km6UNIkf+9gdhytpcW/t+gV
0Aask2sRnCjZfJhmTBJfCm9VEB/+fEnqO3aPYEVOoStTlzohwsTNb9uBHKFQ+DiU
bSFU32KwSIRMO53xqgmEj903vfMHPi7PIXgchrITI0+jp7kZUEyd1P7zTvei0r0U
hVcxEXm4VFiYCqf622bxNgdomQhJv2EXOelnXERj1rgYhqCYN4T4oqX2O8Efduw0
MAEu3BT+zZ6bIYg1MQs+
=wJx7
-END PGP SIGNATURE-

Re: [gentoo-user] Re: grub - gummiboot: good

[Stefan G. Weichinger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 30.01.2015 um 11:05 schrieb Stefan G. Weichinger:
 Am 30.01.2015 um 02:34 schrieb Jonathan Callen:
 
 You have mounted your ESP on /boot, so you need to tell grub
 *that* is your ESP, not /boot/efi, like so:
 
 # grub2-install --target=x86_64-efi --efi-directory=/boot
 
 Once you do that, everything should pretty much Just Work.
 
 Yes, you are right! Such a small issue ... And where to put
 grub.cfg now ...?

solved:

/boot/grub/grub.cfg

works now for me.

Thanks @all !
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJUy2N/AAoJEClcuD1V0Pzm/FEP/RQ5V/kfDxprMgRGDoFVcnXA
RHZ85TRw8Iy3wUqsNdYr32oY+ZQr6G/GF4mq8Dyx1tQJMgEHc4Q3hD9NT/gO0VGz
xaoWrj16QSiW1cvo1/i+8StcQirrFhQHYSoJaSnGTo+VV/yaKc2H2nTJNd8bOWyX
RndgdlhjqyTQxIpmdXN9P1c3glacSQ+mFk6Ba07JRZsiHkPOrgOKUKKQ4+qLiodb
UYH6/y6JJssnt4EiTVrkRRjbPs9/Ri7kq3PfK/rrI+03iwPNM5UkFTGBv269PTBk
21ZeoZoj97nxtnO7/gcMgzPzldDmI+bZ8cb0F1UVTaqKFMdURkm/yrtqxxTUbpea
/TAgRw68hfqjlVetD9W6ufcSHX5kB67rOcKwUulf+3WYH/4jrjMK2xOdwigzZzMK
qGVK3UOrYaWkOdJbbjkF9tEatKY3XYQgSmYUuKi6+ipceysi69MA7dj5U48vJQGX
5HtRPe+f1CwKB2Rg3tSq1phZnxyZyYo8FisuTtTXrrSdDtEZNrclWzqufhtRFavi
PNTkPveH7ck/vSNIqNPnozZHAAbLKLMmKbnnUBAWYQaEmtbaVBhTi/IyS7pGnvBW
MHOBaWBIAoi1V70Omhkm3jOBMe6WFKAEXV2BASe5GpcQfOwNToEaa4hh+3yEFJ+h
JzzEPmf6unqeGh4sthPD
=F0Qn
-END PGP SIGNATURE-

[gentoo-user] Re: grub - gummiboot: good

[Jonathan Callen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/28/2015 06:08 PM, Stefan G. Weichinger wrote:
 On 28.01.2015 23:51, Tom H wrote:
 
 Why two EFIs?
 
 One of them's unnecessary but if you want to have both, you have
 to have them both in the efibootmgr invocation.
 
 I don't know why.
 
 What I did:
 
 cd /boot rm -fr * gummiboot install grub2-install
 --target=x86_64-efi --efi-directory=/boot/efi 
 --bootloader-id=grub_uefi --recheck
 
 (and maybe run kerninst to actually put a kernel and its initrd
 there)
 
 
 The grub2-install-command was just taken from shell history. It
 might be *wrong*  ... yes. At least it says it runs without
 errors.
 
 
 When I run:
 
 # grub2-install --target=x86_64-efi  --bootloader-id=grub_3
 --recheck
 
 Installing for x86_64-efi platform. grub2-install: error: cannot
 find EFI directory.
 
 
 Can you create an entry for your kernel in 40_custom and test
 it?
 
 Take a look at grub.cfg. I doubt that grub-mkconfig looks for a
 kernel in '/boot/machine_id/kernel_version/' or that it
 recognizes 'kernel' and 'initrd' as valid names for a kernel and
 an initramfs.
 
 grub2-mkconfig did not detect any kernel, yes.
 
 That doesn't matter btw ... the reason to have grub2 in parallel is
 just the feature to boot iso-files (rescue media ...).
 
 All this additional grub2-fiddlery is basically learning how to
 make it work and getting the convenience of not having to insert a
 CD now and then.
 
 For daily work I am perfectly happy with gummiboot *just* booting
 my kernel(s) ... which works already!
 
 thanks, regards, Stefan
 
 (leaving now ... late here as mentioned)
 

You have mounted your ESP on /boot, so you need to tell grub *that* is
your ESP, not /boot/efi, like so:

# grub2-install --target=x86_64-efi --efi-directory=/boot

Once you do that, everything should pretty much Just Work.

- -- 
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJUyt+NAAoJEEIQbvYRB3mgolYP/1g9YlZ/IYaLlKNFOMiEKaIa
KrsF+ne2vmITUXtLsVtwCDZNIQyHj6c/Ma7zHpm9Kbzn2OxpKt8dduDNdpA8QLwx
E3TM3pV0AfCYRDazH6pZmHRpDc7gVTtz4yQA/uGJyyFynwqJ3LlPYqMzTv6zFUrf
lJSBBHuNBU340xAukPf6iEMrNh5CbdT9bzzJGyEPfsGcAM3kDO0DlQC1jf8hgCwr
YJsH/WB+EBJ4TR4phzYvAdGOJF04PAwtqTkBjmbyjTwNYy1oaZILu5qjEaHuA+PH
Eybba4Dj3/ItIEyG8cy0Qw7fjUXby01OAYtnLUXMhBH7lxSsBFzcSvihxv3bpt+u
HvHiOi3M+jWYpfhF1rUEGcK3pF8X7gDiQTaDkERzv+EcDLHG19McZPDb3Gpva6qi
oot3O+ky5MQLuG9euhavalEMm2mDCQmSMkS7gVQff5tGUCeUc5fzLKXd1Sywj4Ze
tSBctEU1gMpHenl0XO2FJ7OdgkAAeMYKSBkJJhLhYg8iXe7oBC09VmQeoPBvuwAR
IMzOYJkD6+FY8pOdXQujRWnM47H9/r0434B+2nLujPQ1fgc/MHpVrv7LGwFMEocU
3UloQH4Mh927WNa/F9ilBwl5R0b8vh2hhymj8VENZmsPPB6hV5ZSsvGQ6somL+/r
4ULEtTdoNWUrIVVUvMjF
=IoH5
-END PGP SIGNATURE-

[gentoo-user] Re: grub-mkconfig doesn't pick UUID/LABEL

[Nilesh Govindrajan]

On Sun, Aug 10, 2014 at 12:06 AM, Nilesh Govindrajan m...@nileshgr.com wrote:
 When I run grub-mkconfig (it's grub2, -multislot), it generates
 root=/dev/md127p2. md arrays get assembled at boot so their numbers
 aren't fixed.

 So far I've been manually editing the generated config. But I don't want
 a non-booting server some time in future because of this bug. My rootfs
 has a label with gentoo and root=LABEL=gentoo works perfectly.


Never mind, http://wiki.gentoo.org/wiki/GRUB2 solved it for me.

[gentoo-user] Re: grub vs grub 2

[James]

Neil Bothwick neil at digimed.co.uk writes:


 There are scripts to automatically generate a configuration but
 grub-mkconfig is no more compulsory than genkernel - but both can make
 life easier when setting up multiple, different systems.

Neil et al,

Where is the BEST (gentoo) grub2 documentation?
The last link says that the reason grub2 is still
masked, is the lack of documentation

All I've found so far is:
http://www.gnu.org/software/grub/grub-documentation.html
http://wiki.gentoo.org/wiki/GRUB2
http://dev.gentoo.org/~scarabeus/grub-2-guide.xml
http://blogs.gentoo.org/scarabeus/2011/09/17/grub2-4-months-after/

Any other docs/examples for grub2? Something dumbed_down for us
older admins, would be keen


James

Re: [gentoo-user] Re: grub vs grub 2

[Neil Bothwick]

On Wed, 15 Feb 2012 15:57:27 + (UTC), James wrote:

 Where is the BEST (gentoo) grub2 documentation?

I'm not saying it's the best, but the one I used to switch over is
http://en.gentoo-wiki.com/wiki/Grub2


-- 
Neil Bothwick

Bugs are Sons of Glitches


signature.asc
Description: PGP signature

Re: [gentoo-user] Re: grub vs grub 2

[Claudio Roberto França Pereira]

mike, I'd DEFINITELY LOVE to read grub's history, even if it's a short
summary or something.

TOTALLY OFF-TOPIC, but anyone could recommend me a open
source/linux/unix/free software history book? Something that mentioned
the FSF foundation, the GPL creation, the XFree86 - X.org evolution,
linux [..]. - 2.4 - 2.6 evolution, sound stack evolution (OSS, ALSA,
JACK, PA, ESD, Arts, Phonon), multimedia history (ffmpeg, mplayer,
mplayer2, gstreamer, xine, vlc). It could go all the way back to
shell's, like sh, csh, BASH, zsh.

Re: [gentoo-user] Re: grub vs grub 2

[Paul Hartman]

On Wed, Feb 15, 2012 at 10:28 AM, Claudio Roberto França Pereira
spide...@gmail.com wrote:
 mike, I'd DEFINITELY LOVE to read grub's history, even if it's a short
 summary or something.

 TOTALLY OFF-TOPIC, but anyone could recommend me a open
 source/linux/unix/free software history book? Something that mentioned
 the FSF foundation, the GPL creation, the XFree86 - X.org evolution,
 linux [..]. - 2.4 - 2.6 evolution, sound stack evolution (OSS, ALSA,
 JACK, PA, ESD, Arts, Phonon), multimedia history (ffmpeg, mplayer,
 mplayer2, gstreamer, xine, vlc). It could go all the way back to
 shell's, like sh, csh, BASH, zsh.

Not OSS related, but I really enjoyed reading Dennis Ritchie's article
on the history of the C programming language (which also gets into the
early UNIX days):
http://cm.bell-labs.com/cm/cs/who/dmr/chist.html

Re: [gentoo-user] Re: grub vs grub 2

[Doug Hunley]

On Wed, Feb 15, 2012 at 11:11, Neil Bothwick n...@digimed.co.uk wrote:
 On Wed, 15 Feb 2012 15:57:27 + (UTC), James wrote:

 Where is the BEST (gentoo) grub2 documentation?

 I'm not saying it's the best, but the one I used to switch over is
 http://en.gentoo-wiki.com/wiki/Grub2

One thing I don't see addressed is having /boot on a RAID1 setup. For
Grub Legacy, I do:
grub  device (hd0) /dev/sda
grub  root (hd0,0)
grub  setup (hd0)

then repeat for sdb, sdc, and sdd

Does Grub2 deal w/ this better or the same?

-- 
Douglas J Hunley (doug.hun...@gmail.com)
Twitter: @hunleyd                                               Web:
douglasjhunley.com
G+: http://goo.gl/sajR3

Re: [gentoo-user] Re: grub vs grub 2

[Neil Bothwick]

On Wed, 15 Feb 2012 12:33:06 -0500, Doug Hunley wrote:

  I'm not saying it's the best, but the one I used to switch over is
  http://en.gentoo-wiki.com/wiki/Grub2  
 
 One thing I don't see addressed is having /boot on a RAID1 setup. For
 Grub Legacy, I do:
 grub  device (hd0) /dev/sda
 grub  root (hd0,0)
 grub  setup (hd0)
 
 then repeat for sdb, sdc, and sdd
 
 Does Grub2 deal w/ this better or the same?

I do it just the same. It's not really a GRUB thing, the BIOS needs
somewhere to load GRUB from, whatever the version number.


-- 
Neil Bothwick

I thought I saw the light at the end of the tunnel...
but it was just some sod with a torch bringing me more work!


signature.asc
Description: PGP signature

[gentoo-user] Re: grub vs grub 2

[James]

Florian Philipp lists at binarywings.net writes:


 sys-boot/grub has two slots. The default slot 0 with version numbers
 around 0.92-0.97 is grub-1 (or grub legacy). Slot 2 with version numbers
 around 1.99 is grub-2. Because it is still in development hell, it has
 not reached version 2.00.

OK, this part I understand.

 IIRC, sys-boot/grub-static is mostly there for systems that cannot
 compile grub, for example AMD64 no-multilib profiles.

OK, from the handbook
Thanks for clearing that up.

The second part of this question, is what version of grub do I use
with an AMD64 RAID-1-workstation install that will use this 
(multilib) profile:

[5]   default/linux/amd64/10.0/desktop/kde *

But I intend to put RAID-1 on the boot/root/swap partitions.
ext2 and ext4 FS for boot/root.

Any preferred version of grub (grub-1) will do ?

Trying to use this document:
http://en.gentoo-wiki.com/wiki/RAID/Software
The advice about grub (1 vs 2) and mdadm RAID-metadata
all confuses the grub choice for me.

Should I use Grub-1 ? or Grub-2 ?

Or maybe I should just do a traditional gentoo (handbook) install
and then migrate to a RAID-1 workstation, via this document:

http://en.gentoo-wiki.com/wiki/Migrate_to_RAID

I've spent countless hours on numerous attempts to do it all in
one install, and grub will not boot for me.

IDEAS?


James

[gentoo-user] Re: grub menu and the new openrc

[Nikos Chantziaras]

On 05/15/2011 01:34 PM, Dale wrote:

Hi,

I updated my kernel and had to reboot. I usually boot to single user
mode and rebuild my video drivers. Since I have this in my grub list, I
just select single user and it boots to single user mode. Well, not any
more. This is my current settings:


No need for single user in this case.  In the grub bootscreen, just 
append nox in the command line.  You don't even need an entry in 
grub.conf for this.  This will boot normally, but without starting X.

[gentoo-user] Re: grub installation problem

[Nuno J. Silva]

Jacques Montier jacques.mont...@numericable.fr writes:

 Hi all,

 I am installing Gentoo on a new pc and following the Gentoo manual.
 I create primary partition sda3 for boot with ext3 file system, then
 Extended partition for
 swap sda5
 / sda6 with reiserfs file system
 /usr sda7 with reiserfs file system
 /home sda8 with reiserfs fiel system.

 after chroot, i can install every package except grub in /boot.
 I get the message : your boot partition, detected as being mounted as
 /boot, is read-only.
 Remounting it in read-write mode ...
 Then the error message : failed to create symbolic link `//boot/boot` :
 Read-only file system.

 What's going on ???

I would check if there is any error or warning in the kernel log when
that happens.

just do
   dmesg | tail

after the error, to check the last lines in the log.

-- 
Nuno J. Silva
gopher://sdf-eu.org/1/users/njsg

Re: [gentoo-user] Re: grub installation problem

[Jacques Montier]

Le 12/01/2011 20:07, Nuno J. Silva a écrit :
 Jacques Montier jacques.mont...@numericable.fr writes:

 Hi all,

 I am installing Gentoo on a new pc and following the Gentoo manual.
 I create primary partition sda3 for boot with ext3 file system, then
 Extended partition for
 swap sda5
 / sda6 with reiserfs file system
 /usr sda7 with reiserfs file system
 /home sda8 with reiserfs fiel system.

 after chroot, i can install every package except grub in /boot.
 I get the message : your boot partition, detected as being mounted as
 /boot, is read-only.
 Remounting it in read-write mode ...
 Then the error message : failed to create symbolic link `//boot/boot` :
 Read-only file system.

 What's going on ???
 I would check if there is any error or warning in the kernel log when
 that happens.

 just do
dmesg | tail

 after the error, to check the last lines in the log.

Ther is no error message : just the lines
EXT3-fs (sda3): using internal journal


I see some warning about to avoid automounting and auto-installing with
/boot,
just export the DONT_MOUNT_BOOT variable

How can i do that ?

Thanks

Jacques

[gentoo-user] Re: grub installation problem

[Nuno J. Silva]

Jacques Montier jacques.mont...@numericable.fr writes:

 Le 12/01/2011 20:07, Nuno J. Silva a écrit :
 Jacques Montier jacques.mont...@numericable.fr writes:

 Hi all,

 I am installing Gentoo on a new pc and following the Gentoo manual.
 I create primary partition sda3 for boot with ext3 file system, then
 Extended partition for
 swap sda5
 / sda6 with reiserfs file system
 /usr sda7 with reiserfs file system
 /home sda8 with reiserfs fiel system.

 after chroot, i can install every package except grub in /boot.
 I get the message : your boot partition, detected as being mounted as
 /boot, is read-only.
 Remounting it in read-write mode ...
 Then the error message : failed to create symbolic link `//boot/boot` :
 Read-only file system.

 What's going on ???
 I would check if there is any error or warning in the kernel log when
 that happens.

 just do
dmesg | tail

 after the error, to check the last lines in the log.

 Ther is no error message : just the lines
 EXT3-fs (sda3): using internal journal

So there is no filesystem issue. Errors sometimes result in the
partition being remounted readonly.

Stroller has a point, read his post. As the mounted partitions list is
inside /proc, if you forgot to mount that, then maybe the ebuild can't
just find out /boot is actually mounted. There are probably other things
that might not work if you don't mount these partitions, so just to be
sure, check if you did that :-)

 I see some warning about to avoid automounting and auto-installing with
 /boot,
 just export the DONT_MOUNT_BOOT variable

 How can i do that ?

writing (and executing)

  export DONT_MOUNT_BOOT

in the shell should be enough.

-- 
Nuno J. Silva
gopher://sdf-eu.org/1/users/njsg

Re: [gentoo-user] Re: Grub broke out of the blue

[Mick]

On Tuesday 17 February 2009, Nikos Chantziaras wrote:

 One thing that could be at fault is that I had grub installed into hd0,2
 (sda3) which is an ext4 partition.  

I think that this is probably the cause.  GRUB has these stage 1.5 fs related 
files:

`e2fs_stage1_5'
`fat_stage1_5'
`ffs_stage1_5'
`jfs_stage1_5'
`minix_stage1_5'
`reiserfs_stage1_5'
`vstafs_stage1_5'
`xfs_stage1_5'

 /boot is sda4 and is ext3.  But I'm 
 sure grub should work no matter where you install it.  I can even
 install it on sda1 which is NTFS and it works.  Hell, I can even install
 it on the swap partition.

I think you are mixing stage 1 and stage 2 GRUB images?  Stage 1 is installed 
in MBR or any partition's boot sector.  No knowledge of fs is required for 
that to be accessed (by BIOS or a chainloader)  and JUMPTO deals with that.  
The 1.5 images on the other hand are used to read the fs in which GRUB's 
stage 2 is installed.  That's far too large to fit into a boot sector.  I 
doubt that GRUB's e2fs_stage1_5 can read ext4, but I don't know really - a 
question for GRUB's mailing list?

 I guess the reason it broke will remain a mystery :P

-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

[gentoo-user] Re: Grub broke out of the blue

[Nikos Chantziaras]

Neil Bothwick wrote:

On Tue, 17 Feb 2009 06:17:07 +0200, Nikos Chantziaras wrote:

I've no idea how it broke, but after an emerge --sync, a kernel 
(gentoo-sources) update was there.  After I compiled the kernel, I did 
the usual make modules_install  make install.  I edited grub.conf 
only to the point of changing the booted kernel to the

new one (just a matter of changing -r1 to -r2 at the end of the kernel
filename).  I reboot, Grub stops working.  It just displays GRUB and
hangs there.


Could you have inadvertently made more of a change to grub.conf than
that? Grub is notoriously fragile when it comes to its config file?


No, the change was a simple change of 1 byte (1 - 2).



Why did you edit it in the first place? As you used make install,you will
have symlinks from vmlinuz and vmlinuz.old to the new and previous
kernels. Use these in GRUB and there's no need to edit anything.


That won't work for me because I keep two different kernels (one for 
vmware and one for native) and I sometimes rebuild one of them after 
reconfiguring.  With that approach I would end up with the Native Grub 
entry trying to boot the vmware kernel.


One thing that could be at fault is that I had grub installed into hd0,2 
(sda3) which is an ext4 partition.  /boot is sda4 and is ext3.  But I'm 
sure grub should work no matter where you install it.  I can even 
install it on sda1 which is NTFS and it works.  Hell, I can even install 
it on the swap partition.


I guess the reason it broke will remain a mystery :P

[gentoo-user] Re: Grub broke out of the blue

[Nikos Chantziaras]

Nikos Chantziaras wrote:
I've no idea how it broke, but after an emerge --sync, a kernel 
(gentoo-sources) update was there.  After I compiled the kernel, I did 
the usual make modules_install  make install.  I edited grub.conf 
only to the point of changing the booted kernel to the new one (just a 
matter of changing -r1 to -r2 at the end of the kernel filename).  I 
reboot, Grub stops working.  It just displays GRUB and hangs there.


What might have cause this?  /boot is a 50MB ext3 partition with 14MB 
free.  I had to boot from a live CD and make sda1 bootable (Windows XP) 
so I can get online and burn a repair CD that supports ext4 (/).


Back.  Grub was booting inside a VM under XP even though it refused to 
boot for real.  So I booted in a VM and reinstalled Grub from there. 
I'm left to wonder now how copying a new kernel into /boot with make 
install can possibly make Grub go fubar...