Description of problem: Fedora 21 cannot install to local disk This is very strange as this laptop is running Fedora 17 from the local disk The installer for Fedora 21 says no disks were found. This is bizarre as during the Fedora 21 install I can go to a root prompt and use fdisk to view the partition table Fedora 17 is using LVM and stable on the local disk From the Fedora 21 installer, pvdisplay initially fails partprobe now pvdisplay appears to work vgdisplay shows the volume group vgchange -a y this fails with an ioctl error lvdisplay shows the LVs are NOT AVAILABLE but excluding LVM it should be possible for the F21 installer to idenfity that a local disk exists and to reclaim space. Version-Release number of selected component (if applicable): How reproducible: 100% on my laptop - I haven't been able to find anyone else with this issue Steps to Reproduce: 1. Have tried the F21-live and F21-DVD iso images (USB boot) 2. Same problem 3. Actual results: F21 installer won't work with local disks. Can install to USB disk and this is stable (slower disk I/O) Expected results: It would be nice if F21 could install to the local disk Additional info: Windows 7 laptop. NO EFI on this laptop Didn't find anything helpful in the BIOS settings Will attach more information soon
From Fedora 17: sudo fdisk -l /dev/sda Disk /dev/sda: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk identifier: 0xabfaf1ec Device Boot Start End Blocks Id System /dev/sda1 * 2048 3074047 1536000 27 Hidden NTFS WinRE /dev/sda2 3074048 128903167 62914560 7 HPFS/NTFS/exFAT /dev/sda3 128903168 956223487 413660160 f W95 Ext'd (LBA) /dev/sda4 956223488 976762879 10269696 17 Hidden HPFS/NTFS /dev/sda5 128905216 129429504 262144+ 83 Linux /dev/sda6 129433600 129953792 260096+ 83 Linux /dev/sda7 129957888 956223487 413132800 8e Linux LVM sudo pvdisplay --- Physical volume --- PV Name /dev/sda7 VG Name vg PV Size 393.99 GiB / not usable 26.00 MiB Allocatable yes PE Size 32.00 MiB Total PE 12607 Free PE 768 Allocated PE 11839 PV UUID IBfm0b-VfMv-fSTW-NRmr-e7qC-AsPc-w63znq sudo pvdisplay --- Physical volume --- PV Name /dev/sda7 VG Name vg PV Size 393.99 GiB / not usable 26.00 MiB Allocatable yes PE Size 32.00 MiB Total PE 12607 Free PE 768 Allocated PE 11839 PV UUID IBfm0b-VfMv-fSTW-NRmr-e7qC-AsPc-w63znq sudo lvdisplay --- Logical volume --- LV Path /dev/vg/lv01 LV Name lv01 VG Name vg LV UUID 2SbbKe-M8a5-BdDW-dSAr-9UiY-L40c-SNTPOe LV Write Access read/write LV Creation host, time localhost.localdomain, 2013-04-22 02:22:56 +0800 LV Status available # open 2 LV Size 8.00 GiB Current LE 256 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:0 --- Logical volume --- LV Path /dev/vg/lv00 LV Name lv00 VG Name vg LV UUID UI2wE8-Hi3s-LzqB-aAeN-KrNy-NlGp-95AiKz LV Write Access read/write LV Creation host, time localhost.localdomain, 2013-04-22 02:22:57 +0800 LV Status available # open 1 LV Size 24.00 GiB Current LE 768 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:1 --- Logical volume --- LV Path /dev/vg/lv02 LV Name lv02 VG Name vg LV UUID 6neBwm-9Mdy-3e1Y-vVzi-3Cml-lKZy-OZR6Em LV Write Access read/write LV Creation host, time localhost.localdomain, 2013-04-22 02:23:00 +0800 LV Status available # open 1 LV Size 337.97 GiB Current LE 10815 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:2
As you can see there is 24GB of space available within LVM and /dev/sda6 is about 256MB (this would be /boot for F21) if the Fedora 21 installer would accept it
lspci 00:00.0 Host bridge: Intel Corporation Ivy Bridge DRAM Controller (rev 09) 00:02.0 VGA compatible controller: Intel Corporation Device 0166 (rev 09) 00:14.0 USB Controller: Intel Corporation Panther Point USB xHCI Host Controller (rev 04) 00:16.0 Communication controller: Intel Corporation Panther Point MEI Controller #1 (rev 04) 00:1a.0 USB Controller: Intel Corporation Panther Point USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation Panther Point High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 1 (rev c4) 00:1c.2 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 3 (rev c4) 00:1c.6 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 7 (rev c4) 00:1d.0 USB Controller: Intel Corporation Panther Point USB Enhanced Host Controller #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation Panther Point LPC Controller (rev 04) 00:1f.2 RAID bus controller: Intel Corporation Mobile 82801 SATA RAID Controller (rev 04) 00:1f.3 SMBus: Intel Corporation Panther Point SMBus Controller (rev 04) 02:00.0 Network controller: Realtek Semiconductor Co., Ltd. Device 8723 03:00.0 Ethernet controller: Atheros Communications AR8152 v2.0 Fast Ethernet (rev c1) lspci -n 00:00.0 0600: 8086:0154 (rev 09) 00:02.0 0300: 8086:0166 (rev 09) 00:14.0 0c03: 8086:1e31 (rev 04) 00:16.0 0780: 8086:1e3a (rev 04) 00:1a.0 0c03: 8086:1e2d (rev 04) 00:1b.0 0403: 8086:1e20 (rev 04) 00:1c.0 0604: 8086:1e10 (rev c4) 00:1c.2 0604: 8086:1e14 (rev c4) 00:1c.6 0604: 8086:1e1c (rev c4) 00:1d.0 0c03: 8086:1e26 (rev 04) 00:1f.0 0601: 8086:1e57 (rev 04) 00:1f.2 0104: 8086:282a (rev 04) 00:1f.3 0c05: 8086:1e22 (rev 04) 02:00.0 0280: 10ec:8723 03:00.0 0200: 1969:2062 (rev c1)
It should be possible for Fedora 21 to install to /dev/sda2 currently this is Windows 7 (NTFS)
How is this related to the basesystem package? I am switching the component to lvm2, which provides user space tools for logical volume management...
I didn't know what to pick for architecture and couldn't figure it out. LVM is related to this issue but it is not the only consideration.
Using Fedora 21 installed on an external USB disk; $ uname -a Linux localhost.localdomain 3.19.3-200.fc21.x86_64 #1 SMP Thu Mar 26 21:39:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux $ cat /etc/redhat-release Fedora release 21 (Twenty One) $ sudo ls -la /dev/sd* brw-rw----. 1 root disk 8, 0 Apr 11 2015 /dev/sda brw-rw----. 1 root disk 8, 16 Apr 11 2015 /dev/sdb brw-rw----. 1 root disk 8, 32 Apr 11 2015 /dev/sdc brw-rw----. 1 root disk 8, 33 Apr 11 2015 /dev/sdc1 brw-rw----. 1 root disk 8, 34 Apr 11 2015 /dev/sdc2 brw-rw----. 1 root disk 8, 35 Apr 11 2015 /dev/sdc3 This is odd as F21 hasn't automatically created all the block devices for the partitions on /dev/sda. /dev/sdc is the external USB disk. Forcing their creation... $ sudo partprobe $ ls -la /dev/sda* brw-rw----. 1 root disk 8, 0 Apr 10 22:39 /dev/sda brw-rw----. 1 root disk 8, 1 Apr 10 22:39 /dev/sda1 brw-rw----. 1 root disk 8, 2 Apr 10 22:39 /dev/sda2 brw-rw----. 1 root disk 8, 3 Apr 10 22:39 /dev/sda3 brw-rw----. 1 root disk 8, 4 Apr 10 22:39 /dev/sda4 brw-rw----. 1 root disk 8, 5 Apr 10 22:39 /dev/sda5 brw-rw----. 1 root disk 8, 6 Apr 10 22:39 /dev/sda6 brw-rw----. 1 root disk 8, 7 Apr 10 22:39 /dev/sda7 $ sudo fdisk -l /dev/sda Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0xabfaf1ec Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 3074047 3072000 1.5G 27 Hidden NTFS WinRE /dev/sda2 3074048 128903167 125829120 60G 7 HPFS/NTFS/exFAT /dev/sda3 128903168 956223487 827320320 394.5G f W95 Ext'd (LBA) /dev/sda4 956223488 976762879 20539392 9.8G 17 Hidden HPFS/NTFS /dev/sda5 128905216 129429504 524289 256M 83 Linux /dev/sda6 129433600 129953792 520193 254M 83 Linux /dev/sda7 129957888 956223487 826265600 394G 8e Linux LVM Partition table entries are not in disk order. $ sudo mount /dev/sda6 /media/temp mount: /dev/sda6 is already mounted or /media/temp busy $ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 2.9G 0 2.9G 0% /dev tmpfs 2.9G 80K 2.9G 1% /dev/shm tmpfs 2.9G 1008K 2.9G 1% /run tmpfs 2.9G 0 2.9G 0% /sys/fs/cgroup /dev/mapper/fedora-root 18G 4.2G 13G 26% / tmpfs 2.9G 16K 2.9G 1% /tmp /dev/sdc1 477M 132M 316M 30% /boot tmpfs 588M 0 588M 0% /run/user/989 tmpfs 588M 12K 588M 1% /run/user/1000 /dev/sda6 is NOT already mounted. Fedora 21 is confused and behaving very strangely... I can't mount any other partitions either from /dev/sda (internal disk) ... $ sudo mount /dev/sda5 /media/temp mount: /dev/sda5 is already mounted or /media/temp busy $ sudo mount /dev/sda2 /media/temp ntfs-3g-mount: mount failed: Device or resource busy $ sudo vgchange -a y 2 logical volume(s) in volume group "fedora" now active device-mapper: reload ioctl on failed: Invalid argument device-mapper: reload ioctl on failed: Invalid argument device-mapper: reload ioctl on failed: Invalid argument 0 logical volume(s) in volume group "vg" now active This is showing that the LVM for F21 from /dev/sdc is ok But the LVM from the old F17 on /dev/sda is unusuable If I return to F17 I can mount ALL partitions and access everything with no errors. So it is not the laptop.
It is becoming clear that this issue isn't just during the Fedora 21 installer This issue is in the OS itself, when used on this hardware. Why it works with Fedora 17 is what I don't understand
The relevant entry from GRUB2 I manually edited this to try to solve the issue by adding extra --hint parameters. No luck with that approach. menuentry 'Fedora (3.19.3-200.fc21.x86_64) 21 (Twenty One)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.17.4-301.fc21.x86_64-advanced-e989282b-7349-4d23-b3d6-578b5015e3d7' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd2,msdos1 --hint-efi=hd2,msdos1 --hint-baremetal=ahci2,msdos1 --hint='hd0,msdos1' --hint=hd0,msdos5 --hint='hd0,msdos7' f3190a10-5ed2-488e-bbce-ca868a7a5175 else search --no-floppy --fs-uuid --hint=hd0,msdos5 --hint='hd0,msdos7' --set=root f3190a10-5ed2-488e-bbce-ca868a7a5175 fi linux16 /vmlinuz-3.19.3-200.fc21.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/root rd.luks.uuid=luks-5ad393a1-6043-4dde-9245-11adeca2b9da rhgb quiet LANG=en_AU.UTF-8 initrd16 /initramfs-3.19.3-200.fc21.x86_64.img }
Laptop is Toshiba Satellite U840W (about 2 years old)
/dev/sdb is the internal SDD device and this is the installation software to reimage the Toshiba laptop sudo fdisk -l /dev/sdb Disk /dev/sdb: 32.0 GB, 32017047552 bytes 255 heads, 63 sectors/track, 3892 cylinders, total 62533296 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xaca7e8c4 Device Boot Start End Blocks Id System /dev/sdb1 2048 23521279 11759616 84 OS/2 hidden C: drive
Not exactly an lvm2 issue. It's an installer (likely anaconda) which needs to sort out where to install. It could be either misuse of anaconda (not selecting proper boxes to select some manual boxes - and UI is not really ideal since boxes seems to appear inconsistently in various corners). Switch to anaconda - and I also assume you will need to provide anaconda installation log - could you attach one please to BZ?
Created attachment 1013333 [details] Anaconda installer screenshot (Fedora 21) screenshot shows that the only disk available to install to is /dev/sdc (external USB disk). the internal/local disk is /dev/sda and cannot be installed to.
Created attachment 1013334 [details] anaconda log file Requested log file: anaconda.log
Please attach the other log files from /tmp during the install, in particular storage.log.
Created attachment 1013566 [details] storage.log
Created attachment 1013567 [details] program.log
ifcfg.log and X.log are not related to this issue (not attached) sensitive-info.log has a file size of 0 bytes this issue is NOT just Anaconda, it is Fedora 21 OS. when I use an external USB disk to boot Fedora 21 no partitions on /dev/sda are usable cannot mount any ext3, LVM or NTFS partitions from /dev/sda They always work ok with Fedora 17
Created attachment 1013569 [details] Fedora 21 log of commands i tried to access /dev/sda Using external USB disk to boot Fedora 21 this is what happened when I tried to mount partitions on /dev/sda
Created attachment 1013570 [details] Fedora 17 log for comparison this is /proc/diskstats from Fedora 17
Created attachment 1013580 [details] Fedora 21 dmesg log Booted Fedora 21 from external USB This is the output from dmesg
Reassigning to kernel based on comment 18, and also these messages in the log look suspect: [ 112.325083] device-mapper: table: 253:3: linear: dm-linear: Device lookup failed [ 112.325087] device-mapper: ioctl: error adding target to table [ 112.339760] device-mapper: table: 253:3: linear: dm-linear: Device lookup failed [ 112.339764] device-mapper: ioctl: error adding target to table [ 112.351703] device-mapper: table: 253:3: linear: dm-linear: Device lookup failed [ 112.351706] device-mapper: ioctl: error adding target to table
Nope - not a kernel issue. DM table has been incorrectly constructed. Yet - I'm not an expert on Anaconda logging - so it needs better review from anaconda team members to detect where things go wrong.
From ananconda log - there is detected 'imsm' raid on your /dev/sda ? (This was probably not seen by f17) System on fc21 is not processing devices over this raid. Was your device ever configure as some HW raid?
No hardware raid is being used Fedora 17 OS has been working fine for 2 years. Tried to install Fedora 21 and /dev/sda is unwriteable less -f /dev/sda and viewing the partition table is working
Created attachment 1014115 [details] Fedora 17 dmesg.log (useful as comparison with Fedora 21)
It's not about how you are using it for f17. The issue is (from your program.log) 05:20:07,105 INFO program: Running... mdadm --examine --export /dev/sda 05:20:07,183 INFO program: MD_METADATA=imsm 05:20:07,185 INFO program: MD_LEVEL=container 05:20:07,186 INFO program: MD_UUID=8e5cbc2b:aba0ea70:1798f8dd:080089e3 05:20:07,186 INFO program: MD_DEVICES=1 05:20:07,187 DEBUG program: Return code: 0 05:20:07,187 INFO program: Running... mdadm --examine --brief /dev/sda 05:20:07,684 INFO program: ARRAY metadata=imsm UUID=8e5cbc2b:aba0ea70:1798f8dd:080089e3 05:20:07,684 INFO program: ARRAY /dev/md/82AT5921V32CN6VD container=8e5cbc2b:aba0ea70:1798f8dd:080089e3 member=0 UUID=0f2e9292:47d83655:e82eecdb:0d58a43c 'mdadm' has evolved between f17 and f21 - and recognizes this 'imsm' raid signature on your device. So do you know full history of your machine (and your disks) ? Are you sure your sda device was never ever used as a member of raid? (Could have been preinstalled as raid?) Could you please try (booted into your f21 from DVD) these commands: blkid /dev/sda wipefs /dev/sda Attach output of above commands into BZ. If the 'wipefs' sees the imsm' signature, you should be able to remove it using --offset. (Be sure to read manual pages and take appropriate backups). Otherwise 'dmraid' tool probably will be needed. But let's try the easy thing first.
**************************************************** The information above is EXTREMELY helpful and NOT included in the Fedora 21 Installation Guide PDF (yes, I did read it). I have been trying to get this working for more than 1 month. Please UPDATE the documentation to include this type of information It is EXTREMELY helpful **************************************************** $ sudo wipefs -n /dev/sda offset type ---------------------------------------------------------------- 0x1fe dos [partition table] 0x7470c05c00 isw_raid_member [raid] (dry-run only for testing purposes) $ sudo wipefs -n /dev/sda offset type ---------------------------------------------------------------- 0x1fe dos [partition table] 0x7470c05c00 isw_raid_member [raid] Clearly,this is the source of the problem. I have never used any type of RAID on this laptop but it has Windows 7 and this is probably responsible for the RAID signature on /dev/sda. As Fedora 17 ignores this information, it was never a problem until now. I have some experimentation to do and will update this ticket with the results
Simple answer: this works - issue resolved. Long answer: This laptop came preinstalled with Windows 7 and Intel Windows 7 software which has enabled RAID. Though I don't use Windows 7 and I have been using Fedora 17 for 2 years I didn't even know it existed! This laptop has no BIOS options to configure the RAID. Using the Fedora 21 installer it was impossible to wipe the RAID signature. No writes to /dev/sda are possible. The wipefs command always failed. I had to use Fedora 17 and do the following: wipefs -o 0x7470c05c00 /dev/sda to wipe the RAID signature (wipes 32 bytes) But, booting Windows 7 automatically writes the RAID signature on /dev/sda Then I have the same problem again... After doing this several times, I saw a new message before GRUB Press Ctrl-I to configure RAID Using this I have permanently disabled the RAID - Issue resolved. The annoying thing is in normal circumstances you cannot press Ctrl-I to do this. You have to break the RAID first to get access to it. Apparently on the Toshiba website there are forums which may help with this But I live in China and I cannot access this website and I cannot access Google. Thank you everyone for your assistance in troubleshooting this issue. Hopefully this ticket will assist other users.
Glad to hear everything is working.
I would expect the Fedora 21 installation image to be able to clear the RAID signature if necessary. As far as I understand comment #29, it was not the case.
There are clearly more 'questions' to ask. If 'f17' was running ON a device which has been 'technically' a member of RAID - and Windows even refreshed signature when it was 'lost' on (sda) it's clear sign the raid was 'still' alive. So - it's not just the tool is able to 'remove' signature from 'sda' but it should also do analysis and see there is signature on other devices ? Also - what I'm still missing here is: If Anaconda 'runs' this raid on 'sda' - then what happens with /dev/md0 ? Why it's not continuing to use this device ? Clearly Windows do that - why Anaconda decides to ignore such device ??? The more you think about the issue - the endless list of questions pops up... So I'm not considering this bug as resolved.
Anaconda does not support incomplete RAID arrays. *** This bug has been marked as a duplicate of bug 833314 ***
Hmm - doesn't make it much cleaner. Looking at attached logs: 05:20:07,825 DEBUG blivet: MDRaidMember.__init__: uuid: None ; exists: True ; label: None ; device: /dev/sdb ; serial: S0VSNEAC657636 ; mdUuid: 1fe88d7a-85d9-9a9a-24df-c382d80618ae ; biosraid: True ; 05:20:07,104 DEBUG blivet: DeviceTree.handleUdevDeviceFormat: name: sda ; 05:20:07,685 INFO blivet: type detected on 'sda' is 'isw_raid_member' 05:20:07,687 DEBUG blivet: MDRaidMember.__init__: uuid: None ; exists: True ; label: None ; device: /dev/sda ; serial: 120528TA95123VC26NDV ; mdUuid: 8e5cbc2b-aba0-ea70-1798-f8dd080089e3 ; biosraid: True ; pretty strange - so how was Windows boot able to 'restore' raid back ? I'm rather convinced there was raid - just ignored by f17 installation ? And even if we ignore the whole 'raid' mismatch games and installation - are you seriously suggesting the user with real physical disk in his desktop are supposed to run/install other OS to 'wipe' signature ? It's pretty much clear (and likely not just to me) Anaconda is here missing some 'override' button - to allow user to setup installation on his existing physical disk - unsure what are the best steps - i.e. Show dialog 'sda' is 'raid' member - possibly damaged - Do you want to wipe raid signature yes/no? IMHO it's not an option for an installer just to tell user - go elsewhere fix it elsewhere not my problem.
I am still figuring how this RAID utility was working on my Toshiba Satellite U840 laptop. /dev/sda is 500GB internal SATA disk /dev/sdb is 32GB SDD card ? Preinstalled software included with Windows 7 setup a RAID 0 Stripe that somehow uses the SDD card to cache disk activity and improve read speeds Fedora 17 has always ignored this so disabling it is the easiest option Reminder: When I tried Fedora 21 (booted from external USB disk) running full OS OR from anaconda (using the installer) I couldn't wipe the RAID signature with wipefs. It was necessary to go back to a Linux version before mdadm was updated and wipe the RAID signature then proceed and I had to fiddle with manufacturer provided software which is a mess and has nothing to do with Linux. My opinion is this is not an Anaconda bug Whoever has to fix this I wish you a lot of luck.
(In reply to Steven McIntyre from comment #35) is so disabling it is the easiest option > > Reminder: When I tried Fedora 21 (booted from external USB disk) running > full OS OR from anaconda (using the installer) I couldn't wipe the RAID > signature with wipefs. I assume it's because 'mdadm' was using /dev/sda - and thus you would likely need to stop 'mdadm' first to be able to use wipefs. > My opinion is this is not an Anaconda bug Anaconda needs to give user a choice to 'override' findings of blivet or other tools - users is always the one who has full control.
After carefully thinking about this and trying to think about this as if it was another person that was affected: It has to be the responsibility of the user to manage any RAID type arrays that may exist but in this case there were no options in the BIOS for RAID and it wasn't obvious to me that it even existed. Other users are likely to make similar mistakes... Anaconda cannot wipe the RAID signature - this has side effects... Some users may choose to run a dual boot system and might want to use Windows. The only reasonable alternative is for Anaconda to identify this type of situation exists and to advise the user on what options are available. Anaconda (F21) did NOT identify any RAID arrays at all in the GUI I think the RAID array should be properly identified so that the user is aware of it But, installation would not be possible and the Fedora documentation should be updated to assist the user in identifying this type of scenario. When I have spare time I can do some experimenting and figure out a solution that uses Fedora 21 (Previously I went back to F17 to wipe the RAID signature) All disk writes to /dev/sda were failing with F21. Nothing could be mounted or written to but reads were ok.