s390x images fail to build Could not get file mapping

Bug #1716060 reported by Dimitri John Ledkov
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cloud-images
Fix Released
Undecided
Unassigned
launchpad-buildd
Fix Released
Undecided
Unassigned

Bug Description

s390x images need to install zipl bootloader code.
Most of the parameters are pre-guessed and populated via command line switches.
However, zipl code currently does FIBMAP ioctl call on the target disk to figureout physical system block.

One option is to check if the new confinement allows the ioctl(fd, FIBMAP, &mapped) to succeed on the loop mounted device filesystem, or causes a deny / reject.

Another option, I can run the build locally and check what the answer should be and add command line switches to pass the answers to zipl without it doing FIBMAP ioctl inspection.

/* Get mapping in file system blocks */
phy_per_fs = info->fs_block_size / info->phy_block_size;
mapped = logical / phy_per_fs;
subblock = logical % phy_per_fs;
if (ioctl(fd, FIBMAP, &mapped)) {
 error_reason("Could not get file mapping");
 return -1;
}
if (mapped == 0) {
 /* This is a hole in the file */
 *physical = 0;
} else {
 /* Convert file system block to physical */
 *physical = mapped * phy_per_fs + subblock;
 /* Add partition start */
 *physical += info->geo.start;
}

Related branches

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

I have tweaked zipl to do a perror, and did a build out of a PPA. This resulted in:

+ chroot mountpoint /sbin/zipl -V --image=/boot/vmlinuz --ramdisk=/boot/initrd.img --parameters=root=LABEL=cloudimg-rootfs --target=/boot/ --targetbase=/dev/loop0 --targettype=SCSI --targetblocksize=512 --targetoffset=2048
Could not get file mapping.: Operation not permitted

As expected. Checking kernel code, it does this:

52static int ioctl_fibmap(struct file *filp, int __user *p)
 53{
 54 struct address_space *mapping = filp->f_mapping;
 55 int res, block;
 56
 57 /* do we support this mess? */
 58 if (!mapping->a_ops->bmap)
 59 return -EINVAL;
 60 if (!capable(CAP_SYS_RAWIO))
 61 return -EPERM;
 62 res = get_user(block, p);
 63 if (res)
 64 return res;
 65 res = mapping->a_ops->bmap(mapping, block);
 66 return put_user(res, p);
 67}

Thus this suggests that !capable(CAP_SYS_RAWIO) is not available, and this capability is checked against root user-space (as in real root should have CAP_SYS_RAWIO). And this does sound scary that this is allowed on the devirt livefs builds on s390x....

To get cpc builds going please allow this capability, on s390x, as it was before. Meanwhile I will work on extending zipl command + matching livecd-rootfs SRUs to avoid using FIBMAP by providing pre-calculated values that it tries to inspect.

Colin Watson (cjwatson)
affects: launchpad → launchpad-buildd
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

<cjwatson> xnox: so I guess maybe https://paste.ubuntu.com/25514117/
<xnox> cjwatson, that works \o/ can that be landed please =)

Colin Watson (cjwatson)
Changed in launchpad-buildd:
status: New → Fix Committed
Revision history for this message
Colin Watson (cjwatson) wrote :

launchpad-buildd (152) xenial; urgency=medium

  [ Colin Watson ]
  * Accept a "debug" entry in livefs arguments, which enables detailed
    live-build debugging.
  * Set SHELL=/bin/sh in snap builds, since it was previously passed through
    by the chroot backend and some build systems expect SHELL to be set
    (LP: #1716739).

  [ Robert C Jennings ]
  * LXD: Do not drop sys_rawio capability (LP: #1716060).

 -- Colin Watson <email address hidden> Wed, 13 Sep 2017 14:51:48 +0100

Changed in launchpad-buildd:
status: Fix Committed → Fix Released
Dan Watkins (oddbloke)
Changed in cloud-images:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.