Created attachment 583675 [details] failure on first attempt using liveinst on TC4 Description of problem: TC4 live install to HD IOException: Partition(s) 1 on /dev/sda have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use. As a result, the old partition(s) will remain in use. You should reboot now before making further changes. -Installs on reboot of dd USB. and l-i-t-d USB live desktop x86_64 Version-Release number of selected component (if applicable): How reproducible: every time i686 and x86_64 live install from USB (either l-i-t-d or dd) Steps to Reproduce: 1. 2. 3. Actual results: Install on first invocation of liveinst Expected results: Additional info:
Created attachment 583690 [details] built l-i-t-d on TC4 Desktop x86_64 got this install error ACER ASPIRE ONE N450 booted to external HD install of TC4 Desktop x86_64 Error from anaconda on first try. Installs correctly on second boot of l-i-t-d USB invocation of liveinst. IS this some kind of problem passing the format information on to anaconda or the kernel? (Previous error was from a TC3 Desktop install)
also encountered same liveinst bug using liveusb-creator in (f17TC4 i686 Desktop install) USB created with --reset-mbr. Tried to use first-screen install to HD option. Used an external USB HD with TC2 Desktop installed on it as a target. Use whole disk non lvm option. Had to reboot USB and then install preceded to completion successfully.
The desktop (GNOME in this case) is mounting the external drive under /run/media/liveuser/UUID even though I canceled the popup when I logged in. So when anaconda tried to install to it things get confused because it is already mounted. The live spin desktop shouldn't be automatically mounting things, especially when you cancel the dialog asking you if you want to do that.
Just hit this in KVM/Qemu vm with F17 host
A few thoughts: 1) One recent change is user mounts go to /run/media now instead of /media 2) The bubble doesn't ask you if you want to mount, it tells you it mounted 3) This presumably worked before. My guess is anaconda has code to deal with this, but it broke because the mount point location changed (point 1) If my assumption in 3 is correct, then it should be straight forward to adapt the code to work with the new location I guess. Moving back to anaconda under that assumption.
Discussed at 2012-05-11 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-05-11/f17-final-blocker-review-meeting-5.2012-05-11-17.04.html . Accepted as a blocker per Alpha criterion "The installer must be able to complete an installation using any locally connected storage interface (e.g. PATA, SATA, SCSI etc...) with the default file system ". AIUI, this bug affects the case where you try to install from a live image to an external hard disk. Right? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
TC5 Desktop l-i-t-d x86_64 same error as above 8 GB USB this is message when I tried to use TC5 disk-utility to unmount USB /dev/sdb1 after liveinst error message on reboot of USB: Error unmounting /dev/sdb1: Command-line `umount "/dev/sdb1"' exited with non-zero exit status 32: umount: /run/initramfs/live: target is busy. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1)) (udisks-error-quark, 0) Install to external USB HD worked on second try.
Ext USB install from l-i-t-d TC5 DVD x86_64 Ext USB install: gnome/LDXE/Sugar-Desktop from DVD install repo Boot to LDXE: run dd=f17 TC5 Live Desktop x86_64 to 4 GB USB: Boot from dd=f17 TC5 Live Desktop x86_64 USB: (eject 3 attempts at mount of previous install of f17 Beta volumes) Install to Hardisk (liveinst) External USB HD as target use whole disk non LVM Write changes to disk "ext4 filesystem check failure on /dev/sda3: File system errors left uncorrected....." 2nd Boot from dd=f17 TC5 Live Desktop x86_64 USB: Install to Hardisk (liveinst) External USB HD as target use whole disk non LVM Write changes to disk "ext4 filesystem check failure on /dev/sda3: File system errors left uncorrected....." Will try dd again from gnome desktop....
when I re-wrote the dd USB in Gnome it gave usual error on first try then installed on 2nd try.(Using the same .iso and USB) Why does a dd written in LXDE not work?
more testing with f17 TC5 Live desktop x86_64 l-i-t-d-USB: Error: "Partition(s) 1 on /dev/sda have been written, but we have been unable to inform the kernel of the change". This error occurs if I use an external USB Hard-disk target which has a F17 use whole disk non lvm installation on it. The fix is to not select the opening screen "install to Hard-Disk". but to "try first without install". them use "disks" (Disk-utility) to re-format the target external USB HD fat with a /dev/sdb1 partition fat label=LIVE boot flag. (the /dev/sdb1 partition remains unmounted.) exit disk-utility and select "Install to Hard-disk" on left panel of gnome. This installs correctly with no errors.
Another test: used disks (disk-utility) on USB to unmount 5 partitions first then installed to existing TC5 Desktop HD Looks like unmounting existing partitions on target external USB disk is critical for install to succeed.
(In reply to comment #11) > Another test: > used disks (disk-utility) on USB to unmount 5 partitions first then installed > to existing TC5 Desktop HD > > Looks like unmounting existing partitions on target external USB disk is > critical for install to succeed. This was a liveusb-creator install to USB (with --reset-mbr in command) of Fedora-17.TC5-x86_64-Live-Desktop.iso with 1024 persistence Ref: https://fedoraproject.org/wiki/Test_Results:Fedora_17_Final_TC5_Install#USB_Stick
No, Anaconda doesn't have code to deal with this. It expects things to me unmounted when it runs. This includes raid, luks, external drives, etc. This is why we tell dracut to ignore all of these with the kernel cmdline. I wouldn't expect the desktop to stop doing this, but for live spins they need to disable this behavior somehow.
I think c#13 is entirely wrong and c#5 is entirely right. scripts/anaconda-cleanup has this note: live install: - unmount everything under /media - populate a devicetree and tear everything down and this code: if (mountpoint.startswith("/media") or device.startswith("/dev")) and \ live_install and not "live" in mounted: os.system("umount %s" % mountpoint) so it needs the obvious patch for the /run/media mount point change. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Adam is correct. Sorry for the confusion.
anaconda-17.27-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/anaconda-17.27-1.fc17
Package anaconda-17.27-1.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-17.27-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-7834/anaconda-17.27-1.fc17 then log in and leave karma (feedback).
anaconda-17.27-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
https://fedoraproject.org/wiki/Test_Results:Fedora_17_Final_TC6_Install#USB_Stick dd and --efi l-i-t-d USB Live Desktop x86_64 EFI Mac boot is unable to reformat use whole disk non LVM have to go to "try with out installing - diskutility and format target USB Hd to fat with fat label=LIVE boot flag then Install to HD This is NOT necessary for bios boot install to HD
when translated from satellitish, I believe, that means that he found doing a second EFI install to his Mac over the top of an initial install, using 'use all space', resulted in a non-booting system. To get a successful install over the top of an existing Fedora EFI install, he had to reformat the disk with OS X Disk Utility first. This could well be due to https://bugzilla.redhat.com/show_bug.cgi?id=821187 , I guess? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
*** Bug 819250 has been marked as a duplicate of this bug. ***
*** Bug 819193 has been marked as a duplicate of this bug. ***