13.04 installation... grinding my teeth...

[chconnor]

SteveR, I really owe you a thanks for your detailed help.

But check it out: the CD burned version is working fine (so far......) I wonder if there is just some race condition in the installer that is only triggered by the speed of installing from the flash disk.

Re: EFI - I don't know a thing about it or unetbootin, sorry.

I am becoming convinced that the mobo firmware is kinda sloppy. It seems to have two modes, "normal/modern" mode and "classic" mode. Neither can intentionally boot a UEFI flash drive or CD partition -- it just hangs. But in classic mode, if a partition's UEFI boot mode is first in the boot order list, it will boot it successfully when you "exit/discard changes". It says "Secure boot disabled" and then the grub2 screen pops up.

With the CD I burned, the UEFI boot goes to the grub2 screen, and the non-UEFI boot goes to a graphic interface for the language selection and then on to the same debian installer. This pattern echoes the grub2/unetbootin discrepancy i was seeing on the flash drive. I'm sure the reasons for this are obvious to knowledgable people, but it's a little weird to me. Anyway, the other key difference, as mentioned before, is that the network would not intialize properly unless it booted via UEFI (flash drive or CD -- same deal.)

Ok, installation completed! Looks like grub2 didn't install the bootloader, though... i'll have to sort that out...

Anyhow, I'm also going to bed, but I'm going to try installing Kubuntu 13.04 from CD/UEFI tomorrow to see if that magically solves the crashing partition configuration step. If not, I'll press on with installing kubuntu-desktop.

Thanks again, it's so, so nice to have someone in your corner when you're up against something like this.

[SteveRiley]

SteveR, I really owe you a thanks for your detailed help.

You're welcome.

But check it out: the CD burned version is working fine (so far......) I wonder if there is just some race condition in the installer that is only triggered by the speed of installing from the flash disk.

I've not heard of such a bug before, and I think it would be widely reported. I suspect your problem lies elsewhere.

Re: EFI - I don't know a thing about it or unetbootin, sorry.

The UEFI learning curve is steep. It is as different from BIOS as purple is different from B flat minor. But once you learn it, you'll find that UEFI is quite cool.

I am becoming convinced that the mobo firmware is kinda sloppy. It seems to have two modes, "normal/modern" mode and "classic" mode. Neither can intentionally boot a UEFI flash drive or CD partition -- it just hangs. But in classic mode, if a partition's UEFI boot mode is first in the boot order list, it will boot it successfully when you "exit/discard changes". It says "Secure boot disabled" and then the grub2 screen pops up.

I know that Gigabyte's hybrid EFI has been the source of many problems in the past. Not sure about now, maybe they've changed to a better, more complete UEFI implementation. If you truly are booting to "classic" mode, you shouldn't even see that "Secure boot disabled" message. That's very weird.

With the CD I burned, the UEFI boot goes to the grub2 screen, and the non-UEFI boot goes to a graphic interface for the language selection and then on to the same debian installer. This pattern echoes the grub2/unetbootin discrepancy i was seeing on the flash drive. I'm sure the reasons for this are obvious to knowledgable people, but it's a little weird to me.

This is normal for Debian installer (affectionately called "d-i" at times). In BIOS mode it boots with a graphical splash; in UEFI mode it boots text mode.

Anyway, the other key difference, as mentioned before, is that the network would not intialize properly unless it booted via UEFI (flash drive or CD -- same deal.)

This one perplexes me. Um, does your firmware have a "Fast Boot" setting? If so, disable it.

Ok, installation completed! Looks like grub2 didn't install the bootloader, though... i'll have to sort that out...

BootRepair can fix that.

Anyhow, I'm also going to bed, but I'm going to try installing Kubuntu 13.04 from CD/UEFI tomorrow to see if that magically solves the crashing partition configuration step. If not, I'll press on with installing kubuntu-desktop.

I am no fan of Ubiquity. This is no reflection on the Kubuntu developers; what we have is largely unchanged from Ubuntu. Ubiquity just seems to have problems with anything beyond very basic setups. My standard route for building machines now is to use the server ISO and then install kubuntu-desktop.

[chconnor]

Updates:

- incidentally, the server CD passed "verification" where the flash drive based on the same image did not (though I believe the flash drive to be fine and I did make the flash drive with unetbootin and again with the KDE tool, so i think it's likely a bug in the verifier). So that's interesting.

- Kubuntu 13.04 UEFI booting from CD also failed at manual partition set up with same black-screen crashing as before. So that wasn't flash-drive related.

Now installing kubuntu-desktop.

I've not heard of such a bug before, and I think it would be widely reported. I suspect your problem lies elsewhere.

I did see a bunch of different forum posts and a few bugs about the installer failing... but I'm sure it's not common, yeah. In terms of the manual-partition-failure thing, some of the threads seemed to imply that it's getting more common -- that they used to be able to run the installer a few times and sometimes they'd get through it and it's been getting gradually worse and now they can't get through it at all. Perhaps hardware getting faster + increased used of flash drives = more race conditions? The launchpad bug reported above was started by a guy installing in a VM, so that lines up. Anyway, pointless conjecture. I thought i was finally free of those dumb plastic discs, but i guess they aren't quite out of my life. And installing server and then kubuntu-server is a fine workaround.

I know that Gigabyte's hybrid EFI has been the source of many problems in the past. Not sure about now, maybe they've changed to a better, more complete UEFI implementation. If you truly are booting to "classic" mode, you shouldn't even see that "Secure boot disabled" message. That's very weird.

There are further weirdnesses I won't even trouble you with. :-)

This one perplexes me. Um, does your firmware have a "Fast Boot" setting? If so, disable it.

It does, and it has been disabled. That behavior was totally consistent and repeatable: non-UEFI boot == no net. I chalked it up to some e1000e module bug since that's what seemed to be crashing (iirc the thread trace in the logs). Since i don't understand the technical differences between a UEFI and BIOS boot, i'm just guessing, of course.

BootRepair can fix that.

Thanks -- I booted the livecd and used grub-install and all is well. (via https://help.ubuntu.com/community/Grub2/Installing)