Description of problem:Booting F10 LiveCD kills encrypted swap partition on existing system already installed to HD Version-Release number of selected component (if applicable):initscripts-8.86-1.i386.rpm How reproducible:Every time Steps to Reproduce: 1. On machine with encrypted swap partition boot F10 LiveCD 2. Work with LiveCD then reboot to main system from HD 3. Repeated requests for luks passphrase (actually prompt is "password:") 4. System eventually boots but system has no swap partition active. Actual results: System does boot but without a swap partition since the liveCD had hosed the luks encryption on the swap area, and the main boot process then fails to find the luks mapped swap partition and so boots without a swap area. Expected results: LiveCD should either recognise that the swap area is encrypted and request the passphrase, or continue to boot without using the swap partition, or at least give the user that option. However, if the encrypted swap area is used correctly during liveCD boot, and mkswap not executed on the raw partition then the consequence may be to have a bad effect on the main system during a subsequent recovery from suspend if the main system had been suspended prior to running the liveCD, and then an attempt is made to come out of suspend. Hence the better option is to not use the swap area if it is encrypted. At the very minimum the user should be warned that continuing with the current boot could hose the swap area with the current rc.sysinit script. Additional info:A beginner to Linux would be unlikely to recover from a hosed swap area in this scenario so the rc.sysinit file should be changed to accommodate this bad consequence, even though there will only be a small number of users who would hit this combination of circumstances. However booting a liveCD that can hose your swap partition should not be allowed to happen - running a liveCD should be a safe way to do things. Beyond a rawhide liveCD or possibly a pre-release liveCD one would not expect such bad things to happen with a released liveCD and this need to be fixed before any f11 liveCD is released.
This bug has been triaged
This is a bug in libblkid. We just ask for all swap devices and the encrypted swap dev should show up as being luks as opposed to the fact that it used to be swap/is swap underneath. I know esandeen and I talked about it, but I'm not finding the other bug.
(In reply to comment #2) > This is a bug in libblkid. We just ask for all swap devices and the encrypted > swap dev should show up as being luks as opposed to the fact that it used to be > swap/is swap underneath. Because the device is *valid* swap device and also *valid* luks device :-). See the bug referenced below. > I know esandeen and I talked about it, but I'm not finding the other bug. Yeah, it sounds as a duplicate of bug 473514 - "LiveCD (on usb) ate an existing encrypted partition".
Well crud. There's also Bug 468062 - Encrypted LV has mismatching UUID So IIRC we had patches for both cryptsetup and for anaconda to zero out before creating the luks partition ... need to look and see if these both got committed in time for F10 I think. And for swap made prior to that fix, then what ...
Was the swap partition in question made prior to F10's release? Overwriting swap w/ LUKS seems ok now: [root@test tmp]# mkswap /dev/loop0 Setting up swapspace version 1, size = 131068 KiB no label, UUID=f4d7a2ec-785b-4fd9-94cf-d73910bfaca0 [root@test tmp]# hexdump -C /dev/loop0 | head -n 10 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000400 01 00 00 00 ff 7f 00 00 00 00 00 00 f4 d7 a2 ec |................| 00000410 78 5b 4f d9 94 cf d7 39 10 bf ac a0 00 00 00 00 |x[O....9........| 00000420 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000ff0 00 00 00 00 00 00 53 57 41 50 53 50 41 43 45 32 |......SWAPSPACE2| 00001000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 08000000 [root@test tmp]# cryptsetup luksFormat /dev/loop0 WARNING! ======== This will overwrite data on /dev/loop0 irrevocably. Are you sure? (Type uppercase yes): YES Enter LUKS passphrase: Verify passphrase: Command successful. [root@test tmp]# hexdump -C /dev/loop0 | head -n 10 00000000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00 |LUKS....aes.....| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 00 00 00 00 00 00 00 00 63 62 63 2d 65 73 73 69 |........cbc-essi| 00000030 76 3a 73 68 61 32 35 36 00 00 00 00 00 00 00 00 |v:sha256........| 00000040 00 00 00 00 00 00 00 00 73 68 61 31 00 00 00 00 |........sha1....| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000060 00 00 00 00 00 00 00 00 00 00 04 08 00 00 00 10 |................| 00000070 45 49 72 8e 34 41 37 cc 03 a8 5c 0e 31 97 de b9 |EIr.4A7...\.1...| 00000080 f6 52 1a 62 7e 4d ce 5d 7f af 12 c5 18 be d0 f6 |.R.b~M.]........| 00000090 00 25 a1 c1 26 52 b6 f7 29 92 10 37 d7 85 34 bc |.%..&R..)..7..4.| [root@test tmp]# blkid /dev/loop0 /dev/loop0: UUID="0e5658ca-71d4-4be6-a156-71db4104efb7" TYPE="crypt_LUKS" so it is properly identified by blkid and: [root@test tmp]# hexdump -C -v /dev/loop0 | grep ^00000ff0 00000ff0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| the old swap signature is gone .... luks is doing the right thing now. BUT going the other way: [root@test tmp]# mkswap /dev/loop0 Setting up swapspace version 1, size = 131068 KiB no label, UUID=c44cd15f-d554-4773-9505-7bc64332b128 [root@test tmp]# blkid /dev/loop0 /dev/loop0: UUID="0e5658ca-71d4-4be6-a156-71db4104efb7" TYPE="crypt_LUKS" argh, going the other way, mkswap is not zeroing out the LUKS header. Sigh. (but I don't think that's relevant to this bug)
In my system (as originally reported) the swap partition was created in a version of Fedora a few years ago but during the install of F10 I asked the installer to format and encrypt the existing swap partition (in this case /dev/sda6). When I repaired the partition after using the liveCD I used cryptsetup create to make a new encrypted partition on /dev/sda6, and then mkswap to turn the encrypted partition into the swap area after luksOpen'ing it. I am not near the machine in question at the moment but tomorrow evening I will get to the machine and run blkid on the partition as it stands and then report the result so you can see the TYPE if that would be helpful?
I have now got a route into the original machine that generated this bz- and checked the swap partition. This was the /dev/sda6 swap partition that was overwritten by the livecd, and is now repaired. [root@lapmike1 ~]# hexdump -C /dev/sda6 | head -n 10 00000000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00 |LUKS....aes.....| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 00 00 00 00 00 00 00 00 63 62 63 2d 65 73 73 69 |........cbc-essi| 00000030 76 3a 73 68 61 32 35 36 00 00 00 00 00 00 00 00 |v:sha256........| 00000040 00 00 00 00 00 00 00 00 73 68 61 31 00 00 00 00 |........sha1....| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000060 00 00 00 00 00 00 00 00 00 00 04 08 00 00 00 10 |................| 00000070 c8 30 99 e5 37 c6 7d 10 1d 67 a8 84 3f 98 df 99 |.0..7.}..g..?...| 00000080 36 d3 1e b6 da 79 81 03 23 e2 17 56 c8 e1 3b f0 |6....y..#..V..;.| 00000090 28 39 2b 76 e0 d2 6f 1b cc 19 a0 bb 66 89 8b 5c |(9+v..o.....f..\| [root@lapmike1 ~]# blkid /dev/sda6 /dev/sda6: UUID="f2013f34-3923-4087-b83f-4da73d06f31c" TYPE="crypt_LUKS" So the id is only showing the luks header. The current swap partition was made on the mapped area and swapon -s confirms that this is operational. The question I am not sure about is whether running a current rawhide liveCD (or f10 liveCD ) would overwrite this swap area again and cause the same problem? However I don't wish to run that test! Nevertheless I hope the above is useful?
I don't believe we'd delay the release for this, but we would take a fix. Putting on the target.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.