Debugging Fedora UEFI boot problems on Intel DQ77MK
by Pasi Kärkkäinen
Hello,
I hope someone here can help me out..
I have a new Intel DQ77MK motherboard, based on the Intel Q77 chipset.
CPU is Intel Ivy Bridge i7-3770.
I'm running the latest BIOS version (0048), and UEFI boot is enabled in the BIOS.
I've tried UEFI booting the following operating systems from burned DVDR discs:
- Fedora 16 x64 DVD.
- Fedora 17 x64 DVD.
- Redhat Enterprise Linux (RHEL) 6.3 Server DVD. (Redhat Linux is supposed to be UEFI supported per the motherboard manuals).
UEFI boot fails with all of the listed operating systems. Symptoms:
- I get the Fedora/RHEL EFI boot menu, and I let it boot with the default options.
- I get text on the screen about allocating memory pages for Linux-EFI, loading VMLINUZ, etc.
- The screen goes empty/black, there's only a cursor blinking, and nothing happens..
- The boot failed or is stuck with nothing happening. I need to reset the box.
It looks like Linux kernel doesn't get started at all.. so it could be a UEFI firmware or a bootloader problem.
I'm actually expecting this is an Intel BIOS/UEFI firmware bug,
because I've seen reports about UEFI boot problems on other Intel 7-series chipset aswell.
Does anyone know how to debug/troubleshoot UEFI boot problems?
The motherboard in question has Intel vPro/AMT, so it has SOL, so I could use a serial console,
if there's a way to use it with UEFI/bootloader before Linux is started..
Any help is welcome!
Thanks,
-- Pasi
11 years, 6 months
Network configuration future
by Olaf Kirch
Hi all,
I would like to revive a proposal that I have made a while ago, regarding
a framework for managing network interfaces. I called it wicked at that time,
and it's still called that way, but because of potential confusion with WICD
I'll probably change the name soonishly.
This project has been going on for a while now, and is getting into a more
presentable shape.
Given the breadth and the width of the whole topic, I won't be able to
cover all aspects of the system in one email - instead, I want to give you
my perspective on why I think we need something new, and what it should
look like from my point of view.
While I my original motivation in working on this is from a SUSE perspective,
I believe other Linux distributions can benefit from this as well, and I'd
be happy to work on this cross-distribution.
Your feedback is very much welcome!
Regards,
Olaf
--
Neo didn't bring down the Matrix. SOA did. (soafacts.com)
--------------------------------------------
Olaf Kirch - Director SUSE Linux Enterprise; R&D (okir(a)suse.com)
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
11 years, 7 months
Announcing OLPC OS 12.1.0 for XO-1, XO-1.5 and XO-1.75
by Daniel Drake
Hi,
We're pleased to announce the release of OLPC OS 12.1.0 for XO-1,
XO-1.5 and XO-1.75. Details of new features, known issues, and how to
download/install/upgrade can all be found in the release notes:
http://wiki.laptop.org/go/Release_notes/12.1.0
Many thanks to all contributors, testers, upstreams, and those who
have provided feedback of any kind.
For those who were following the release candidate process in the last
few weeks: candidate build 21 is released as final with no changes.
Thanks and enjoy!
Daniel
11 years, 7 months
orphan most of my packages
by Andy Shevchenko
Hello,
I have no more time to support the following packages in the Fedora.
jack-audio-connection-kit -- The Jack Audio Connection Kit
klamav -- Clam Anti-Virus on the KDE Desktop
man-pages-uk -- Ukrainian man pages from the Linux Documentation Project
python-alsa -- Python binding for the ALSA library
qstat -- Real-time Game Server Status for FPS game servers
uniconvertor -- Universal vector graphics translator
--
With Best Regards,
Andy Shevchenko
11 years, 7 months
[HEADS-UP] Rawhide: /tmp is now on tmpfs
by Lennart Poettering
Heya!
Please be aware that since the most recent systemd uploads /tmp is now
in tmpfs by default in Rawhide/F18.
For details please see this feature page:
https://fedoraproject.org/wiki/Features/tmp-on-tmpfs
If you have an explicit /tmp entry in fstab things should continue to
work the same as before. If you don't then you will now get a tmpfs on
/tmp by default.
This will most likely lead to a problem or two with software that isn't
happy about /tmp being small. We have created a tracker bug to keep
track of this:
https://bugzilla.redhat.com/show_bug.cgi?id=826015
If you have identified a bug that is triggered by /tmp being on tmpfs
now, please add it to this tracker bug!
For a bit of background on all of this and recommendations for
developers, please see:
http://0pointer.de/blog/projects/tmp.html
Thank you,
Lennart
--
Lennart Poettering - Red Hat, Inc.
11 years, 7 months
Systemd macros (f18+)
by Simone Caronni
Hello,
sorry to bring up the discussion again but I still have some grey areas in
my head.
According to the systemd snippets [1], the new macros should be only for
NEW packages, i.e. those that never had a SysV init script.
I have a few questions:
1- Since the packages I mantain build on RHEL5+ and Fedora 16+ (and have
for a long time), can I assume these macros in the spec file is optional?
If that's the case, what should I do with the bugs opened?
2- What's the status of the back-port of those macros to F16/F17 (with a
different expansion of course)? Is it under evaluation? Should I wait for
the resolution of this before starting to add the macros?
3- If I should start putting the macros in now in the spec files and still
keep the option to build the same package on all EPEL/Fedora supported
distributions, can I assume RHEL 7 = Fedora 18 for the various %if/%elif?
Thanks,
--Simone
[1] https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
--
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).
11 years, 7 months
Rawhide boot problems
by Jerry James
I've got two Rawhide VMs, one x86_64, one i686, both otherwise
identical. I last booted them yesterday and did a yum repo-sync.
Today, neither of them will boot.
First, systemd complained about being unable to find
systemd-journal-flush.service. Sure enough, it wasn't in the
initramfs. So I added
"$systemdsystemunitdir/systemd-journal-flush.service" to
/usr/lib/dracut/modules.d/98systemd/module-setup.sh, and regenerated
the initramfs. Now the boot gets past that point, but starts doing
this over and over, apparently forever, even in emergency mode:
[ OK ] Reached target Basic System.
[ 5.337054] systemd-journald[722]: Received SIGUSR1
[ 5.364465] systemd-udevd[763]: worker [817] did not accept message -1
(Connection refused), kill it
[ 5.372587] systemd-udevd[763]: worker [821] did not accept message -1
(Connection refused), kill it
[ 5.373956] systemd-udevd[763]: worker [823] did not accept message -1
(Connection refused), kill it
[ 5.375104] systemd-udevd[763]: worker [824] did not accept message -1
(Connection refused), kill it
[ 5.376358] systemd-udevd[763]: worker [826] did not accept message -1
(Connection refused), kill it
[ 5.377670] systemd-udevd[763]: worker [829] did not accept message -1
(Connection refused), kill it
[ 5.378890] systemd-udevd[763]: worker [831] did not accept message -1
(Connection refused), kill it
[ 5.380187] systemd-udevd[763]: worker [834] did not accept message -1
(Connection refused), kill it
[ 5.381802] systemd-udevd[763]: worker [837] did not accept message -1
(Connection refused), kill it
[ 5.383105] systemd-udevd[763]: worker [838] did not accept message -1
(Connection refused), kill it
[ 5.386671] systemd-udevd[763]: worker [786] did not accept message -1
(Connection refused), kill it
[ 35.340097] systemd-journald[722]: Received SIGTERM
[ 35.356677] systemd[1]: Running in intial RAM disk.
Welcome to Fedora 19 (Rawhide) dracut-023-2.fc18 (Initramfs)!
Starting Journal Service...
Starting Dracut cmdline hook...
[ OK ] Reached target Sockets.
[ OK ] Listening on udev Kernel Socket.
[ OK ] Listening on udev Control Socket.
[ OK ] Reached target Encrypted Volumes.
Starting Setup Virtual Console...
[ OK ] Reached target Swap.
[ OK ] Reached target Local File Systems.
Starting Tell Plymouth To Write Out Runtime Data...
[ 35.531873] systemd[1]: systemd-journald.service holdoff time over,
scheduling restart.
[ OK ] Started Tell Plymouth To Write Out Runtime Data.
[ OK ] Stopped Trigger Flushing of Journal to Persistent Storage.
Stopping Journal Service...
[ OK ] Stopped Journal Service.
Starting Journal Service...
[ OK ] Started Journal Service.
Starting Trigger Flushing of Journal to Persistent Storage...
[ 35.884485] systemd-journald[881]: Fixed max_use=48.9M max_size=6.1M
min_size=64.0K keep_free=24.4M
[ 35.895630] systemd-journald[881]: Vacuuming...
[ OK ] Started Trigger Flushing of Journal to Persistent Storage.
[ 35.945177] systemd-journald[881]: Received SIGUSR1
[ OK ] Started Setup Virtual Console.
[ OK ] Reached target System Initialization.
dracut-cmdline[885]: Warning: Option 'KEYTABLE' is deprecated, use
'KEYMAP' instead.
dracut-cmdline[885]: Warning: Option 'SYSFONT' is deprecated, use
'FONT' instead.
[ OK ] Started Dracut cmdline hook.
Starting Dracut pre-udev hook...
[ OK ] Started Dracut pre-udev hook.
Starting udev Kernel Device Manager...
[ 36.107496] system-udevd[948]: starting version 188
[ OK ] Started udev Kernel Device Manager.
Starting Dracut pre-trigger hook...
[ OK ] Reached target Basic System.
[ 36.691716] systemd-journald[881]: Received SIGUSR1
...
Does anybody recognize the problem?
--
Jerry James
http://www.jamezone.org/
11 years, 7 months
FusionInventory stack need a new maintainer, or a co-maintainer, or be ORPHAN
by Remi Collet
Hi,
I currently maintains fusioninventory stack in Fedora / EPEL
fusioninventory-agent
perl-FusionInventory-Agent-Task-Deploy
perl-FusionInventory-Agent-Task-ESX
perl-FusionInventory-Agent-Task-NetDiscovery (to be EOL)
perl-FusionInventory-Agent-Task-NetInventory (new in F18, to be EOL)
perl-FusionInventory-Agent-Task-OcsDeploy (EOL in f17)
perl-FusionInventory-Agent-Task-SNMPQuery (EOL in f18)
Missing (new) package
perl-FusionInventory-Agent-Task-Network
(which replace Task-NetDiscovery and Task-NetInventory)
Because of lack of time (new job), lack of interest (I don't use it
anymore) and lack of understandind with upstream, this stack need a new
maintainer.
I will also accept a co-maintainer, to work with (for some time)
Else, I plan to orphan this stack and ask to remove packages from
repositories
Remi.
11 years, 7 months
