I installed F20-Beta TC1 in VirtualBox, without UEFI flag (own partitioning, x86_64, booting from netinst.iso) flawlessly. The installed system hangs on boot, only a black screen. Running the iso in the troubleshooting mode and (re)writing the grub2 boot record was possible. But still no boot possible (grub2 does not present any bootable system, only a command prompt).
Partition table:
Partition Table for /dev/sda
---Starting---- ----Ending----- Start Number of # Flags Head Sect Cyl ID Head Sect Cyl Sector Sectors -- ----- ---- ---- ----- ---- ---- ---- ----- ----------- ----------- 1 0x00 32 33 0 0x83 250 63 1019 2048 16384000 2 0x00 251 1 1019 0x83 241 55 1274 16386048 4096000 3 0x00 241 56 1274 0x82 232 47 1529 20482048 4096000 4 0x00 0 0 0 0x00 0 0 0 0 0
Kind regards
Joachim Backes
On Thu, 2013-10-03 at 11:09 +0200, Joachim Backes wrote:
I installed F20-Beta TC1 in VirtualBox, without UEFI flag (own partitioning, x86_64, booting from netinst.iso) flawlessly. The installed system hangs on boot, only a black screen. Running the iso in the troubleshooting mode and (re)writing the grub2 boot record was possible. But still no boot possible (grub2 does not present any bootable system, only a command prompt).
Partition table:
What filesystem(s) and mount points?
On 10/03/2013 11:59 AM, Adam Williamson wrote:
On Thu, 2013-10-03 at 11:09 +0200, Joachim Backes wrote:
I installed F20-Beta TC1 in VirtualBox, without UEFI flag (own partitioning, x86_64, booting from netinst.iso) flawlessly. The installed system hangs on boot, only a black screen. Running the iso in the troubleshooting mode and (re)writing the grub2 boot record was possible. But still no boot possible (grub2 does not present any bootable system, only a command prompt).
Partition table:
What filesystem(s) and mount points?
output of the mount command (in the rescue shell):
/dev/sda1 on / type ext4 (rw,relatime,seclabel,data=ordered) devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=362692k,nr_inodes=90673,mode=755) devpts on /dev/pts type devpts (rw,relatime,seclabel,gid=5,mode=620,ptmxmode=000) tmpfs on /dev/shm type tmpfs (rw,relatime,seclabel) /dev/sda2 on /home type ext4 (rw,relatime,seclabel,data=ordered) proc on /proc type proc (rw,relatime) tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755) sysfs on /sys type sysfs (rw,relatime,seclabel) selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
/etc/fstab:
# # /etc/fstab # Created by anaconda on Thu Oct 3 07:32:42 2013 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # UUID=e5ac9be3-0ff9-4478-8f6a-f13ae1dfcdcf / ext4 defaults 1 1 UUID=e70ba418-deb0-4af1-83fc-6e3ded10dd57 /home ext4 defaults 1 2 UUID=a892fae8-4a5a-487e-9927-8f3d1e0f3fa0 swap swap defaults 0 0
Kind regards
Joachim Backes
Fedora release 19 (Schrödinger’s Cat) Kernel-3.11.3-201.fc19.x86_64
Joachim Backes joachim.backes@rhrk.uni-kl.de https://www-user.rhrk.uni-kl.de/~backes
On 10/03/2013 05:09 AM, Joachim Backes wrote:
I installed F20-Beta TC1 in VirtualBox, without UEFI flag (own partitioning, x86_64, booting from netinst.iso) flawlessly. The installed system hangs on boot, only a black screen. Running the iso in the troubleshooting mode and (re)writing the grub2 boot record was possible. But still no boot possible (grub2 does not present any bootable system, only a command prompt).
Partition table:
Partition Table for /dev/sda
---Starting---- ----Ending----- Start Number of
# Flags Head Sect Cyl ID Head Sect Cyl Sector Sectors
1 0x00 32 33 0 0x83 250 63 1019 2048 16384000 2 0x00 251 1 1019 0x83 241 55 1274 16386048 4096000 3 0x00 241 56 1274 0x82 232 47 1529 20482048 4096000 4 0x00 0 0 0 0x00 0 0 0 0 0
Kind regards
Joachim Backes
On the other hand, my install of F20-Beta-TC1 on KVM virtual with all LVM "partitions" (boot, root, home, and swap) went smoothly (now using existing partitions). Software was basic gnome3 plus a little. Boots up and runs. I see that NetworkManager is back to "-12" which works but not for IPv6 yet.
Gene
TC1 netinst installation, booting, and initial operation nominal on a hardware E6550. Gnuradio compiled in normal time and passed all but one self test (the usual).
The TC1 USB stick netinst UEFI booted on an Asus P8z77v LE Plus was unable to modify the hard drive partitions.
Is UEFI boot a requirement for Heisenbug?
On Thursday, October 3, 2013, Chuck Forsberg WA7KGX caf@omen.com wrote:
TC1 netinst installation, booting, and initial operation nominal on a hardware E6550. Gnuradio compiled in normal time and passed all but one self test (the usual).
The TC1 USB stick netinst UEFI booted on an Asus P8z77v LE Plus was unable to modify the hard drive partitions.
Is UEFI boot a requirement for Heisenbug?
No.
On Fri, 2013-10-04 at 00:47 +0200, drago01 wrote:
On Thursday, October 3, 2013, Chuck Forsberg WA7KGX caf@omen.com wrote:
TC1 netinst installation, booting, and initial operation nominal on a hardware E6550. Gnuradio compiled in normal time and passed all but one self test (the usual).
The TC1 USB stick netinst UEFI booted on an Asus P8z77v LE Plus was unable to modify the hard drive partitions.
Is UEFI boot a requirement for Heisenbug?
No.
I think you misread Chuck's mail (I did at first). Just to be sure, here are answers to both of the possible questions:
1. Do you have to be using UEFI to install Fedora 20? Answer: No.
2. Is it a QA requirement that a normal UEFI install of Fedora 20 work? Answer: Yes.
On Fri, Oct 4, 2013 at 2:52 PM, Adam Williamson awilliam@redhat.com wrote:
On Fri, 2013-10-04 at 00:47 +0200, drago01 wrote:
On Thursday, October 3, 2013, Chuck Forsberg WA7KGX caf@omen.com wrote:
TC1 netinst installation, booting, and initial operation nominal on a hardware E6550. Gnuradio compiled in normal time and passed all but one self test (the usual).
The TC1 USB stick netinst UEFI booted on an Asus P8z77v LE Plus was unable to modify the hard drive partitions.
Is UEFI boot a requirement for Heisenbug?
No.
I think you misread Chuck's mail (I did at first). Just to be sure, here are answers to both of the possible questions:
- Do you have to be using UEFI to install Fedora 20?
Answer: No.
Yeah that's the question I answered.
On Oct 3, 2013, at 3:09 AM, Joachim Backes joachim.backes@rhrk.uni-kl.de wrote:
I installed F20-Beta TC1 in VirtualBox, without UEFI flag (own partitioning, x86_64, booting from netinst.iso) flawlessly. The installed system hangs on boot, only a black screen.
Works for me in a vbox VM.
Running the iso in the troubleshooting mode and (re)writing the grub2 boot record was possible. But still no boot possible (grub2 does not present any bootable system, only a command prompt).
Partition table:
Partition Table for /dev/sda
---Starting---- ----Ending----- Start Number of
# Flags Head Sect Cyl ID Head Sect Cyl Sector Sectors
1 0x00 32 33 0 0x83 250 63 1019 2048 16384000 2 0x00 251 1 1019 0x83 241 55 1274 16386048 4096000 3 0x00 241 56 1274 0x82 232 47 1529 20482048 4096000 4 0x00 0 0 0 0x00 0 0 0 0 0
I'm not familiar with this output. I don't see partition type codes. If that's supposed to be the first column, they're all wrong. And none are marked bootable either (although with GRUB2 boot.img installed in the MBR bootstrap region that should not matter).
What output do you get from 'fdisk -l' and 'parted -s /dev/sda u s p'
Chris Murphy
On 2013-10-03 13:46 (GMT-0600) Chris Murphy composed:
Joachim Backes wrote:
...own partitioning...
Partition Table for /dev/sda
---Starting---- ----Ending----- Start Number of
# Flags Head Sect Cyl ID Head Sect Cyl Sector Sectors
1 0x00 32 33 0 0x83 250 63 1019 2048 16384000 2 0x00 251 1 1019 0x83 241 55 1274 16386048 4096000 3 0x00 241 56 1274 0x82 232 47 1529 20482048 4096000 4 0x00 0 0 0 0x00 0 0 0 0 0
I'm not familiar with this output. I don't see partition type codes. If that's supposed to be the first column, they're all wrong. And none are marked bootable either (although with GRUB2 boot.img installed in the MBR bootstrap region that should not matter).
It does make me wonder what tool created "own partitioning", but the types are right there in the unfamiliarly located ID column. The bootable flag is only relevant to legacy compatible MBR code, which AFAIK no Grub, or Lilo or Syslinux, has ever been.
On Oct 3, 2013, at 5:20 PM, Felix Miata mrmazda@earthlink.net wrote:
On 2013-10-03 13:46 (GMT-0600) Chris Murphy composed:
Joachim Backes wrote:
...own partitioning...
Partition Table for /dev/sda
---Starting---- ----Ending----- Start Number of
# Flags Head Sect Cyl ID Head Sect Cyl Sector Sectors
1 0x00 32 33 0 0x83 250 63 1019 2048 16384000 2 0x00 251 1 1019 0x83 241 55 1274 16386048 4096000 3 0x00 241 56 1274 0x82 232 47 1529 20482048 4096000 4 0x00 0 0 0 0x00 0 0 0 0 0
I'm not familiar with this output. I don't see partition type codes. If that's supposed to be the first column, they're all wrong. And none are marked bootable either (although with GRUB2 boot.img installed in the MBR bootstrap region that should not matter).
It does make me wonder what tool created "own partitioning", but the types are right there in the unfamiliarly located ID column.
Doh! That's right.
Double doh, I might be having a similar problem. Now that I've read the subject, and this applies to beta TC1 and not alpha, I just tried booting vbox with beta KDE and while I did get syslinux, I have a black screen after that.
Chris Murphy
On Oct 3, 2013, at 6:53 PM, Chris Murphy lists@colorremedies.com wrote:
Doh! That's right.
Double doh, I might be having a similar problem. Now that I've read the subject, and this applies to beta TC1 and not alpha, I just tried booting vbox with beta KDE and while I did get syslinux, I have a black screen after that.
Reproduced on baremetal. Me thinks something isn't quite right with this TC1…
Chris Murphy