Re: uefi boot install and disk partitions

[Cindy Sue Causey]

On 1/5/20, to...@tuxteam.de  wrote:
> On Sun, Jan 05, 2020 at 10:47:52AM +0100, Pascal Hambourg wrote:
>> Le 04/01/2020 à 20:47, Sven Joachim a écrit :
>
> [FAT, hard links]
>
>> >a feature that is crucial for dpkg.
>>
>> I vaguely remember this, but not when and why dpkg needs to create
>> additional hard links. Can you refresh my memories ?
>
> My search engine is lucky today (no, Goog, no cookies for you today ;-)
>
>
> https://unix.stackexchange.com/questions/208073/dpkg-replacing-files-on-a-fat-filesystem
>
> I'd be more worried about whatever packagers do in their post-install
> scripts. After all, hard links are pretty handy when trying to do
> atomic operations on file systems. If there's no policy explicitly
> banning hard links, I'd expect them to be used...


DISCLAIMER: HOPEFULLY I'm understanding the use of "hard links" here
such as has been my understanding of that topic for *many* years.. :)

For the most part, I thought about the only problem with hard links
was that whatever was using them had to exit an entire hierarchy to
then dig back in from the top to find its target. That comes from my
earliest days of creating anchor links in web design where you're
trying to help your webpages load as fast as possible for the end
user.

As I was sitting pondering this, two thoughts keep floating in my head...

1) Maybe this, primarily the "fat" part of it, somehow explains why
rsync flat out refused to copy a limited number of files over to a USB
for me a few ago. Happened a couple times in different situations. I
can't remember how to recreate it to say yay or nay on it having been
about this topic.

2) A couple years ago, my linux-image installations on debootstraps
were creating "hard" /vmlinuz and /initrd.img links. At some point in
my decades' old perennial newbie-ness, I accidentally stumbled on a
usage case where that very detrimentally linked out of my chroot
somehow... and was targeting my host's /boot directory, i.e. NOT the
intended /mnt/deboostrap/boot directory which it SHOULD have been
seeking, instead...

To this day to fix it, one of my early-on debootstrap checklist points
is to consciously verify that /vmlinuz and /initrd.img symlinks are
being used instead of hard links immediately after apt/apt-get is
finished installing linux-image. Apparently a Developer at some point
noticed the same on some level because I haven't had to create new
links there in a LONG time now.

In wondering how I would have caught that major whoa, maybe it was
that the hard link was reflecting the different kernel version. That
sounds like the most likely way a User would catch that kind of
[anomaly].

Maybe "fat" is trying to (intelligently, proactively) protect us
from the rare occasion something like my experience might occur??

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with... a... seriously... more backup modems... NOW. Because
weather-util says another thunderstorm is in the queue this week.
*

Re: uefi boot install and disk partitions

[Pascal Hambourg]

Le 05/01/2020 à 11:00, to...@tuxteam.de a écrit :

On Sun, Jan 05, 2020 at 10:47:52AM +0100, Pascal Hambourg wrote:

Le 04/01/2020 à 20:47, Sven Joachim a écrit :


[FAT, hard links]


a feature that is crucial for dpkg.


I vaguely remember this, but not when and why dpkg needs to create
additional hard links. Can you refresh my memories ?


   
https://unix.stackexchange.com/questions/208073/dpkg-replacing-files-on-a-fat-filesystem


Thanks. I would be very careful when using a hard link to back up a file 
before replacing it, because it depends on the method used to replace 
the original file with the new file. For example plain 'cp' or shell 
redirection does not break the link and overwrites the contents of the 
original file (and of the hard link), whereas 'cp -d' breaks the link 
and creates a new file.



I'd be more worried about whatever packagers do in their post-install
scripts. After all, hard links are pretty handy when trying to do
atomic operations on file systems.


What kind of atomic operations ?

Re: uefi boot install and disk partitions

[tomas]

On Sun, Jan 05, 2020 at 10:47:52AM +0100, Pascal Hambourg wrote:
> Le 04/01/2020 à 20:47, Sven Joachim a écrit :

[FAT, hard links]

> >a feature that is crucial for dpkg.
> 
> I vaguely remember this, but not when and why dpkg needs to create
> additional hard links. Can you refresh my memories ?

My search engine is lucky today (no, Goog, no cookies for you today ;-)

  
https://unix.stackexchange.com/questions/208073/dpkg-replacing-files-on-a-fat-filesystem

I'd be more worried about whatever packagers do in their post-install
scripts. After all, hard links are pretty handy when trying to do
atomic operations on file systems. If there's no policy explicitly
banning hard links, I'd expect them to be used...

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: uefi boot install and disk partitions

[Pascal Hambourg]

Le 04/01/2020 à 20:47, Sven Joachim a écrit :

On 2020-01-04 13:38 +0100, Pascal Hambourg wrote:


Some new boot specification mounts the EFI partition on /boot


Citation needed, which specification is that?


Freedesktop/systemd's Boot Loader Specification.

now 

Also mentionned in the Discoverable Partitions Specification.




but Debian does not follow it (yet) and still
mounts the EFI partition on /boot/efi.


There are good reasons for not mounting the EFI system partition on
/boot, the most important one is that FAT filesystems do not support
files with multiple hard links,


You mean that FAT filesystems do not support hard links at all. The 
concept of hard link requires some level of indirection between a 
directory entry and a file. In common Unix-like filesystems such as 
ext*, this is provided by inodes structures which contain the file 
metadata. FAT filesystems do not have such indirection and the file 
metadata are contained in the directory entry instead.



a feature that is crucial for dpkg.


I vaguely remember this, but not when and why dpkg needs to create 
additional hard links. Can you refresh my memories ?

Re: uefi boot install and disk partitions

[Sven Joachim]

On 2020-01-04 13:38 +0100, Pascal Hambourg wrote:

> Le 04/01/2020 à 11:25, Bonno Bloksma a écrit :
>
>> If I had not created that /boot partition would those files be in
>> /boot folder on the / (root) partition or would /boot then be on the
>> EFI partition?
>
> On the root partition. Some new boot specification mounts the EFI
> partition on /boot

Citation needed, which specification is that?

> but Debian does not follow it (yet) and still
> mounts the EFI partition on /boot/efi.

There are good reasons for not mounting the EFI system partition on
/boot, the most important one is that FAT filesystems do not support
files with multiple hard links, a feature that is crucial for dpkg.

Cheers,
   Sven

Re: uefi boot install and disk partitions

[Harry Putnam]

Bonno Bloksma  writes:

> Hi,
>
>
>
> I have been creating a small (300MB) primary /boot partition at the
> beginning of the disk for as long as I can remember... That is after
> disks got to be too big for the BIOS to reach all of the disk to be
> able to boot from a file anywhere on the disk.
>
> So far so good, that still works but do I still need that
> partition when I create an EFI System Partition (ESP) to boot using
> UEFI?
>

[...]

First off, I'm pretty sure that Pascal is far more knowledgeable than I
but I just had some experience with setting up  Uefi.  Still working
on it so not tested yet.

It is on a zfs-on-root-linux install so that might be different. But
the part of preparing the disk for booting seems to be the same.

I used `gsdisk' which is in the package `gdisk' in the debian repo.

There are detailed direction by Richard Laager:

I'm quoting a small bit from URL:

https://github.com/zfsonlinux/zfs/wiki/Debian-Buster-Root-on-ZFS

2.3 Partition your disk(s):

  [...] section on non efi boot snipped

   Run this for UEFI booting (for use now or in the future):

   sgdisk -n2:1M:+512M   -t2:EF00 $DISK

   Run this for the boot pool:

   sgdisk -n3:0:+1G  -t3:BF01 $DISK

He's taking about a zpool setup but I think Its the same far as
preparing the disk for uefi booting.

There are more details further on concerning actually installing the
boot code on the disk where booting will occur.  You probably want to
read this part:

   4.8b Install GRUB for UEFI booting 

Re: uefi boot install and disk partitions

[Pascal Hambourg]

Le 04/01/2020 à 11:25, Bonno Bloksma a écrit :


I have been creating a small (300MB) primary /boot partition at the beginning 
of the disk for as long as I can remember... That is after disks got to be too 
big for the BIOS to reach all of the disk to be able to boot from a file 
anywhere on the disk.

So far so good, that still works but do I still need that partition when I 
create an EFI System Partition (ESP) to boot using UEFI?


A separate /boot is required only if GRUB cannot read the root 
filesystem. Possible reasons include :

- root device not supported by the firmware
- root filesystem type not supported by GRUB
- root device type not supported by GRUB (e.g. RAID linear, maybe some 
LVM volume types)

- encrypted root device


If I had not created that /boot partition would those files be in /boot folder 
on the / (root) partition or would /boot then be on the EFI partition?


On the root partition. Some new boot specification mounts the EFI 
partition on /boot but Debian does not follow it (yet) and still mounts 
the EFI partition on /boot/efi.



Do I still need that /boot partition now that the ESP has the boot flag set?


The EFI partition has no boot flag. If you are using parted or Gparted, 
the boot flag is only a virtual representation of the EFI partition type.



Do I still want it?


You may still want a separate plain /boot partition for safety when the 
root uses some complex setup such as LVM even though it is supported by 
GRUB.

uefi boot install and disk partitions

[Bonno Bloksma]

Hi,



I have been creating a small (300MB) primary /boot partition at the beginning 
of the disk for as long as I can remember... That is after disks got to be too 
big for the BIOS to reach all of the disk to be able to boot from a file 
anywhere on the disk.

So far so good, that still works but do I still need that partition when I 
create an EFI System Partition (ESP) to boot using UEFI?



The automatic disk partitioning created a 500M EFI partition that only has 5M 
files on it, on my 300M boot partition are another 49M files.

If I had not created that /boot partition would those files be in /boot folder 
on the / (root) partition or would /boot then be on the EFI partition?

Do I still need that /boot partition now that the ESP has the boot flag set?

Do I still want it?



The current layout of my 1TB SSD on which I still have some free space inside 
my LVM vgroup.

root@linbobo:~# df -h

FilesystemSize  Used Avail Use% Mounted on

udev  7.8G 0  7.8G   0% /dev

tmpfs 1.6G  8.9M  1.6G   1% /run

/dev/mapper/linbobo--vg-root   23G  815M   21G   4% /

tmpfs 7.8G 0  7.8G   0% /dev/shm

tmpfs 5.0M 0  5.0M   0% /run/lock

tmpfs 7.8G 0  7.8G   0% /sys/fs/cgroup

/dev/sda2 237M   49M  176M  22% /boot

/dev/mapper/linbobo--vg-var   9.2G  188M  8.5G   3% /var

/dev/mapper/linbobo--vg-tmp   1.8G  5.6M  1.7G   1% /tmp

/dev/sda1 511M  5.1M  506M   1% /boot/efi

/dev/mapper/linbobo--vg-home  500G   73M  474G   1% /home

tmpfs 1.6G 0  1.6G   0% /run/user/0

tmpfs 1.6G 0  1.6G   0% /run/user/1000



I read https://wiki.debian.org/UEFI but that does not answer my questions above.



Bonno Bloksma