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

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

install Kernel and GRUB in chroot.

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

Contents

  install Kernel and GRUB in chroot. Dmitry <lbvf50.mobile@gmail.com> - 2024-02-01 16:20 +0100
    Re: install Kernel and GRUB in chroot. Marco Moock <mm@dorfdsl.de> - 2024-02-01 17:00 +0100
      Re: install Kernel and GRUB in chroot. Max Nikulin <manikulin@gmail.com> - 2024-02-01 17:30 +0100
        Re: install Kernel and GRUB in chroot. Dmitry <lbvf50.mobile@gmail.com> - 2024-02-01 19:50 +0100
      Re: install Kernel and GRUB in chroot. Dmitry <lbvf50.mobile@gmail.com> - 2024-02-01 18:30 +0100
        Re: install Kernel and GRUB in chroot. Marco Moock <mm@dorfdsl.de> - 2024-02-01 19:50 +0100
          Re: install Kernel and GRUB in chroot. Marco Moock <mm@dorfdsl.de> - 2024-02-02 15:20 +0100
          Re: install Kernel and GRUB in chroot. Dmitry <lbvf50.mobile@gmail.com> - 2024-02-02 15:20 +0100
            Re: install Kernel and GRUB in chroot. Max Nikulin <manikulin@gmail.com> - 2024-02-02 15:30 +0100
              Re: install Kernel and GRUB in chroot. Dmitry <lbvf50.mobile@gmail.com> - 2024-02-02 19:30 +0100
                Re: install Kernel and GRUB in chroot. <tomas@tuxteam.de> - 2024-02-02 20:00 +0100
              Re: install Kernel and GRUB in chroot. Dmitry <lbvf50.mobile@gmail.com> - 2024-02-02 19:40 +0100
                Re: install Kernel and GRUB in chroot. "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-02 21:00 +0100
                  Re: install Kernel and GRUB in chroot. Max Nikulin <manikulin@gmail.com> - 2024-02-03 05:00 +0100
          Re: install Kernel and GRUB in chroot. Dmitry <lbvf50.mobile@gmail.com> - 2024-02-02 15:30 +0100
            Re: install Kernel and GRUB in chroot. David Wright <deblis@lionunicorn.co.uk> - 2024-02-02 17:50 +0100
            Re: install Kernel and GRUB in chroot. Franco Martelli <martellif67@gmail.com> - 2024-02-02 21:20 +0100
    Re: install Kernel and GRUB in chroot. Tim Woodall <debianuser@woodall.me.uk> - 2024-02-01 19:20 +0100
      Re: install Kernel and GRUB in chroot. Dmitry <lbvf50.mobile@gmail.com> - 2024-02-01 20:00 +0100
        Re: install Kernel and GRUB in chroot. Marco Moock <mm@dorfdsl.de> - 2024-02-01 20:10 +0100
          Re: install Kernel and GRUB in chroot. Tim Woodall <debianuser@woodall.me.uk> - 2024-02-01 20:30 +0100
            Re: install Kernel and GRUB in chroot. Marco Moock <mm@dorfdsl.de> - 2024-02-01 20:40 +0100
              Re: install Kernel and GRUB in chroot. Tim Woodall <debianuser@woodall.me.uk> - 2024-02-02 20:20 +0100
                Re: install Kernel and GRUB in chroot. Max Nikulin <manikulin@gmail.com> - 2024-02-03 05:10 +0100
                  Re: install Kernel and GRUB in chroot. Tim Woodall <debianuser@woodall.me.uk> - 2024-02-03 22:30 +0100
                    Re: install Kernel and GRUB in chroot. Felix Miata <mrmazda@earthlink.net> - 2024-02-04 03:30 +0100
        Re: install Kernel and GRUB in chroot. Tim Woodall <debianuser@woodall.me.uk> - 2024-02-01 20:20 +0100
        Re: install Kernel and GRUB in chroot. Max Nikulin <manikulin@gmail.com> - 2024-02-02 03:40 +0100
          Re: install Kernel and GRUB in chroot. Marco Moock <mm@dorfdsl.de> - 2024-02-02 07:00 +0100
    Re: install Kernel and GRUB in chroot. Dmitry <lbvf50.mobile@gmail.com> - 2024-02-03 16:50 +0100
      Re: install Kernel and GRUB in chroot. Max Nikulin <manikulin@gmail.com> - 2024-02-04 14:20 +0100
        Re: install Kernel and GRUB in chroot. Dmitry <lbvf50.mobile@gmail.com> - 2024-02-05 08:20 +0100
        Re: install Kernel and GRUB in chroot. Dmitry <lbvf50.mobile@gmail.com> - 2024-02-05 12:00 +0100
          Re: install Kernel and GRUB in chroot. Ralph Aichinger <ra@h5.or.at> - 2024-02-05 12:20 +0100
          Re: install Kernel and GRUB in chroot. Max Nikulin <manikulin@gmail.com> - 2024-02-05 12:50 +0100

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

#266855

On Thu, 1 Feb 2024, Marco Moock wrote:

> Am 02.02.2024 um 01:46:06 Uhr schrieb Dmitry:
>
>> 2. ==>BAM<== some how that binary knows the system partition.
>
> That information is on the EFI partition, where the GRUB bootloader
> binary also resides.
>
> root@ryz:/boot/efi/EFI# cat /boot/efi/EFI/debian/grub.cfg
> search.fs_uuid 5b8b669d-xyz root hd0,gpt2 #boot partition
> set prefix=($root)'/grub'
> configfile $prefix/grub.cfg
> root@ryz:/boot/efi/EFI#
>
> If that information is loaded, the kernel can be loaded from the boot
> partition.
>
>
>

Are you sure that file does anything? I don't have one

drwxr-xr-x 2 root root   4096 Dec 31  2017 .
drwxr-xr-x 6 root root   4096 Dec 25  2019 ..
-rwxr-xr-x 1 root root 163840 Sep 11  2022 grubx64.efi


This finds my boot partition and then chainloads the XEN efi binary
which does have some config.

/boot/efi/EFI/XEN:
total 38204
drwxr-xr-x 2 root root     4096 May  5  2023 .
drwxr-xr-x 6 root root     4096 Dec 25  2019 ..
-rwxr-xr-x 1 root root 31132473 Aug 12 08:34 initrd.img
-rwxr-xr-x 1 root root  5283136 Aug 12 08:34 vmlinuz
-rwxr-xr-x 1 root root      138 May  5  2023 xen.cfg
-rwxr-xr-x 1 root root  2687456 Jun 20  2021 xen.efi

$ cat /boot/efi/EFI/XEN/xen.cfg
[global]
default=debian

[debian]
options=console=vga smt=true
kernel=vmlinuz root=/dev/mapper/vg--dirac-root ro quiet
ramdisk=initrd.img


menuentry "Xen EFI NVME" {
     insmod part_gpt
     insmod search_fs_uuid
     insmod chain
#    set root=(hd1,gpt1)
     search --no-floppy --fs-uuid --set=root C057-BC13
     chainloader (hd1,gpt1)/EFI/XEN/xen.efi
}

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

#266856

Am 01.02.2024 um 19:20:01 Uhr schrieb Tim Woodall:

> $ cat /boot/efi/EFI/XEN/xen.cfg
> [global]
> default=debian
> 
> [debian]
> options=console=vga smt=true
> kernel=vmlinuz root=/dev/mapper/vg--dirac-root ro quiet
> ramdisk=initrd.img
> 
> 
> menuentry "Xen EFI NVME" {
>      insmod part_gpt
>      insmod search_fs_uuid
>      insmod chain
> #    set root=(hd1,gpt1)
>      search --no-floppy --fs-uuid --set=root C057-BC13
>      chainloader (hd1,gpt1)/EFI/XEN/xen.efi
> }

Then this file tells the boot loader about the /boot or / partition.
Is that the Xen virtualization software?

-- 
Gruß
Marco

Spam und Werbung bitte an ichschickereklame@cartoonies.org

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

#266887

On Thu, 1 Feb 2024, Marco Moock wrote:

> Am 01.02.2024 um 19:20:01 Uhr schrieb Tim Woodall:
>
>> $ cat /boot/efi/EFI/XEN/xen.cfg
>> [global]
>> default=debian
>>
>> [debian]
>> options=console=vga smt=true
>> kernel=vmlinuz root=/dev/mapper/vg--dirac-root ro quiet
>> ramdisk=initrd.img
>>
>>
>> menuentry "Xen EFI NVME" {
>>      insmod part_gpt
>>      insmod search_fs_uuid
>>      insmod chain
>> #    set root=(hd1,gpt1)
>>      search --no-floppy --fs-uuid --set=root C057-BC13
>>      chainloader (hd1,gpt1)/EFI/XEN/xen.efi
>> }
>
> Then this file tells the boot loader about the /boot or / partition.
> Is that the Xen virtualization software?
>
The NVRAM is configured to boot:
/boot/efi/EFI/debian/grubx64.efi

That then hunts for grub.cfg. I believe it finds the first grub.cfg -
which has caused me issues in the past where I've had a legacy partition
on the disk that I'd forgotten about but the efi application sees. I'd
be interested if there's a way to tell grubx64.efi to look for a
particular partition UUID.

That menuentry above then tells efi to chainload the xen.efi
application. This is all in efi land.

That then reads xen.cfg and boots the kernel and initrd defined in that
file.

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

#266913

On 03/02/2024 02:15, Tim Woodall wrote:
>>> $ cat /boot/efi/EFI/XEN/xen.cfg
[...]
> I'd be interested if there's a way to tell grubx64.efi to look for a
> particular partition UUID.

An example of such grub.cfg from EFI/debian has been posted already in 
this thread
https://lists.debian.org/msgid-search/20240201200846.0bb82581@dorfdsl.de

Frankly speaking, I am unsure concerning your configuration. Perhaps the 
following may make it more clear

     efibootmgr -v
     find /boot/efi | sort

It seems secure boot is disabled in your case, so I am wondering why you 
do not boot xen.efi directly.

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

#266934

On Sat, 3 Feb 2024, Max Nikulin wrote:

> It seems secure boot is disabled in your case, so I am wondering why you do 
> not boot xen.efi directly.
>
Because the NVRAM is extremely tempremental. Most updates fail, or
worse, corrupt it to the point it's hard to get anything to boot.

Additionally, there was a bug in an older version of xen that caused a
kernel oops if wifi networking was started. So I wanted to start vanilla
debian and I don't dare touch the NVRAM again (or the bios) until I
absolutely have to.

I don't remember for certain now but I might be booting using
bootx86.efi (which is a copy of grubx64.efi)

It's an old laptop but it still works well for me.

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

#266935

Tim Woodall composed on 2024-02-03 21:25 (UTC):

> Max Nikulin wrote:

>> It seems secure boot is disabled in your case, so I am wondering why you do 
>> not boot xen.efi directly.

> Because the NVRAM is extremely tempremental. 

Not in my experience. I recognized long ago that WRT non-removable media, only one
bootloader per machine is required, and pretty well stuck to having only one
active, or at all, no matter how many FOSS operating systems or media I have
installed. The Grubs I have used are not picky about whose kernel or initrd they
are called to load. With only one bootloader installed, retouching NVRAM isn't
often required, and there needn't be much in it to scramble.
-- 
Evolution as taught in public schools is, like religion,
	based on faith, not based on science.

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

Felix Miata

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

#266854

On Fri, 2 Feb 2024, Dmitry wrote:

> Hi Tim. The community is so kind.
>
> So.
>
>> I'm not exactly sure what you're doing.
>
> Understand how GRUB works, to boot myself.
>
> 1. Trying to install Debian on the Flash.
> 2. Use it by the Debootstrap.
> 3. Now I want to boot using that Flash.
>
> Looks like a caught the thread.
>
> 1. ESP is a partition that stores GRUB Binary. /boot/EFI/Name/grub64.eif
> 2. ==>BAM<== some how that binary knows the system partition.


because grub64.efi understands the disk layout and looks for it. You can
build your own

I'm not giving any guarantees - look at the date on this file:

$ ls -al test-uefi
-rw-r--r-- 1 tim tim 341 Dec 31  2018 test-uefi

$ cat test-uefi
grub-mkimage -o bootx64.efi -p /EFI/BOOT -O x86_64-efi \
  fat iso9660 part_gpt part_msdos \
  normal boot echo linux configfile loopback chain \
  efifwsetup efi_gop efi_uga \
  ls search search_label search_fs_uuid search_fs_file \
  gfxterm gfxterm_background gfxterm_menu test all_video loadenv \
  exfat ext2 lvm mdraid09 mdraid1x diskfilter

but that probably builds (or once worked) a .efi application that will
successfully boot a system by searching for grub.cfg. I don't remember
the details...

I also have this - take with a pinch of salt - I wrote this learning
about this system as you are trying to now...


$ ls -al uefi-notes
-rw-r--r-- 1 tim tim 2375 Dec  1  2018 uefi-notes

1 FDISK

g - create a new empty GPT partition table

p - create a primary partition
+128M (size)

t - change type
1 - EFI system

p - create primary partition
fill rest of disk

vgcreate vg-uefi-boot /dev/sdb2

lvcreate -L 128M -n boot vg-uefi-boot

lvcreate -l 100%FREE -n root vg-uefi-boot

mke2fs -j /dev/mapper/vg--uefi--boot-boot

mke2fs -j /dev/mapper/vg--uefi--boot-root

mkdosfs /dev/sdb1

mount /dev/vg-uefi-boot/root /mnt/image/

debootstrap --variant=minbase stretch /mnt/image ftp://einstein/debian/

mount -o bind /proc /mnt/image/proc
mount -o bind /dev /mnt/image/dev
mount -o bind /sys /mnt/image/sys

chroot /mnt/image <<EOF

echo boot.home.woodall.me.uk >/etc/hostname

cat <<EOFX >/etc/fstab
# /etc/fstab: static file system information.
#
# <file system>  <mount point>  <type>  <options>          <dump>  <pass>
/dev/vg-uefi-boot/root       /              ext3    errors=remount-ro  1       1
/dev/vg-uefi-boot/boot       /boot          ext3    defaults           1       2
UUID=D1EA-35CC               /boot/efi auto defaults,noatime,nofail 0 0
EOFX

mount /boot
mkdir /boot/efi
mount /boot/efi

#Don't install recommends
cat <<EOFX >/etc/apt/apt.conf.d/99-no-recommends
APT
{
   Install-Recommends "false";
}
EOFX

#Setup apt sources
cat <<EOFX >/etc/apt/sources.list
deb ftp://einstein/debian stretch main non-free
deb ftp://einstein/debian-security stretch/updates main non-free
deb ftp://einstein/local stretch main
EOFX

echo link_in_boot = Yes >/etc/kernel-img.conf

apt-get update
apt-get -y upgrade

apt-get -y install sysvinit-core
apt-get -y install openssh-server
apt-get -y install ifupdown
apt-get -y install grub-efi-amd64
apt-get -y install mdadm
apt-get -y install lvm2
apt-get -y install linux-image-amd64

grub-install

mkdir /boot/efi/EFI/BOOT
cp /boot/efi/EFI/debian/grubx64.efi /boot/efi/EFI/BOOT/bootx64.efi

update-grub

(update root password)

umount /boot/efi
umount /boot

EOF

umount /mnt/image/proc
umount /mnt/image/dev
umount /mnt/image/sys
umount /mnt/image/

vgchange -aln vg-uefi-boot

(Installed firmware-realtek)

mount /dev/vg-uefi-boot/root /mnt/image/
mount -o bind /proc /mnt/image/proc
mount -o bind /dev /mnt/image/dev
mount -o bind /sys /mnt/image/sys
chroot /mnt/image
mount -a

umount -a
exit

umount /mnt/image/proc
umount /mnt/image/dev
umount /mnt/image/sys
umount /mnt/image/
vgchange -aln vg-uefi-boot

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

#266861

On 02/02/2024 01:46, Dmitry wrote:
> 3. Now I want to boot using that Flash.
> 
> 1. ESP is a partition that stores GRUB Binary. /boot/EFI/Name/grub64.eif

On a *removable* drive EFI/Boot/bootx64.efi (that is actually 
/usr/lib/shim/shimx64.efi.signed that loads grubx64.efi) may allow to 
boot without modification of boot entries in NVRAM. Likely it is 
implementation-dependent whether a drive with GPT partition table is 
considered as a removable. For regular (internal) drives UEFI requires 
GPT. I do not suggest you to use msdos partition table that might be 
suitable for live media, not for installation with multiple partitions 
including Linux native file systems.

> 3. At the system partition there is a /boot/grub/grub.cfg

There are 2 grub.cfg: for ESP and for /boot

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

#266864

Max Nikulin schrieb:
> On a *removable* drive EFI/Boot/bootx64.efi (that is actually 
> /usr/lib/shim/shimx64.efi.signed that loads grubx64.efi) may allow to 
> boot without modification of boot entries in NVRAM.
Yes, UEFI can (and must be able) to boot from a device without a boot 
entry in the UEFI. Otherwise you wouldn't be able to install an OS.
You can boot such a device by simply selecting the device in the UEFI 
boot manager. Often it shows the model number of the device.
> Likely it is implementation-dependent whether a drive with GPT 
> partition table is considered as a removable. For regular (internal) 
> drives UEFI requires GPT.
MBR should also work.

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

#266930

Main question is resolved.

GRUB knows how to reach grub.cfg because grubx64.efi binary has the UUID and 
path to grub configurations.

1. sudo blkid;
2. sudo bash
3. cd /boot/efi/EFI/Mangaro
4. strings grubx64.efi
5. And at the output of strings there is UUID and /boot/grub.

Summary: GRUB installation not only involves configuration of text files, but
also it involves generating data in binary grubx64.efi.

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

#266944

On 03/02/2024 22:32, Dmitry wrote:
> 2. sudo bash

sudo -i

> 3. cd /boot/efi/EFI/Mangaro
> 4. strings grubx64.efi
> 5. And at the output of strings there is UUID and /boot/grub.

I am unsure what UUID you mean.

> Summary: GRUB installation not only involves configuration of text 
> files, but
> also it involves generating data in binary grubx64.efi.

It would not work with secure boot

md5sum /boot/efi/EFI/debian/grubx64.efi 
/usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed
62ff1ee5b75b4565f609043c4b1da759  /boot/efi/EFI/debian/grubx64.efi
62ff1ee5b75b4565f609043c4b1da759 
/usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed

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

#266970

> sudo -i

Thank you!


> I am unsure what UUID you mean.

At Manjaro:

grubx64.efi is at the sdb1 - EFI vfat /dev/sdb1
grub.cfg is at the sdb2 - crypto_LUKS /dev/sdb2

grubx64.efi contains data UUID=""a8...b7" of /dev/sdb2 which is 
TYPE="crypto_LUKS".

`blkid` output:
/dev/sdb2: UUID="a8...b7" TYPE="crypto_LUKS" PARTUUID="8...5"

`strings /boot/efi/EFI/Manjaro/grub64x.efi` output:
cryptomount -u a8...b7
(cryptouuid/a8...b7)/boot/grub

I have a Manjaro installed, and what to migrate to Debian. That involves 
exploration of Booting order.

In the Manjaro GRUB installation mounting point for ESP (sdb1) is:
/boot/efi
And the grub.cfg is
/boot/grub/grub.cfg

The grub.cfg located at the crypto partition sdb2.

Manjaro has different GRUB installation scheme from Debian.

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

#266975

 > It would not work with secure boot

Yes.

But secure boot is usually turned off. It is a standard advice during Linux 
installation.

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

#266977

On Mon, 2024-02-05 at 17:40 +0700, Dmitry wrote:
> 
> But secure boot is usually turned off. It is a standard advice during
> Linux 
> installation.
> 
Will probably be increasingly common though, I've got a Microsoft
Surface Laptop that works fine with Debian, but if you switch off
secure boot, it displays some big red scary warning screen before the
bootloader.

/ralph

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

#266981

On 05/02/2024 17:40, Dmitry wrote:
>  > It would not work with secure boot
> 
> Yes.
> 
> But secure boot is usually turned off. It is a standard advice during 
> Linux installation.

That advice may be standard for distributions that do not provide signed 
shim and grub. Likely it is applicable for Arch and derivatives. Debian 
supports installation with enabled secure boot.

At first I suspected that you enrolled your own MOK and maybe even wiped 
out Microsoft keys.

Perhaps you may get encrypted /boot in Debian similar to what you have 
in Manjaro, but certainly it is not default configuration.

[toc] | [prev] | [standalone]

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

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

csiph-web