Identify and match existing partitions based on label
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 974
- Forks
- 296
- Avg merge
- 6d 14h
- Merged PRs (30d)
- 9
Description
Feature Request
Currently if I have a butane config like:
variant: fcos
version: 1.3.0
storage:
disks:
- device: /dev/sda
wipe_table: false
partitions:
- number: 0
label: root
size_mib: 12000
resize: true
- number: 0
label: var-home
size_mib: 10240
filesystems:
- path: /var/home
device: /dev/disk/by-partlabel/var-home
format: xfs
wipe_filesystem: false
label: var-home
with_mount_unit: true
I assume that the label: root entry will match the existing partition with the root label and apply specified changes to that partition.
What I end up with is two partitions with a root partition label and my actual root partition is the minimal 1.8G:
[dustymabe@media images]$ ssh core@192.168.122.31
Warning: Permanently added '192.168.122.31' (ECDSA) to the list of known hosts.
Fedora CoreOS 34.20210427.3.0
############################################################################
WARNING: The root filesystem is too small. It is strongly recommended to
allocate at least 8 GiB of space to allow for upgrades. From June 2021, this
condition will trigger a failure in some cases. For more information, see:
https://docs.fedoraproject.org/en-US/fedora-coreos/storage/
You may delete this warning using:
sudo rm /etc/motd.d/60-coreos-rootfs-size.motd
############################################################################
Tracker: https://github.com/coreos/fedora-coreos-tracker
Discuss: https://discussion.fedoraproject.org/c/server/coreos/
[core@localhost ~]$
[core@localhost ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 40G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 127M 0 part
├─sda3 8:3 0 384M 0 part /boot
├─sda4 8:4 0 1.8G 0 part /sysroot
├─sda5 8:5 0 11.7G 0 part
└─sda6 8:6 0 10G 0 part /var/home
[core@localhost ~]$
[core@localhost ~]$ sudo blkid
/dev/sda3: LABEL="boot" UUID="faa1e08b-44cb-4b22-9fe6-0ec9c7809e1c" BLOCK_SIZE="1024" TYPE="ext4" PARTLABEL="boot" PARTUUID="e694bc20-c397-4c1c-8a9a-a2e585878d18"
/dev/sda4: LABEL="root" UUID="621d6ca4-75e2-4a88-ae98-6d100840ddfc" BLOCK_SIZE="512" TYPE="xfs" PARTLABEL="root" PARTUUID="b081bc27-7fe4-473c-b1ad-7d19dc575d95"
/dev/sda1: PARTLABEL="BIOS-BOOT" PARTUUID="67c1015f-668a-48ce-aea4-e34836df4582"
/dev/sda2: SEC_TYPE="msdos" LABEL_FATBOOT="EFI-SYSTEM" LABEL="EFI-SYSTEM" UUID="24F3-E9D4" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI-SYSTEM" PARTUUID="6b80bc4c-caad-4eaa-b57d-e9ec319cddc5"
/dev/sda5: PARTLABEL="root" PARTUUID="2bb02c19-239f-42e1-bcbc-981ad69a7138"
/dev/sda6: LABEL="var-home" UUID="d6b014ed-81cd-4cba-9811-a496e1ca844f" BLOCK_SIZE="512" TYPE="xfs" PARTLABEL="var-home" PARTUUID="a64dda2d-910a-4be0-890a-91e0ae9092c9"
We should probably try to match entries to existing labels. Also maybe we should just enforce that partition labels are unique such that there can't be more than one partition with that label.
Other Information
[core@localhost ~]$ rpm-ostree status
State: idle
AutomaticUpdatesDriver: Zincati
DriverState: active; trying to stage 34.20210518.3.0 (1 failed deployment attempt)
Deployments:
● ostree://fedora:fedora/x86_64/coreos/stable
Version: 34.20210427.3.0 (2021-05-18T08:56:57Z)
Commit: b4b2199ec09b9e4200024b52062b119035a06b3ffc27b4268c5b8c3aa6fcde17
GPGSignature: Valid signature by 8C5BA6990BDB26E19F2A1A801161AE6945719A39
[core@localhost ~]$ rpm -q ignition
ignition-2.9.0-4.fc34.x86_64
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue does not name files, tests, or an entry point. Start by locating Ignition's storage partition handling and reviewing how requested partitions are created, then clarify whether labels should match existing partitions, be unique, or both; done should include defined behavior for duplicate labels and coverage for the reported configuration.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- operating-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100