Enumerating disks and partitions

[Sebastian Roth]

Starting a new discussion about this topic as Tom has put in some work into getting this important part of FOG to work with new things like eMMC, ePCI SSDs and what not. I feel that we should discuss things and post new findings to improve this even more.

I started looking into different methods of enumeration. Two seam interesting: lsblk and the information in /sys/block and accordingly /sys/class/block. After some research and testing I think we are on the right track with lsblk already! The sysfs information is great too but more complex to parse. lsblk is using the sysfs anyway.

Interesting things I came across:

• lsblk -I 3,8,9,... to only see devices with those major device ids (so we need less awk foo!)
• lsblk -o TYPE to distinguish between ‘disk’ and ‘part’ without trying to guess on the basis of minor device id or even device names like ‘mmcblk0boot0p1’. This seams to work with those new devices as well as we see here: https://communities.intel.com/thread/57157?start=0&tstart=0
• We might also be able to handle raid/md (http://linuxaria.com/pills/linux-shelllsblk) and logical volumes (http://unix.stackexchange.com/questions/90290/how-to-display-all-the-partitions-in-a-tree-like-format-primary-extended-and-l#90298) using the TYPE.

I am still not sure how to handle those mmcblk0boot0 disks. At first I thought they are used raw (dump bootloader straight to disk) but I haven’t found enough information to confirm. On the other hand I hardly find information about those disks really being partitioned. Seams like you can. But is this really used? Should we up/download those disks raw as they are very small anyway or better ignore them completely (as well as mmcblk0rpmb)? Does anyone know more about this?

[Sebastian Roth]

@Tom-Elliott Have you looked into using some of those options yet?

[Tom Elliott]

@Sebastian-Roth I believe we are already though I need help looking over the scripts. I’ve done a lot and I fear I’m now probably doing more harm than good.

[Tom Elliott]

All -o TYPE does is show the “type” in the list. so the way I’m enumerating partitions from the disk is:

 # $1 is the partition to search for.
 getPartitions() {
     local disk="$1"
     [[ -z $disk ]] && disk="$hd"
     [[ -z $disk ]] && handleError "No disk found (${FUNCNAME[0]})"
     local valid_parts=""
     allparts="$(fdisk -l $disk | awk '{if ($1 ~ "'$disk'" && $1 ~ /[0-9]+$/) print $1}' |   sort -V | uniq)"
     for checkpart in $allparts; do
         [[ $checkpart =~ mmcblk[0-9]+boot[0-9]+ ]] && continue
         valid_parts="$valid_parts $checkpart"
     done 
     parts=$(trim $valid_parts)
 }

So you pass it the disk, and it provides the partitions. All partitions should end in a numeric value, at least as far as disk layout is concerned in linux, so this method works.

For now I’m just not pulling the parts if the disk is mmcblk[0-9]+boot.

[Sebastian Roth]

Why did you decide to use fdisk instead of lsblk? From my understanding of linux and those tools I’d say that fdisk might cause more issues than lsblk would. Thinking about GPT and minor hickups in a partitioning schema. lsblk is more likely to show the partition names without doing much checks on them before.

[Tom Elliott]

@Sebastian-Roth I went with fdisk because the version in the init’s has support for GPT already. Also, I needed a more accurate way to get the partitions without having to try to filter which, or which not, is the disk. While the lsblk could do the -o option, it still needed to be filtered to get the relevant data.

so lsblk -I 3,8,9,179,259 -dpno KNAME,TYPE | awk '{if ($2 =~ /part/) print $1}' could work, but would be very rough, at least when I was attempting things.

[Sebastian Roth]

Well, let’s hope that fdisk is not doing any unnecessary checks causing us issues then…

The function itself looks pretty straight forward, I like it this way.