Page MenuHomeVyOS Platform

install image doesn't respect chosen root partition size
Closed, ResolvedPublicBUG

Description

When trying to install VyOS on a new empty SSD, using the install image command, and specifying a specific size for the root partition, this is ignored and it ends up using the full drive size.

As far as I can tell, the culprit is the "create_partitions" function in the install-get-partition script. This contains:

##Do GPT/EFI Setup
       sgdisk --zap-all /dev/$ldrive
       # part1 = BIOS BOOT (backwards compatibility)
       # part2 = EFI
       # part3 = ROOT
       sgdisk -a1 -n1:34:2047   -t1:EF02 \
           -n2:2048:+256M -t2:EF00 \
           -n3:0:0:+$root_part_size -t3:8300 /dev/$ldrive

The last line seems to contain a mistake, and should likely be -n3:0:+$root_part_size -t3:8300 /dev/$ldrive (so one :0 too many). This would take the next available largest chunk of free space and create a partition of the given $root_part_size.

Details

Difficulty level
Unknown (require assessment)
Version
-
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Unspecified (please specify)

Event Timeline

Viacheslav changed the subtype of this task from "Task" to "Bug".Feb 20 2022, 7:45 PM
Viacheslav added a subscriber: Viacheslav.

Which version?

This is on a fresh ISO build of 1.3, but looking at Github, the same parts are in the current branch and the equuleus branch of the vyatta-cfg-system repo.

sgdisk man says -n should have a partition number followed by start/end values. Looking at the code this bug is present in all versions 1.2 and above.

I wasn't able to reproduce the issue.
I installed 3 times VyOS 1.3.0 version on Proxmox:

  1. Installed using 2.5G, and got expected results
  2. Installed using 6.5G and got expected results
  3. Installed using default settings (all hdd space), and got expected results.

I also tested similar procedure installing VyOS 1.4-rolling-202201180317 on Virtualbox, and always got root partition as expected

@pvanberlo Can you share more info on how we can reproduce this issue?

I can't add anything else unfortunately, it just doesn't work for me on a physical device whichever value I enter, it always takes the remainder of the free space for the root partition. Manually modifying it works fine.

The man page for sgdisk states:

-n, --new=partnum:start:end

The script contains:

sgdisk -a1 -n1:34:2047   -t1:EF02 \
           -n2:2048:+256M -t2:EF00 \
           -n3:0:0:+$root_part_size -t3:8300 /dev/$ldrive

Which means partnum = 3, start = 0, and end = 0. Start and end being 0 according to the man page results in taking the largest continuous available of diskspace, which is the remainder of the drive. The last part after the last colon seems to be ignored. From the man page:

A start or end value of 0 specifies the default value, which is the start of the largest available block for the start sector and the end of the same block for the end sector.

sarthurdev changed the task status from Open to Confirmed.Feb 24 2022, 11:51 AM
sarthurdev claimed this task.

@n.fort I have been able to reproduce this, it only occurs when installing for UEFI.

...
Install the image on? [sda]:

This will destroy all data on /dev/sda.
Continue? (Yes/No) [No]: yes

Looking for pre-existing RAID groups...none found.
Looking for config files from previous installations on sda1...
How big of a root partition should I create? (2000MB - 4294MB) [4294]MB: 2000
...
vyos@vyos:~$ fdisk -l
Disk /dev/sda: 4 GiB, 4294967296 bytes, 8388608 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: B6E35C17-1348-4F41-BD53-82E3052F0A73

Device      Start     End Sectors  Size Type
/dev/sda1      34    2047    2014 1007K BIOS boot
/dev/sda2    2048  526335  524288  256M EFI System
/dev/sda3  526336 8388574 7862239  3.7G Linux filesystem

Closing this task since it has been in "Needs Testing" status for more than one year, for both 1.3 and 1.4 projects.