Trying to do https://fedoraproject.org/wiki/QA:Testcase_Anaconda_ISCSI_No_Authentication (yes, for the first time *now*, I'm sorry :/). Connecting to the target works fine, but when I get into custom partitioning, I can create a 500MB /boot, but trying to create anything bigger causes a 'Failed to add new device. Click for details.' red bar, which shows an 'unable to allocate aligned partition' error popup. After an awful lot of effort one try (I think I used the autopart button then messed with the created partitions) I was able to sweet-talk it into a layout which looked like what the test case suggests - /boot (and swap) on local drive, / on the iSCSI target - but when I completed the install and booted the installed system, it seemed to have created the swap partition on the iSCSI target and /boot and / on the local drive. It worked - the right cmdline stuff was in place, it all got connected up right. Then I tried again, and somehow got it to work, but...don't ask me, er, exactly how? Let me see. I had a 15GB local disk (virtio, in a VM) and 10GB iSCSI target. I set device type to 'standard partition' and scheduled all existing volumes for deletion. Then I used the 'autopart' button, which, IIRC, scheduled creation of a 500MB /boot, 14.5GB / on vda (local disk), and 2GB swap on sda (iSCSI disk). I changed the size of / to 8GB, and then I edited swap and forced it to be on vda. That caused / to get moved to sda, and it apparently didn't throw any errors, and I was able to complete the configuration and install. So somehow, I won the game. But just about every other path leads to failure... I'll attach the log of the run where I finally 'won the game' - it should also show some previous attempts where I hit the 'aligned partition' problem.
oh, and on the first attempt described, several of the partitions got labelled 'req6', 'req5', 'req4' and stuff in the custom part screen (rather than 'vda1' or 'sda2' or anything like that).
Created attachment 832419 [details] storage.log showing the error occurring multiple times (tried to create partitions of various sizes), then the 'lucky' successful setup
Proposing as a blocker per criterion https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#network-attached-storage - "The installer must be able to detect (if possible) and install to supported network-attached storage devices." - it's clearly not really working right, based on my test at least.
Well, looks like this also happens on F19, so it's not a regression. Could be specific to my particular iSCSI target config. I'm using a Thecus N5550 NAS for the test; created an iSCSI target using the NAS' web interface, following the manual. :P Not sure how exactly it's backed on the NAS, I can ssh into the box but it doesn't look much like a Fedora or Mandriva system so I'm a bit at sea, heh.
I also tried the iscsi test case with a F18 target and a bare metal host using the F20 TC4 x86_64 netinstall burned to usb. I hit some different weirdness for the first install where the iscsi target lun was detected and treated as a local disk post-install (leading to a boot failure) but on the second install, everything went fine.
Works for me here with F19 target, both x86_64 and arm.
Discussed in 2013-12-04 Blocker Review Meeting [1]. It was determined that we need more information. 2:1 users see this bug, looking for more feedback. Punting for more information. Will discuss at next meeting. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-12-04/
Tested using F19 target, F20 TC4 boot.iso and other than having to make sure the local disk was selected for the bootloader it works fine. I think we need a better reproducer before calling this a blocker.
bcl: thanks, but mostly I was interested in someone smart looking at my logs and seeing if they can tell whether there's something unusual about my target that seems to be triggering this. it's very easy to reproduce if you happen to have a Thecus NAS. =) It seems the iSCSI support has mostly been tested with an iSCSI target that's an RH or Fedora box acting as an iSCSI target; I did it somewhat differently by using the iSCSI capability of my NAS. We might have a better chance of making a guess at whether my NAS is particularly weird/unusual or if this may happen with quite a lot of non-RHish iSCSI targets if someone can see from my logs what's actually happening in my case.
Discussed in 2013-12-05 Go/No-Go meeting [1]. Voted a RejectedBlocker on the basis it appears to be specific to adamw's iscsi target, can be re-proposed if it looks like it will affect enough configurations to be worthwhile blocking on. [1] http://meetbot.fedoraproject.org/fedora-meeting-2/2013-12-05/
Created attachment 833329 [details] storage.log from successful iSCSI install As requested, I'm attaching the storage.log from my successful iSCSI install using F20 TC4 x86_64
Created attachment 833330 [details] program.log from successful iSCSI install
Is this still an issue? Could you attach the other logs or traceback?
Haven't tried it lately. Not sure I'm going to get time to, so let's close it for now, and if I do find some time to run the test again I can always re-open.