| |||||||||||||
The Grumpy Editor's Fedora 18 experienceThe Grumpy Editor's Fedora 18 experiencePosted Jan 15, 2013 17:00 UTC (Tue) by quintesse (subscriber, #14569)Parent article: The Grumpy Editor's Fedora 18 experience
I'm just getting a message that it can't find the boot images. Looking at what the mirror manager returns it seems that the only fedora-install-18 repository available is for ppc64 arch. Don't see any mention on the fedora website though that they're working on a problem or anything.
(Log in to post comments)
The Grumpy Editor's Fedora 18 experience Posted Jan 15, 2013 17:14 UTC (Tue) by mattdm (subscriber, #18) [Link]
First I've seen a report like this. Can you give some more details? (Ideally either post to fedora-users list or to http://ask.fedoraproject.org )
The Grumpy Editor's Fedora 18 experience Posted Jan 15, 2013 17:28 UTC (Tue) by nirik (subscriber, #71) [Link]
Yes, there's a known issue with mirrormanager and fedup right now.
Please hang on, we are working hard to fix it. ;)
The Grumpy Editor's Fedora 18 experience Posted Jan 15, 2013 18:07 UTC (Tue) by quintesse (subscriber, #14569) [Link]
It's not the first time that a new Fedora release has had problems that prevented installation and it's not the first time I've thought that it would be a great idea to have some kind of online service that the upgrader/installer could use to display urgent informational messages.
The simplest thing would maybe be a link to some web page that appears if the installation fails. The web page could list all the currently known installer problems that they found out about after the installer was released.
But especially in the case of the installer where you might actually be trying to install on your only computer (not so common anymore these days with smart phones, but still) so checking the internet might be a problem it would be nice if those problems(hopefully with solutions) might be displayed right in the installer.
The Grumpy Editor's Fedora 18 experience Posted Jan 15, 2013 19:22 UTC (Tue) by nirik (subscriber, #71) [Link]
I don't disagree with you. ;) Would be nice to have a single place to update everyone that there's a problem being worked on and then notify them when it's fixed.
The Grumpy Editor's Fedora 18 experience Posted Jan 16, 2013 9:22 UTC (Wed) by rvfh (subscriber, #31018) [Link]
It's called Twitter :-P
The Grumpy Editor's Fedora 18 experience Posted Jan 17, 2013 0:08 UTC (Thu) by voltagex (subscriber, #86296) [Link]
Could be good to include that feed in Anaconda.
The Grumpy Editor's Fedora 18 experience Posted Jan 18, 2013 13:49 UTC (Fri) by drag (subscriber, #31333) [Link]
that sounds terrible.
The Grumpy Editor's Fedora 18 experience Posted Jan 25, 2013 10:54 UTC (Fri) by mgedmin (subscriber, #34497) [Link]
Ubuntu did that in their installer. A bit later they discovered some HTML injection vulnerability in the Twitter feed display code.
The Grumpy Editor's Fedora 18 experience Posted Jan 15, 2013 19:21 UTC (Tue) by nirik (subscriber, #71) [Link]
fedup should be happy and working for network upgrades again now. ;)
The Grumpy Editor's Fedora 18 experience Posted Jan 15, 2013 21:49 UTC (Tue) by quintesse (subscriber, #14569) [Link]
Upgrading right now, thx! ;)
The Grumpy Editor's Fedora 18 experience Posted Jan 16, 2013 0:01 UTC (Wed) by quintesse (subscriber, #14569) [Link]
OMG they made it impossible to disable "suspend on lid close" (they even removed it from the tweak ui and no extension either, this is becoming so ridiculous)
The Grumpy Editor's Fedora 18 experience Posted Jan 16, 2013 0:16 UTC (Wed) by nirik (subscriber, #71) [Link]
It's now handled (by default) by systemd.
Either:
a) edit /etc/systemd/logind.conf and tell it to not do that.
or
b) run systemd-inhibit to prevent it from doing so when you don't want it to.
The Grumpy Editor's Fedora 18 experience Posted Jan 16, 2013 0:38 UTC (Wed) by quintesse (subscriber, #14569) [Link]
I tried editing the logind.conf but it didn't seem to do anything, is there some service that has to be restarted first?
(I also tried systemd-inhibit, but all the examples I find seem to be missing some important part because the command always complains)
The Grumpy Editor's Fedora 18 experience Posted Jan 16, 2013 4:48 UTC (Wed) by mezcalero (subscriber, #45103) [Link]
yes, restart systemd-logind
The Grumpy Editor's Fedora 18 experience Posted Jan 16, 2013 10:44 UTC (Wed) by jospoortvliet (subscriber, #33164) [Link]
Should this even have gone in without a way to disable it (preferably the same way it used to be possible to disable)? I think it's a good feature and a reasonable place to put this feature - but some degree of user control shouldn't be optional. I'm rather unhappy not to be able to easily control power management.
Are there hooks for the UI to control this, Lennart?
(I use the feature to disable power management in the battery applet frequently, it's a smart and useful feature which I'd rather not see broken)
I'll surely test this feature for the upcoming openSUSE 12.3 release to make sure I raise a bug if this is an issue there too. I'd rather not have us ship it this way.
The Grumpy Editor's Fedora 18 experience Posted Jan 16, 2013 22:50 UTC (Wed) by mezcalero (subscriber, #45103) [Link]
DEs can control the stuff on their own if they wish. logind only does that if no DE is around or if the DE is too simply to do lid switch handling of its own.
With other words: KDE can do whatever it wants, it can tell logind to stay away from the lid switch, or it can leave logind in control, and can even dynamically do that at any time.
GNOME for example tells logind to stay away from the lid switch if an external monitor is plugged in, but otherwise let's logind handle everything.
Joke alert Posted Jan 17, 2013 18:16 UTC (Thu) by man_ls (subscriber, #15091) [Link] What!? You mean to say that systemd doesn't have its own embedded desktop environment yet? Really hope you are working on it! (Disableable of course. Is that a word? Apparently not.)
Joke alert Posted Jan 18, 2013 10:41 UTC (Fri) by dgm (subscriber, #49227) [Link]
A desktop environment? Why?
I hereby propose that systemd gets merged with Emacs. Think of the possibilities! It would become sentient in less than 24 hours...
:-P
Joke alert Posted Jan 18, 2013 16:12 UTC (Fri) by man_ls (subscriber, #15091) [Link] I hereby propose your message as "LWN comment of the week".
Joke alert Posted Jan 22, 2013 23:59 UTC (Tue) by DonDiego (subscriber, #24141) [Link]
That's at least the comment of the month and let's see if anybody gets close in 2013 ;-p
Joke alert Posted Jan 18, 2013 22:49 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
But whose personality would it have? Stallman's? Lennart's? It's going to have a lot of enemies to start out either way…
Joke alert Posted Jan 19, 2013 15:52 UTC (Sat) by nix (subscriber, #2304) [Link]
You can already run Emacs as /sbin/init, so *obviously* the solution is to reimplement systemd in Emacs Lisp. (We might need to wait for the concurrency branch to mature, so as not to block for too long.)
My normal arguments about init being critical software and thus being software that should not change too fast (because if it dies the system is useless and instantly panics) is moot here, because if your Emacs dies your system is useless in any case. I mean, what else is an OS for?
Joke alert Posted Jan 19, 2013 16:44 UTC (Sat) by apoelstra (subscriber, #75205) [Link]
>You can already run Emacs as /sbin/init,
This isn't true, is it? Do people do that?
I'm scared to try because I don't know Emacs well enough to undo it.
Joke alert Posted Jan 19, 2013 20:10 UTC (Sat) by tom.prince (subscriber, #70680) [Link]
> I'm scared to try because I don't know Emacs well enough to undo it.
If you just pass init=/usr/bin/emacs on the kernel command line, you shouldn't need to do anything to undo it.
Joke alert Posted Jan 20, 2013 8:04 UTC (Sun) by apoelstra (subscriber, #75205) [Link]
> If you just pass init=/usr/bin/emacs on the kernel command line, you shouldn't need to do anything to undo it.
That didn't work. Maybe this is a bug in Fedora's initram, because it worked the last time I tried it (several years ago, and with an actual init program).
For those curious, I did manage to do it though, by popping open my initramfs and adding an explicit INIT=/bin/emacs after the code which sets the INIT variable. The result was emacs saying "cannot open /dev/tty" and bailing, and then the kernel panicked.
If only udev had been merged into emacs..
The Grumpy Editor's Fedora 18 experience Posted Jan 16, 2013 0:27 UTC (Wed) by mezcalero (subscriber, #45103) [Link]
HandleLidSwitch=ignore in /etc/systemd/logind.conf
The Grumpy Editor's Fedora 18 experience Posted Jan 16, 2013 7:11 UTC (Wed) by ekj (guest, #1524) [Link]
Is there also "IgnoreIfOnWallPowerOtherwiseSuspend" ?
The Grumpy Editor's Fedora 18 experience Posted Jan 16, 2013 13:34 UTC (Wed) by cortana (subscriber, #24596) [Link]
Perhaps the kernel needs to grow a virtual machine to run a program which can more precisely control the conditions under which the system is suspended.
The Grumpy Editor's Fedora 18 experience Posted Jan 16, 2013 13:40 UTC (Wed) by ekj (guest, #1524) [Link]
If you need real flexibility it's better to run a userspace-program when something related to power-status changes, and let that program decide what to do.
But having different rules for what to do when you're plugged in, relative to when you're on battery-power is something that's fairly standard, and something there's a good reason for.
The Grumpy Editor's Fedora 18 experience Posted Jan 29, 2013 15:16 UTC (Tue) by oblio (guest, #33465) [Link]
Windows has already grown this "virtual machine", since it has different power setting depending on the power source: battery or plugged in.
I doesn't seem to absurd to not make the laptop suspend when the lid is closed while plugged in, since it could use an external display and keyboard. But when it's not plugged in you don't want it chugging along in your backpack, getting fried due to the lack of ventilation.
The Grumpy Editor's Fedora 18 experience Posted Jan 16, 2013 15:24 UTC (Wed) by lkundrak (subscriber, #43452) [Link]
Seconded. I find this use case very useful.
When the machine is plugged in, I mostly close the lid to turn off the screen so that it does not disturb me from sleep, but can still be alive finishing a build.
When it's not plugged, I'm probably travelling and I close the lid so that I can carry the laptop in my bag.
This even sounds like a sane default to me and I'll miss the setting terribly if it goes away from my desktop.
The Grumpy Editor's Fedora 18 experience Posted Jan 16, 2013 18:45 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
In systemd 196, I added the option of 'lock' to the lid switch, though it appears as though F18 has 195 and probably won't get that upgrade (though a backport should be minimal work/maintenence; I'd certainly love to see it in RHEL7 at least). This causes all sessions to receive a 'lock' signal. If there's a signal for when the lid closes as well, the listener in the DEs could check if they're on AC and suspend if so. I'm writing a minimal Python daemon which does what I want (with flexibility); haven't worked on it for a while though.
The Grumpy Editor's Fedora 18 experience Posted Jan 17, 2013 8:52 UTC (Thu) by michich (subscriber, #17902) [Link]
F18 is going to get an update to systemd v197. It's in updates-testing now: https://admin.fedoraproject.org/updates/FEDORA-2013-0655/...
The Grumpy Editor's Fedora 18 experience Posted Jan 18, 2013 22:37 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
Ah, I had missed it in Koji because it has a trailing '.1' instead of fc18. Sounds good :) .
The Grumpy Editor's Fedora 18 experience Posted Jan 18, 2013 9:06 UTC (Fri) by Kamilion (subscriber, #42576) [Link]
Forgive me for sidebusting here, both as a normally ubuntu user and the occasional windows 7 gamer. I've been playing with FC18-lxde in a client project for the last few days, but have been actively lurking the systemd and wayland MLs since they were wee footnotes on LWN, and frowning my little heart out at *ubuntu for keeping upstart over systemd. But hey, least it isn't the tangle of LFS sysv scripts or openrc!
My Asus netbook currently has the exact settings you speak of, under windows 7. If the machine is on AC, display off. If the machine is on battery, suspend. I find myself instinctively pulling the cord out before closing the screen when I'm about to take it somewhere. Just consider it another plus one to the idea, since I think it's Asus's fancy 'superhybridengine' power profiles that seem to invoke this behavior.
On the upside, FC18 ships with systemd 19*, so it'd be pretty sane to send a patch to the ML and expect to be able to build and utilize the resulting fix. (haha, systemd-44 patches? YGTBSM.)
The Grumpy Editor's Fedora 18 experience Posted Jan 29, 2013 8:15 UTC (Tue) by Duncan (guest, #6647) [Link]
Anybody that's serious about having their laptop run differently on wall power than it does on battery should have a look at laptop-mode-tools.
Originally designed to deal with the kernel's laptop-mode, it now ships a plethora of scripts designed to control all sorts of things. The defaults are sane and reasonable in most cases, but those who feel the need can tweak settings to their heart's content (as naturally I have, being a gentooer =:^)
rpmfind doesn't appear to list any fedora packages, but it does list mandriva/opensuse/sourceforge/mageia/dagfabian-rhel noarch packages, upto 1.61, which is only a version behind the 1.62 that's showing up here on gentoo (and that adds systemd support according to the changelog, so anyone running that will probably want to grab 1.62 from the home page, there's Fedora-specific instructions), and it lists homepages/sites for it as well, so that would appear to be a reasonable place for rpm-based-distro folks at least to start looking for more, if they're interested.
http://www.rpmfind.net/linux/rpm2html/search.php?query=la...
http://www.samwel.tk/laptop_mode/
But you really have to take a look in the tarball to see all the modules it comes with, and thus the configuration options. =:^)
While I don't see a direct lid-switch module in the 1.60 tarball that's what I have on my (slightly dated) netbook install, there's hooks for adding commandlines to execute at plug/unplug, and it'd be simple enough to add the commands above, there.
Duncan
The Grumpy Editor's Fedora 18 experience Posted Jan 16, 2013 22:54 UTC (Wed) by mezcalero (subscriber, #45103) [Link]
We only implement the most basic policy in systemd's logind: We give the user/admin a way to disable logind's built-in lid switch handling entirely, and we give DEs/apps a way to turn it off temporarily. DEs may then build on that and implement a smarter policy, that takes other conditions into account.
GNOME for example turns off lid switch handling if an external monitor is plugged in. If you want a different policy, file a bug against GNOME or hack it up yourself.
The Grumpy Editor's Fedora 18 experience Posted Jan 16, 2013 2:58 UTC (Wed) by apoelstra (subscriber, #75205) [Link]
Thanks, done! Wow, that was easy. My DVD drive died since installing Fedora 17, so I was hoping that there'd be such a simple upgrade process for 18.
However, I did encounter a problem: after asking for my disk password, systemd only decrypts my / partition, not my /home, which caused a cascading effect and dropped me into an emergency shell.
Running journalctl showed the original problem as:
Jan 15 18:05:45 titanic systemd-tty-ask-password-agent[527]: open(/run/systemd/ask-password/ask.jgeHtn): Permission denied
I was very impressed with journalctl's verbose output, but it didn't tell me where "ask.jgeHtn" was created (or destroyed, since 'ls' did not find it from the emergency shell). So I had no way to get more detailed information about what was going on.
In the end, I disabled selinux (that's the fix for "Permission Denied" as root, right? ;)) and typed 'systemctl default' to continue booting, which is okay for now. Later I will see how to fix my policy properly.
What is the proper channel to report this?
The Grumpy Editor's Fedora 18 experience Posted Jan 16, 2013 4:47 UTC (Wed) by mezcalero (subscriber, #45103) [Link]
That's a temporary file that is renamed later on to the real name. Sounds like an selinux AVC, and should be reported on rhbz against the selinux-policy package.
The Grumpy Editor's Fedora 18 experience Posted Jan 17, 2013 13:20 UTC (Thu) by cesarb (subscriber, #6266) [Link]
> My DVD drive died since installing Fedora 17
You can simply dd the ISO to a USB flash drive and boot from it. I have not tested with Fedora 18 yet, but it has worked that way for several releases.
|
|||||||||||||