mkswap lives in sys-apps/util-linux. From util-linux>=2.15.1 on, mkswap will issue a warning when the parameter is a “whole disk”: mkswap: /dev/mapper/swap: warning: don't erase bootbits sectors on whole disk. Use -f to force. This issue is mainly cosmetic: swap areas don’t use the first block on the disk or partition they’re on. Nevertheless, to keep people and bootloaders from trying to boot a swap partition, mkswap usually deletes the first block (or “clears” or “zaps” it, since you can’t delete blocks), but only if there is no disk label or partition table or the like on it. However, if the parameter is not a partition, but a whole disk, mkswap issues the warning above. Since a dmcrypt volume apparently is handled like being a whole disk, the warning occurs there as well. /lib/rcscripts/addons/dm-crypt-start.sh should use “mkswap -f” to create swap volumes. Currently, line 34 says: : ${pre_mount:='mkswap ${dev}'} Insert a -f there, and everything should be fine. Oh, and while you’re at it: Please show some love for bug #257556 as well. It’s a small patch that will make multi-dmcrypt-volumes users happy. Workaround for users: Add pre_mount='mkswap -f ${dev}' after the “source” line of your swap definition in /etc/conf.d/dmcrypt.
*** Bug 288272 has been marked as a duplicate of this bug. ***
Created attachment 231595 [details, diff] use mkswap -f
(In reply to comment #2) > Created an attachment (id=231595) [details] > use mkswap -f > As you noted "pre_mount" will take care of the warning. However, I wouldn't call it a workaround as the option is provided just for this kind of situations: # pre_mount='cmds' == commands to execute before mounting partition. So you can be flexible enough without hard coding the script. IMO this is not a bug.
he isnt hardcoding the script ... simply changing the default i'm not entirely sold that this is a good idea. the -f option will cause other sanity checks to be ignored. i think requiring people who hit this to set -f themselves in their conf.d is OK.
*** Bug 436972 has been marked as a duplicate of this bug. ***