Replies: 1 comment
-
Alternative solution to the problem described in the guilty patch but without triggering the bug is to use partition LABEL (PARTLABEL) in the installer's
The various labels and UUID's used in the installation image can be seen as here: # setup loopback device and partitions within
$ sudo losetup /dev/loop0 --partscan Fedora-Silverblue-ostree-x86_64-41-1.4.iso
# output properties of the block devices
$ lsblk /dev/loop0 -o PTUUID,UUID,LABEL,PARTUUID,PARTLABEL
PTUUID UUID LABEL PARTUUID PARTLABEL
231b25b1-67e7-4891-a286-1c3ee4f39909 2024-10-24-14-37-30-00 Fedora-SB-ostree-x86_64-41
231b25b1-67e7-4891-a286-1c3ee4f39909 2024-10-24-14-37-30-00 Fedora-SB-ostree-x86_64-41 231b25b1-67e7-4891-a287-1c3ee4f39909 ISO9660
231b25b1-67e7-4891-a286-1c3ee4f39909 BA81-F12E ANACONDA 231b25b1-67e7-4891-a284-1c3ee4f39909 Appended2 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Fedora's .ISO installer images also contain appended vfat EFI System Partition (ESP) in it.
The boot.iso typically has the following structure:
The problem is, that sda2 vfat ANACONDA partition can never be mounted by Anaconda installer, as the whole sda disk is mounted as rootfs first.
This is regression introduced by https://pagure.io/centos-sig-hyperscale/anaconda/c/301a09d06ee0f0df7a3a1c818d7051f31a12bbd1?branch=4532ca0cb394c5ed0eb3b99865adff9b98d6adb7
301a09d "Never mount partitions on a disk with the iso9660 filesystem (#1878784)"
I deem it quite severe as that vfat EFS was the only handy place for custom Kickstart ks.cfg file, if user flashes the .ISO to SD card or USB drive.
More details:
https://bugzilla.redhat.com/show_bug.cgi?id=2346192
@poncovka
Beta Was this translation helpful? Give feedback.
All reactions