Description of problem: When searching for storage devices during a live CD install from yesterday's snapshot desktop-i386-20091024.19, an error window pops up complaining that an error has occurred while processing drive /dev/dm-0 (see attached screenshot). After clicking "Ignore drive" for /dev/dm-0 and likewise for the subsequent error message for /dev/dm-1, the install proceeds as expected. Clicking "Re-initialize drive" will keep the installer stuck in this step. Version-Release number of selected component (if applicable): anaconda-12.39-1.fc12.i686 How reproducible: Always. Steps to Reproduce: 1. Boot system from desktop-i386-20091024.19 live media. 2. Lauch /usr/bin/liveinst. 3. Proceed to storage step. Actual results: Installer reports error processing drive: /dev/dm-0. Expected results: Installer launches partitioning tool. Additional info: This issue is fairly recent and was not encountered using the F12 Alpha Snap3 live CD.
Created attachment 366125 [details] Anaconda storage log file
Please try the newest F12 Beta
Humphrey, 20091024 version supposes to be newer than F12 Beta. From the page, https://fedoraproject.org/wiki/F12_Beta_Announcement Beta was announced in 20 Oct.
I believe I have encountered this issue as well. I was running the beta live cd installer to replace my F11 installation. (I updated anaconda to latest 12.39-1 before proceeding.) My old setup was as follows, create by F11 anaconda except for /home which was kept from a F9 or F10 install. /dev/sda1 ext3 196MB /boot /dev/sda4 ext4 7993MB / (encrypted) /dev/sda2 swap 1537MB /dev/sda3 ext3 66589MB /home (encrypted) As the OP described, the "Error processing drive" message comes up twice, in my case reading: /dev/dm-2 3067MB Linux device-mapper (snapshot) /dev/dm-3 3067MB Linux device-mapper (snapshot) I did not recoginize the 3067MB size as any of my own, so the first time the message came up I suspected a problem with the persistent live image. I re-copied the image and got the error once again. This time I clicked "Re-Initalize Drive". The dialog went away immediately, it did not seem like it did anything to my hard disk. At that point I exited the installer and booted from my local disk. /boot and / mounted correctly, but for /home: fsck.ext3: bad magic number in super-block while trying to open /dev/mapper/luks-90a5cc4a-... /dev/mapper/luks-905cc4a-...: The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid ... then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device> So, that's where I am for now. Strange that only one of my partitions was impacted. I hold out hope I could get /home to mount again, but am currently stumped. It is hard to believe all 60GB were wiped out in about a second, but maybe that is the case. I at least wanted to report what seems like a serious problem with F12Beta live / anaconda.
I see this myself too with current rawhide spins. I think this is a F12Blocker candidate.
Can you attach the output of ls -l /dev/live* to this bug report? Thanks.
(In reply to comment #6) > Can you attach the output of ls -l /dev/live* to this bug report? Thanks. Testing with anaconda-12.41-1.fc12.i686 # ls -l /dev/live* lrwxrwxrwx. 1 root root 3 2009-10-29 13:38 /dev/live -> sr0
Created attachment 366674 [details] anaconda.log (anaconda-12.41-1.fc12) After clicking "ignore" for both /dev/dm-0 and /dev/dm-1, I am able to proceed with the installation. Attaching the anaconda.log, storage.log and program.log that demonstrate clicking "ignore".
Created attachment 366675 [details] program.log (anaconda-12.41-1.fc12)
Created attachment 366676 [details] storage.log (anaconda-12.41-1.fc12)
this happened to me with the 28-oct-2009 nightly desktop live cd just now.
Testing with anaconda-12.39-1.fc12.i686 $ ls -l /dev/live* lrwxrwxrwx. 1 root root 3 2009-10-30 03:28 /dev/live -> sr0
Fixed by commits 447db7bf1f6c and 080f12b6d4ee, which will be in anaconda-12.42-1.
Discussed at blocker meeting, accepted as a blocker. Please re-test when the next anaconda build is available and included in images. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
this is in the 12.42 build: http://koji.fedoraproject.org/koji/buildinfo?buildID=139122 tag request: https://fedorahosted.org/rel-eng/ticket/2942 -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This will be in tomorrow's (20091103) rawhide - please retest with that!
can someone please confirm this is fixed with today's Rawhide? spins are at: http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/ thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
this issue fixed on liveCD 2009-11-03, so close rawhide
This bug appears to be back. I am booting from a live-usb and it is trying to initialize the USB stick. Ignoring the error lets the install continue. anaconda-12.46-2.fc12.i686 kernel-2.6.31.5-127.fc12.i686
I have the same issue with my upgrade from a preupgrade utility: Error processing drive: /dev/md127 476930MB RAID1 Array anaconda-12.46. I don't want to test a click on Re-initialize drive :)
mv'ing /lib/udev/rules.d/70-anaconda.rules to /lib/udev/rules.d/70-anaconda.rules.old to fix "Bug 453095 - Cd tray is closed automatically after ejecting" was the cause in my case. Putting 'echo "dev.cdrom.autoclose = 0" >> /etc/sysctl.conf' in my kickstart file instead looks like it may solve both issues.