I would _asume_ it could not be "EBUSY" as I see nothing in the script that would mount the drive... Again: this is the script, not custom. This is 100% reproducable in all my setups: just try using the defaults from the installer, and you should hit this.
This occurs immediately after partitioning, which _does_ succeed. - you say "some configurations" - try the DEFAULT. Let it wipe the HD, partition, and: fail. A guess, but ... one that makes no sense: Surely it isn't one of those "old kernel" type problems where the new partition scheme isn't known, and therefore, kernel can't find the partition that the script expects? I haven't seen one of those issues for... over 15 years (: On Sun, Jun 13, 2021 at 03:12:32PM +0200, Ludovic Courtès wrote: > Hi, > > Mathieu Othacehe <[email protected]> skribis: > > > The "free-parted" procedure that makes sure that all the partitions are > > created and not in use probably fails in some configurations. Otherwise, > > I cannot understand why the "mkswap" binary would fail. > > Do we know why ‘mkswap’ exited with code 1, though? EBUSY or could it > be something else? > > Thanks, > Ludo’. >
