Bug 1037934

Summary:

'unable to allocate aligned partition' errors keep occurring when trying to create partitions on iSCSI device, and does...other...odd...stuff

Product:

[Fedora] Fedora

Reporter:

Adam Williamson <awilliam>

Component:

anaconda

Assignee:

Anaconda Maintenance Team <anaconda-maint-list>

Status:

CLOSED INSUFFICIENT_DATA

QA Contact:

Fedora Extras Quality Assurance <extras-qa>

Severity:

high

Docs Contact:

Priority:

unspecified

Version:

CC:

anaconda-maint-list, awilliam, bwalker, Frodox, g.kaviyarasu, jonathan, mruckman, robatino, tflink, vanmeeuwen+fedora

Target Milestone:

---

Target Release:

---

Hardware:

x86_64

OS:

All

Whiteboard:

RejectedBlocker

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2015-04-14 21:03:48 UTC

Type:

Bug

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
storage.log showing the error occurring multiple times (tried to create partitions of various sizes), then the 'lucky' successful setup	none
storage.log from successful iSCSI install	none
program.log from successful iSCSI install	none

Description Adam Williamson 2013-12-04 05:47:50 UTC

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.

Comment 1 Adam Williamson 2013-12-04 05:48:35 UTC

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).

Comment 2 Adam Williamson 2013-12-04 05:51:03 UTC

Created attachment 832419 [details]
storage.log showing the error occurring multiple times (tried to create partitions of various sizes), then the 'lucky' successful setup

Comment 3 Adam Williamson 2013-12-04 05:53:01 UTC

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.

Comment 4 Adam Williamson 2013-12-04 06:25:29 UTC

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.

Comment 5 Tim Flink 2013-12-04 07:25:42 UTC

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.

Comment 6 John Dulaney 2013-12-04 17:35:07 UTC

Works for me here with F19 target, both x86_64 and arm.

Comment 7 Mike Ruckman 2013-12-04 17:40:19 UTC

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/

Comment 8 Brian Lane 2013-12-04 20:39:11 UTC

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.

Comment 9 Adam Williamson 2013-12-05 07:42:00 UTC

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.

Comment 10 Mike Ruckman 2013-12-05 19:09:46 UTC

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/

Comment 11 Tim Flink 2013-12-05 22:03:14 UTC

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

Comment 12 Tim Flink 2013-12-05 22:04:34 UTC

Created attachment 833330 [details]
program.log from successful iSCSI install

Comment 13 David Shea 2015-04-14 20:09:01 UTC

Is this still an issue? Could you attach the other logs or traceback?

Comment 14 Adam Williamson 2015-04-14 21:03:48 UTC

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.