Upgrading to Fedora 20 using fedup - what is the ISO format wanted?
I have an iso image of the Fedora 20 install DVD, but when I try to use it I get this:
fedup -v --iso Fedora-20-x86_64-DVD.iso --network 20 usage: fedup <SOURCE> [options] fedup: error: argument --iso: invalid isofile value: 'Fedora-20-x86_64-DVD.iso'
I wrote this exact iso file to a stick. mounted it, and used the "--device DEV" option, and successfully ran the upgrade, so I would like to know for the future what does the "--iso" option really want?
Allan Duncan <amd2345@fastmail.com.au> wrote:
I have an iso image of the Fedora 20 install DVD, but when I try to use it I get this:
fedup -v --iso Fedora-20-x86_64-DVD.iso --network 20 usage: fedup <SOURCE> [options] fedup: error: argument --iso: invalid isofile value: 'Fedora-20-x86_64-DVD.iso'
Just an idea (I've never used this tool), perhaps try omitting the ".iso" extension from the file name, in case this is appended to whatever name you specify. This would be unusual behaviour, of course, but not entirely out of the question.
On 21/12/13 20:29, Jason White wrote:
Allan Duncan <amd2345@fastmail.com.au> wrote:
I have an iso image of the Fedora 20 install DVD, but when I try to use it I get this:
fedup -v --iso Fedora-20-x86_64-DVD.iso --network 20 usage: fedup <SOURCE> [options] fedup: error: argument --iso: invalid isofile value: 'Fedora-20-x86_64-DVD.iso'
Just an idea (I've never used this tool), perhaps try omitting the ".iso" extension from the file name, in case this is appended to whatever name you specify. This would be unusual behaviour, of course, but not entirely out of the question.
Not in this case, it just turns into File not found
On Sat, Dec 21, 2013 at 8:57 PM, Allan Duncan <amd2345@fastmail.com.au> wrote:
On 21/12/13 20:29, Jason White wrote:
Allan Duncan <amd2345@fastmail.com.au> wrote:
I have an iso image of the Fedora 20 install DVD, but when I try to use it I get this:
fedup -v --iso Fedora-20-x86_64-DVD.iso --network 20 usage: fedup <SOURCE> [options] fedup: error: argument --iso: invalid isofile value: 'Fedora-20-x86_64-DVD.iso'
Just an idea (I've never used this tool), perhaps try omitting the ".iso" extension from the file name, in case this is appended to whatever name you specify. This would be unusual behaviour, of course, but not entirely out of the question.
Not in this case, it just turns into File not found
I just googled fedup and found this https://fedoraproject.org/wiki/FedUp#ISO_File from the page it looks like you have to define the full path "For the sake of example, we will assume that the ISO exists at /home/user/fedora-20.iso but it can be anywhere in the filesystem as long as you alter the path below to reflect the actual location of the ISO" and it also looks like the command to run is fedup-cli as superuser also from the page... sudo fedup-cli --iso /home/user/fedora-20.iso I may be way of base as I am an apt-get upgrade person myself so YMMV -- Mark "Pockets" Clohesy Mob Phone: (+61) 406 417 877 Email: hiddensoul@twistedsouls.com G-Talk: mark.clohesy@gmail.com GNU/Linux..Linux Counter #457297 - "I would love to change the world, but they won't give me the source code" "Linux is user friendly...its just selective about who its friends are"
On 21/12/13 22:05, Hiddensoul (Mark Clohesy) wrote:
On Sat, Dec 21, 2013 at 8:57 PM, Allan Duncan <amd2345@fastmail.com.au> wrote:
On 21/12/13 20:29, Jason White wrote:
Allan Duncan <amd2345@fastmail.com.au> wrote:
I have an iso image of the Fedora 20 install DVD, but when I try to use it I get this:
fedup -v --iso Fedora-20-x86_64-DVD.iso --network 20 usage: fedup <SOURCE> [options] fedup: error: argument --iso: invalid isofile value: 'Fedora-20-x86_64-DVD.iso'
Just an idea (I've never used this tool), perhaps try omitting the ".iso" extension from the file name, in case this is appended to whatever name you specify. This would be unusual behaviour, of course, but not entirely out of the question.
Not in this case, it just turns into File not found
I just googled fedup and found this https://fedoraproject.org/wiki/FedUp#ISO_File from the page it looks like you have to define the full path
"For the sake of example, we will assume that the ISO exists at /home/user/fedora-20.iso but it can be anywhere in the filesystem as long as you alter the path below to reflect the actual location of the ISO"
and it also looks like the command to run is fedup-cli as superuser also from the page...
sudo fedup-cli --iso /home/user/fedora-20.iso
I may be way of base as I am an apt-get upgrade person myself so YMMV
Been there, done that. It finds the file, but isn't happy with what it wanrs.
On Sat, 21 Dec 2013 10:26:31 PM Allan Duncan wrote:
It finds the file, but isn't happy with what it wanrs
It is the install DVD and not a live DVD? Do the checksums match? cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP
On 21/12/13 22:28, Chris Samuel wrote:
On Sat, 21 Dec 2013 10:26:31 PM Allan Duncan wrote:
It finds the file, but isn't happy with what it wanrs
It is the install DVD and not a live DVD? Do the checksums match?
Yep and yep.
On 21/12/13 22:30, Allan Duncan wrote:
On 21/12/13 22:28, Chris Samuel wrote:
On Sat, 21 Dec 2013 10:26:31 PM Allan Duncan wrote:
It finds the file, but isn't happy with what it wanrs
It is the install DVD and not a live DVD? Do the checksums match?
Yep and yep. hi
there is a lots of messages on the G+ Fedora Project Community about updating to Fed-20 as there are out of date packages blocking the update and other issues. https://plus.google.com/communities/109103154272245339550 ensure all your configs are backed-up and systemd is more invasive with this release. fedup needs to be vsn 0.8 # yum --enablerepo=updates-testing update fedup should update to vsn 0.8 # yum clean metadata ; yum --skip-broken update # fedup-cli --iso <full path the dvd.iso> --debuglog=/root/fedupdebug.log reboot this should be sufficient, but the update may bring down 1GB of packages Steve
On 22/12/13 21:01, Steve Roylance wrote:
On 21/12/13 22:30, Allan Duncan wrote:
On 21/12/13 22:28, Chris Samuel wrote:
On Sat, 21 Dec 2013 10:26:31 PM Allan Duncan wrote:
It finds the file, but isn't happy with what it wanrs
It is the install DVD and not a live DVD? Do the checksums match?
Yep and yep. hi
there is a lots of messages on the G+ Fedora Project Community about updating to Fed-20 as there are out of date packages blocking the update and other issues.
https://plus.google.com/communities/109103154272245339550 ensure all your configs are backed-up and systemd is more invasive with this release.
fedup needs to be vsn 0.8 # yum --enablerepo=updates-testing update fedup should update to vsn 0.8 # yum clean metadata ; yum --skip-broken update # fedup-cli --iso <full path the dvd.iso> --debuglog=/root/fedupdebug.log reboot this should be sufficient, but the update may bring down 1GB of packages
It's the --iso <full path the dvd.iso> that is breaking. It finds the iso file but doesn't like what it finds. Writing said file to a stick, mounting it, and using --device <dev> works fine. It was 1.4 G of download, but my yum.conf has entries for the internode mirror so all it costs is time. Therefore to some extent this is a curiousity thing.
On 22/12/13 23:29, Allan Duncan wrote:
It's the --iso <full path the dvd.iso> that is breaking. It finds the iso file but doesn't like what it finds. Writing said file to a stick, mounting it, and using --device <dev> works fine. It was 1.4 G of download, but my yum.conf has entries for the internode mirror so all it costs is time. Therefore to some extent this is a curiousity thing.
hi another gotcha for Fed-20 /var/log/messages is no more "cat /var/log/messages" will now become "journalctl". Steve
On 23/12/13 14:00, Steve Roylance wrote:
On 22/12/13 23:29, Allan Duncan wrote:
It's the --iso <full path the dvd.iso> that is breaking. It finds the iso file but doesn't like what it finds. Writing said file to a stick, mounting it, and using --device <dev> works fine. It was 1.4 G of download, but my yum.conf has entries for the internode mirror so all it costs is time. Therefore to some extent this is a curiousity thing.
hi
another gotcha for Fed-20 /var/log/messages is no more
"cat /var/log/messages" will now become "journalctl".
That may be for a new install only, my upgrade still uses messages.
Steve Roylance <roylance@corplink.com.au> wrote:
another gotcha for Fed-20 /var/log/messages is no more
But you can use journalctl to read the logs. The somewhat interesting Forward Secure Sealing feature was mentioned on LWN a while ago; it's designed to detect some forms of malicious modification to log files.
On 23 Dec 2013, at 2:00 pm, Steve Roylance <roylance@corplink.com.au> wrote:
another gotcha for Fed-20 /var/log/messages is no more
"cat /var/log/messages" will now become "journalctl".
As the release notes say, this is because syslogd is no longer installed by default. It’s easy to install yourself if you need the functionality, but for the majority of people journalctl does the same (or better).
On 23/12/13 17:58, Jeremy Visser wrote:
On 23 Dec 2013, at 2:00 pm, Steve Roylance <roylance@corplink.com.au> wrote:
another gotcha for Fed-20 /var/log/messages is no more
"cat /var/log/messages" will now become "journalctl".
As the release notes say, this is because syslogd is no longer installed by default. It’s easy to install yourself if you need the functionality, but for the majority of people journalctl does the same (or better).
Having been alerted to the existence of journalctl I had a look. Maybe because I have syslog still running the messages are only going to the old places, but the man for journalctl implied they would be scraped anyway, but there was little of what I would want to see held by it. I _like_ to use vi and grep to find traces of whatever I was trying to extract from messages.
On 23 Dec 2013, at 8:48 pm, Allan Duncan <amd2345@fastmail.com.au> wrote:
I _like_ to use vi and grep to find traces of whatever I was trying to extract from messages.
journalctl doesn’t prevent you from doing any of that. What are you having trouble with?
Jeremy Visser <jeremy@visser.name> wrote:
On 23 Dec 2013, at 8:48 pm, Allan Duncan <amd2345@fastmail.com.au> wrote:
I _like_ to use vi and grep to find traces of whatever I was trying to extract from messages.
journalctl doesn’t prevent you from doing any of that. What are you having trouble with?
http://0pointer.de/blog/projects/journalctl.html offers an informative overview.
On 23/12/13 21:15, Jeremy Visser wrote:
On 23 Dec 2013, at 8:48 pm, Allan Duncan <amd2345@fastmail.com.au> wrote:
I _like_ to use vi and grep to find traces of whatever I was trying to extract from messages.
journalctl doesn’t prevent you from doing any of that. What are you having trouble with?
Reading the reference Jason gives, I realise I need to use sudo to get all the logs displayed. All the way back to June. I see a great future for the options "-k -b -0".
On Mon, Dec 23, 2013 at 08:48:45PM +1100, Allan Duncan wrote:
I _like_ to use vi and grep to find traces of whatever I was trying to extract from messages.
newsflash: you are wrong. it doesn't matter what you think you like, or what you think your needs might be - you are just plain wrong. systemd's author knows better than you. welcome to the new Lennartix mono-culture. your distro will be assimilated. craig -- craig sanders <cas@taz.net.au>
On 24/12/13 21:06, Craig Sanders wrote:
On Mon, Dec 23, 2013 at 08:48:45PM +1100, Allan Duncan wrote:
I _like_ to use vi and grep to find traces of whatever I was trying to extract from messages. newsflash: you are wrong.
it doesn't matter what you think you like, or what you think your needs might be - you are just plain wrong. systemd's author knows better than you.
welcome to the new Lennartix mono-culture. your distro will be assimilated.
Can you please refrain from posting crap? (In case it was supposed to be funny, it was pretty lame.) Again, as I said before, journalctl doesn’t prevent you from doing any of that. Your Lennart-bashing is currently based on a strawman. I don’t know about you, but I thought this was pretty straightforward: $ journalctl | vim - $ journalctl | grep SCSI Of course, you can get better niceties by actually taking advantage of some of journalctl’s features (hint: the future looks a lot brighter with your head out of the sand): $ journalctl _EXE=/usr/sbin/sshd $ journalctl _SYSTEMD_UNIT=httpd.service _SYSTEMD_UNIT=mysqld.service Or if you like, combine filtering and grep: $ journalctl _EXE=/usr/sbin/dhclient | grep 'bound to' If you’re still having trouble, maybe you should, dare I say it, RTFM? $ man journalctl
On Tue, Dec 24, 2013 at 10:23:30PM +1100, Jeremy Visser wrote:
On 24/12/13 21:06, Craig Sanders wrote:
On Mon, Dec 23, 2013 at 08:48:45PM +1100, Allan Duncan wrote:
I _like_ to use vi and grep to find traces of whatever I was trying to extract from messages. newsflash: you are wrong.
it doesn't matter what you think you like, or what you think your needs might be - you are just plain wrong. systemd's author knows better than you.
welcome to the new Lennartix mono-culture. your distro will be assimilated.
Can you please refrain from posting crap? (In case it was supposed to be funny, it was pretty lame.)
it's funny only in the sense that all things that suck are funny - in a sad, depressing way.
Again, as I said before, journalctl doesn???t prevent you from doing any of that. Your Lennart-bashing is currently based on a strawman.
you say that as if there's some reason, any reason, why i should give a shit what you say. i don't really give a fuck what you've said before or what you believe - who the fuck are you that your opinion is greater than anyone else's? and who the fuck are you that your opinion has any value to anyone other than yourself?
I don???t know about you, but I thought this was pretty straightforward:
and there you go proving my point: he's wrong because lennartix provides a rough analog of what he wants to do, and he only needs to be re-educated to truly believe in the One True Way for him to be happy. to lennartix groupies, whatever existing (i.e. old-fashioned and therefore stupid) method or preference someone has for doing something is wrong and obsolete and completely irrelevant because lennartix provides some half-arsed emulation that can kind of be forced to do something vaguely similar to what they actually wanted to do. hooray! problem solved! and they were a moron for wanting to do it any other way, right? THAT is the attitude of systemd developers and pushers that pisses people off. it really doesn't matter if lennartix provides some way of doing something - that's not the issue. the problem is that in lennartix, poettering's way is the ONLY way and pottering's monolithic monstrosity is absorbing every system function and destroying the concept of modularity and replacability in the process. while some of the things about systemd may work quite nicely and/or are useful or interesting concepts, the mono-culture that will result from poettering's implementation and the inevitable death of innovation which that mono-culture brings is not worth it. especially when all of the relatively minor benefits that systemd brings can be achieved without creating a monolithic system or a mono-culture. systemd just isn't anywhere near good enough to justify the price. nothing could ever be good enough to be worth that price. and it's certainly not worth the replacement of well-documented behaviour between sub-systems with whatever the undocmented whim of the week is for pottering's latest absorption target. partial C library documentation and NO communications protocol documentation is not enough. and "read (this week's) source (for a dozen or so different excessively integrated subsystems) if you want to try to figure out how it works (and hope it doesn't change too much before you're finished)" is nowhere near good enough either. and no, a dozen or so self-praising blog posts extolling the beauty of the Grand and Glorious Vision doesn't cut it either. you may think lennartix's magic black box is good enough for your systems. good for you. you are entitled to your opinion. but don't go ramming it down everyone's throat, or telling me, or anyone else, to shut up if we disagree, as if yours is the only valid opinion on the subject. you can take your One True Way and shove it. True Believers (in anything) are always a menace. and getting all caught up in the branding and marketing hype of redhat's commercial war with Canonical is just plain stupid. it's no accident that RH are pushing gnome and systemd while canonical are pushing upstart and unity - they're takeover bids for the future of linux, the modern day equivalent of the old proprietary unix wars, and it would truly suck if either side actually won. corporations already effectively control linux, a fact that's pragmatically tolerable because the (usually) co-operative competition results in useful improvements. either side - any side - winning would be a disaster. craig -- craig sanders <cas@taz.net.au>
On 2013-12-25 01:52, Craig Sanders wrote:
On Tue, Dec 24, 2013 at 10:23:30PM +1100, Jeremy Visser wrote: [...]
Again, as I said before, journalctl doesn???t prevent you from doing any of that. Your Lennart-bashing is currently based on a strawman.
you say that as if there's some reason, any reason, why i should give a shit what you say.
i don't really give a fuck what you've said before or what you believe - who the fuck are you that your opinion is greater than anyone else's? and who the fuck are you that your opinion has any value to anyone other than yourself? [...]
Craig, I loathe the idea of systemd as much as the next guy, and basically agree with everything you said in your previous email, but I think you went somewhat over the top on the language above. I also think that with all the (valid) attacks you made on systemd, it wasn't necessary to be so harsh on Jeremy specifically. Incidentally, who wants to go to Lennart's LCA talk about kdebus (*shudder*) and throw fruit? I thought about it and then noticed there was a Raspberry Pi talk on at the same time that I cound ammuse myself with. -- Regards, Matthew Cengia
Matthew Cengia <mattcen@gmail.com> wrote:
I loathe the idea of systemd as much as the next guy, and basically agree with everything you said in your previous email,
I don't loathe the idea of systemd; in fact I think it's an interesting and useful piece of work, which is why it's seeing adoption from multiple distributions (Arch, Fedora, OpenSUSE, possibly others). There have always been different init systems (System V, BSD, etc.) in use, and there's nothing to suggest the situation is about to change, hence I don't agree with the "monoculture" claims. It's true that the developers of systemd are keen to promote their work, but that's nothing new in software generally or free/open-source software specifically. Furthermore, I'm not suggesting to anyone that they should (or shouldn't) use systemd; that's an issue to consider, among others, in choosing a distribution.
On Wed, 25 Dec 2013 09:44:39 AM Jason White wrote:
I don't loathe the idea of systemd; in fact I think it's an interesting and useful piece of work, which is why it's seeing adoption from multiple distributions (Arch, Fedora, OpenSUSE, possibly others).
The downside that I see is that any application that wants to support cgroups is now going to have to support at least 3 different APIs. 1) the current filesystem one (which will be superseded) 2) the systemd interface 3) the cgmanager one, which will be different because systemd won't support LXC containers and the systemd developers will not work with other groups on a generic interface. http://lwn.net/Articles/575672/ Much joy for those of us in the HPC world who use control groups a lot. Merry Newtonmas all! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP
On Wed, Dec 25, 2013 at 09:59:49AM +1100, Chris Samuel wrote:
The downside that I see is that any application that wants to support cgroups is now going to have to support at least 3 different APIs.
1) the current filesystem one (which will be superseded) 2) the systemd interface 3) the cgmanager one, which will be different because systemd won't support LXC containers and the systemd developers will not work with other groups on a generic interface.
that's one of the biggest problems with systemd developers - they won't work with anyone on anything. it's their way or FOAD. they won't accept patches, they won't co-operate, and there is absolutely no desire to make any accomodations for any alternatives. they are not interested in co-operating in any way with anyone else on anything. cgroups are one of the many areas that should be a well-documented open standard, with multiple competing implementations of the standard. not something where one corporation uses their market dominance to jerk around competing implementations with the attitude "play never-ending catch up, losers! compatibility is your problem, not ours". documentation is required for an open standard, not "monitor our github account and hope you don't miss anything important". the fact that they have repeatedly demonstrated their unwillingness to co-operate - indeed, their contempt for the idea - is why i view systemd as a hostile takeover attempt. it's not just LP's ego or his abrasive personal style, RH are paying him and others to do this work, if they wanted to they could tell him to pull his head in and play nice with others. they don't. and they don't do it for gnome, either, which is another RH-dominated project and has the same "ours is the one true way" attitude and refusal to co-operate. craig ps: they're also militantly linux-kernel-only, explicitly excluding (to the point of refusing patches for and refusing to even discuss the possibility) the *BSDs and open solaris. whether you use these other unix-like systems or not, the healthy competition between them and linux benefits everyone. -- craig sanders <cas@taz.net.au>
On Wed, Dec 25, 2013 at 09:44:39AM +1100, Jason White wrote:
Matthew Cengia <mattcen@gmail.com> wrote:
I loathe the idea of systemd as much as the next guy, and basically agree with everything you said in your previous email,
I don't loathe the idea of systemd; in fact I think it's an interesting and useful piece of work, which is why it's seeing adoption from multiple distributions (Arch, Fedora, OpenSUSE, possibly others).
There have always been different init systems (System V, BSD, etc.) in use, and there's nothing to suggest the situation is about to change, hence I don't agree with the "monoculture" claims.
if it was *just* an init system, then it wouldn't be a monolithic monstrosity resulting in a mono-culture. but it's also absorbing syslogging, cron, udev, console and login handling, automount, and everything else in sight. an init system doesn't need to do all those things. it just needs to handle starting up daemons/services in the right order at boot time, and killing them later on shutdown or reboot. at the moment, each one of those system functions is provided by a separate, independent program - and each one can be replaced with an alternative or competing implementation *WITHOUT* fucking up the rest of the system. and we have *all* benefitted from that modularity over the years. I want to keep benefitting from that in the future. with systemd, that will no longer be possible. it's all or nothing. systemd's monolithic nature is antithetical to the unix "small tools" philosophy of "do one thing only but do it extremely well" that has served us all so well for decades. systemd absorbs everything and does a just barely good enough job for each of them before moving on to absorb something else (i.e. jack-of-all-trades, master-of-none) and the end result isn't anything like unix. it's not unix and it isn't linux any more, which is why i've taken to calling it lennartix.
It's true that the developers of systemd are keen to promote their work, but that's nothing new in software generally or free/open-source software specifically.
promotion is one thing. absorbing every low-level system service whether it's related to init or not is quite another. building unneccessary interdepencies that require end-users to switch to systemd is not mere "promotion", it's RH's version of the microsoft embrace and extend tactic, but in this case it's absorb and monopolise. having multiple corporations contribute to and co-operate and compete in linux development is a good thing. having one corporation end up controlling the low-level userland AND the desktop environments of all, or nearly-all, distros would be an absolute, unmitigated disaster.
Furthermore, I'm not suggesting to anyone that they should (or shouldn't) use systemd; that's an issue to consider, among others, in choosing a distribution.
it's more than just in choosing a distro - there are growing interdependencies between systemd and gnome (and, unfortunately, other desktop/window managers - even xfce). it's not quite there yet, but the future is clear: if you want to run gnome or most other desktops, you will have no choice but to run systemd (or, if you're lucky, put up with running your desktop environment in a second-rate "unsupported" systemd-less "degraded mode") when you *can't* choose to run something else - whether it's a syslogd or a crond or your desktop - because of these interdependencies, *THAT* is when you get a complete mono-culture. craig -- craig sanders <cas@taz.net.au>
Craig Sanders <cas@taz.net.au> writes:
if it was *just* an init system, then it wouldn't be a monolithic monstrosity resulting in a mono-culture. but it's also absorbing syslogging, cron, udev, console and login handling, automount, and everything else in sight.
I noticed yesterday that readahead-fedora (the only readahead currently in Debian) has been abandoned upstream because its functionality is now absorbed into pid 1.
an init system doesn't need to do all those things. it just needs to handle starting up daemons/services in the right order at boot time, and killing them later on shutdown or reboot.
Preferably one that's as simple as possible, because when (not if) it goes tits-up, you won't have enough of a system up to fix it remotely. (Modulo a BNC, which is an entire bag of different pain.) For me, systemd (and pulseaudio and avahi) boil down to: Lennart (claims to) solve problems I don't have. I could ignore avahi and pa, because I Don't Do Desktops. I can't ignore systemd because it's likely to end up on servers. And I know from past experience with cinit/minit that dropping in a distro-unsupported init is... nontrivial.
On Wed, Dec 25, 2013 at 09:05:09AM +1100, Matthew Cengia wrote:
I loathe the idea of systemd as much as the next guy, and basically agree with everything you said in your previous email, but I think you went somewhat over the top on the language above. I also think that with all the (valid) attacks you made on systemd, it wasn't necessary to be so harsh on Jeremy specifically.
i objected to being told to shut up and go away. jeremy's attitude that only positive opinions about systemd were valid and deserving to be expressed really pissed me off. craig -- craig sanders <cas@taz.net.au>
On 25 Dec 2013, at 11:22 am, Craig Sanders <cas@taz.net.au> wrote:
jeremy's attitude that only positive opinions about systemd were valid and deserving to be expressed really pissed me off.
I never said that. The following is the contents of my post, once again. Can you please point to the specific paragraph/sentence that caused you to think that I said that:
Can you please refrain from posting crap? (In case it was supposed to be funny, it was pretty lame.)
Again, as I said before, journalctl doesn’t prevent you from doing any of that. Your Lennart-bashing is currently based on a strawman.
I don’t know about you, but I thought this was pretty straightforward:
$ journalctl | vim - $ journalctl | grep SCSI
Of course, you can get better niceties by actually taking advantage of some of journalctl’s features (hint: the future looks a lot brighter with your head out of the sand):
$ journalctl _EXE=/usr/sbin/sshd $ journalctl _SYSTEMD_UNIT=httpd.service _SYSTEMD_UNIT=mysqld.service
Or if you like, combine filtering and grep:
$ journalctl _EXE=/usr/sbin/dhclient | grep 'bound to'
If you’re still having trouble, maybe you should, dare I say it, RTFM?
$ man journalctl
On 24/12/13 21:06, Craig Sanders wrote:
On Mon, Dec 23, 2013 at 08:48:45PM +1100, Allan Duncan wrote:
I _like_ to use vi and grep to find traces of whatever I was trying to extract from messages.
newsflash: you are wrong.
it doesn't matter what you think you like, or what you think your needs might be - you are just plain wrong. systemd's author knows better than you.
welcome to the new Lennartix mono-culture. your distro will be assimilated.
craig
Ah, trust Craig to stir the possum. But I agree in part, I get a system into a form that suits my way of doing things, and then the underlying distro changes some fundamentals and breaks it. Gnome being a case in point. So eventually I end up with XFCE and the sawfish wm to get back to where I was. I don't mind systemd and I am slowly finding my way about it - it is a pain to change but I can see there may be ultimately a cleaner control structure, although sometimes the error message can be unhelpful - when I upgraded to F20 an automount of a remote volume started failing with the message that it "failed". I eventually worked out that the network connection was now slower in coming up to the extent that the mount came before the network was there. I ended up putting it in rc.local after a "sleep 5". The Old Way still lives.
I did a network upgrade from Fedora 18 to 20 the other day and it went fine. I ran this to get the Fedora 20 GPG key: su -c 'yum --enablerepo=updates-testing update --advisory=FEDORA-2013-23598' (from https://fedoraproject.org/wiki/Common_F20_bugs#Upgrade_from_Fedora_18_with_f...) Then followed the instructions: https://fedoraproject.org/wiki/FedUp Cheers, Bianca
On 27/12/13 20:25, Bianca Gibson wrote:
I did a network upgrade from Fedora 18 to 20 the other day and it went fine. I ran this to get the Fedora 20 GPG key:
su -c 'yum --enablerepo=updates-testing update --advisory=FEDORA-2013-23598'
(fromhttps://fedoraproject.org/wiki/Common_F20_bugs#Upgrade_from_Fedora_18_with_f...)
Then followed the instructions: https://fedoraproject.org/wiki/FedUp
Oh, I've run the update from a stick OK, it was just trying to do it from the iso image that the stick was written from that I had trouble with and was following up on. Btw you could probably set gpgcheck=0 in yum.conf and run with that, although fedup 0.8 deals with other issues as well, which is what I did first.
On Sat, 21 Dec 2013 08:13:39 PM Allan Duncan wrote:
I have an iso image of the Fedora 20 install DVD, but when I try to use it I get this:
The only thing I can find is a note to make sure you have fedup v0.8: https://fedoraproject.org/wiki/Common_F20_bugs#fedup-07-fail But other than that I've no clue, sorry! -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP
On 21/12/13 22:23, Chris Samuel wrote:
On Sat, 21 Dec 2013 08:13:39 PM Allan Duncan wrote:
I have an iso image of the Fedora 20 install DVD, but when I try to use it I get this:
The only thing I can find is a note to make sure you have fedup v0.8:
https://fedoraproject.org/wiki/Common_F20_bugs#fedup-07-fail
But other than that I've no clue, sorry!
Yeah, got that before I started. Looks like a visit to bugzilla.
participants (10)
-
Allan Duncan -
Bianca Gibson -
Chris Samuel -
Craig Sanders -
Hiddensoul (Mark Clohesy) -
Jason White -
Jeremy Visser -
Matthew Cengia -
Steve Roylance -
trentbuck＠gmail.com