Upgrading and Installing Fedora 18 in VMware Fusion

I was thoroughly excited about Fedora 18 until I actually went to install it. I use Fedora 17 on a laptop and a desktop, but I also have copies in virtual machines that I use for testing — these virtual machines run in VMware Fusion on my Mac Pro. So never having used Fedora 18 during any of the betas or anything, first thing I did was try to install it in VMware.

A few times.

First I have to say that I’m not a big fan of the new Anaconda UI. One of the things I appreciated about Anaconda in the past is that it was easy to use, but didn’t prevent me from doing “power things”, like partitioning disks the way I wanted to partition them. This seems to no longer be the case, and Anaconda does a lot of hand-holding. It has been a habit to go through the list of packages to be installed (select a group, then go through and weed out the stuff I don’t want), so things I don’t want don’t even touch the disk. Doesn’t seem like I can do this anymore either. I don’t agree with some reviewers who seem to think the UI change is to make it look/feel more mobile or “touchscreen-like”, but I do feel it’s dumbed down quite a bit which makes me unhappy. I lived with it, until trying to change the partition layout killed Anaconda. Twice. After that I decided to let it do what it wanted since it was just a VM and I didn’t care enough to fight it.

So Fedora gets installed and lo! A nice blue screen where I can do absolutely nothing. No icons, no text, no login box, nothing. Afterwards I read this has to do with having 3D graphics enabled in VMware (but at that point I had already reinstalled to use LXDE rather than GNOME, so I’ve not tried anything regarding that, however I did find this blog posting about Fedora 18 in VMware Fusion 5/VMware Workstation 9 which explains things a bit).

On my home network I run IPA on Red Hat Enterprise Linux 6 to handle my Kerberos/LDAP auth duties. This means when I install an operating system, no matter what it is, I don’t create local users. So when I installed Fedora 18, I only have the root user and the rest come from IPA. A few problems with that:

  • Setting up IPA in Anaconda does not work
  • Post-install, logging in as root at the GUI is not permitted
  • I have a grub error on tty2, not a login (and nothing on tty3 for that matter)
  • I have to reboot and edit grub to add systemd.unit=multi-user.target to boot into the console to get a tty (see Systemd: Boot Kernel Command Line)
  • After I install freeipa-client, I can enroll in the domain
  • SSSD is not enabled when you install it! Once again I have to reboot to the console
  • Enable SSSD and reboot, only to find that once again I cannot login as a user in the GUI (that I could login as on the console)
  • Head-scratching moment when I realize I know next to nothing about systemd and can only conclude that perhaps NetworkManager starts upon login in the graphical boot and not at system start, which prevents SSSD from talking to IPA to confirm my login
  • Looking at /etc/sysconfig/network-scripts/ifup-eth0 tells me that perhaps that is not the case
  • Big WTF moment and go to bed

Currently I am unhappy with Fedora 18. I suppose that on bare metal it probably works better. I also suppose that with a real user account it works better. At this point I don’t want to do yet another reinstall because then I have to remove the host from IPA and re-enroll, which is annoying (and I really don’t want to revisit Anaconda either — I’ll get to do that when I create the 64bit Fedora 18 VM later).

Ok, after a few days I tried a few other things. The first was getting rid of NetworkManager thinking that perhaps it would only start when I login (which I can’t, if there is no network, because my login is IPA-based). So I had to do:

# systemctl disable NetworkManager.service
# systemctl enable network.service

The most annoying thing, however, is that when I boot into graphical mode, I get no gettys. I’m pretty sure I told systemd that I want three of them (I have three symlinks in /etc/systemd/system/getty.target.wants: getty@tty1.service through getty@tty3.service; sadly when I boot into graphical mode and switch to TTY2, I get a grub error message and nothing on TTY3… what the heck?)

Another thing I did was disable SELinux. In multi-user.target, I can login as my IPA-user no problem. With LXDM, however, I never could (assuming, perhaps incorrectly, that network initialization was delayed). But upon further inspection I see a lot of:

lxdm-binary: pam_selinux(lxdm:session): Setting key creation contect guest_u:guest_r:oddjob_mkhomedir_t:s0 failed: Permission denied

I have zero interest and zero time in making SELinux work with LXDM and since this is a virtual machine, I don’t care if SELinux is disabled.

Lo and behold, I can now log into LXDM. In light of the SELinux thing, I’m thinking that NetworkManager is not to blame (silly me, I made two changes then rebooted — it could be either one, but I strongly suspect SELinux). Maybe it would have worked better with GNOME (will try that on the next VM I install).

On another side note, since I use VMWare Fusion for the VM, for the tools install (probably the same for the latest VMware Workstation as well, etc.), you may want to check out this thread. In particular, seems like linux/version.h is missing and makes the tools angry. The fix is easy though:

# cd /usr/src/kernels/[current_version]/include
# cp generated/uapi/linux/version.h linux/

Then you can compile the tools. IIRC, you’ll also not want to use the i686 PAE kernel (doesn’t seem to work on older versions, I suspect the same may be true with F18). Easy enough to yum remove the PAE kernels and install the regular kernel. YMMV.

Finally, the next day I installed Fedora 18 64-bit in VMWare Fusion. With the lessons learned above, it was a lot less painful. I still am not a big fan of Anaconda… I like the look of it, but the practical “working” bits of it definitely need some work. I don’t like that you can pick only one group of packages. What if I want both GNOME desktop and a working web server? Doesn’t seem like it can be done. I also like picking through individual packages and sorely miss that — makes for having to install a bunch of stuff later. Also not sure why vim isn’t installed by default… I think this is the first time ever I’ve seen “vim: command not found”.

Also, despite getting the VMware tools installed, if you want GDM to present you with anything, you need to disable 3D graphics. I have it enabled on my 32-bit VM (which is using LXDM, works fine), but on the 64-bit VM (using GDM), even with vmware-tools compiled and running, I needed to disable 3D graphic acceleration. I suppose there is a bug in the driver and/or X there. Not a big deal to disable since I’ve done “yum groupinstall ‘MATE Desktop’” (what need do I have for 3D graphics? BTW, MATE is sweet!) and now GDM loads.

IPA still would not work to configure from Anaconda. Definitely a bug to be filed there.

Anyways, time to end this. This entry has been in the works for about two weeks (sadly, I’ve not had time to finish it or get my Fedora VM’s running until yesterday, and finished up the 64-bit install this morning). So far the install of Fedora 18, in VMware, has been a bit of a PITA. Next order of business is to see how the upgrade works… I’ve got a Fedora 17 install in Parallels to upgrade to make sure all my work-related bits work, before attempting to upgrade on bare metal. I’m quite certain that a lot of this can be attributed to the virtual machines and it’ll work better on bare metal. I’m also happy that those won’t be fresh installs, so I don’t have to deal with Anaconda.

12 Comments

  1. Adam Williamson

    Sigh…I can understand random bloggers just poking things and assuming they know what’s going on, but I’d figure you at least would know to read the documentation :|

    “This seems to no longer be the case, and Anaconda does a lot of hand-holding.”

    No, that’s not really true. You can do nearly everything in newUI custom part that you could do in oldUI custom part, and the few things that don’t quite work yet (I think mainly some specific LVM-on-RAID setups) are just ‘not done yet’, they’re not removed. It works *differently* from oldUI, but it is no less flexible or capable. It is not really holding your hand, it’s just using a different interface design – for very good reasons, if you read up on it, ask the designer, or just think about it for a bit.

    Additionally, newUI has capabilities oldUI never had; it is already more capable when it comes to btrfs, for instance. For the few releases oldUI was able to handle btrfs interactively at all, it simply treated it like it was a simple partition format like ext4, which it isn’t. It’ll be much better in f19, but f18 is already better than f17 was.

    Remember, you work for RH…people who read your blog are gonna assume you know what you’re talking about when you write about a Fedora release, not that you’re just poking around and guessing.

    “It has been a habit to go through the list of packages to be installed (select a group, then go through and weed out the stuff I don’t want), so things I don’t want don’t even touch the disk. Doesn’t seem like I can do this anymore either.”

    Yeah, you can’t: ask Bill and Mo about it, but basically, maintaining an entire package manager in the installer is a bunch of maintenance effort that’s unnecessary in the vast majority of cases, and mostly offers people a chance to shoot themselves in the foot by picking the wrong things. The installer is a deployment tool, really, not a package manager. It rather sounds to me, though, like you really ought to be using a kickstart install: you’re doing a pretty non-standard deployment, and a lot of things about it would probably go smoother if you used a kickstart. You could customize your package set and use the %post section to set up your whole freeipa/sssd auth stuff.

    “SSSD is not enabled when you install it! Once again I have to reboot to the console”

    This is a Fedora policy – again, I’d kinda expect you to be familiar with this: https://fedoraproject.org/wiki/Starting_services_by_default .

    “Setting up IPA in Anaconda does not work”

    That’s…pretty vague…care to expand a bit?

    “Post-install, logging in as root at the GUI is not permitted”

    Nothing new to F18, it hasn’t been for years in GDM. It’s an intentional design and a good one, there’s no good reason for anyone to log in as root graphically. tty2 and tty3 being broken is a bug, though. It’s not normal: I haven’t seen that on any F18 test installs, it’s something we explicitly test. In all my F18 tests, ttys 2 through 6 have always been present as normal.

    You are wrong about NetworkManager, it brings up wired connections at boot, it does not happen after login. Wireless connections that you configure from a desktop as a user wind up configured as per-user connections by default, but you can change that and make them system-wide if you like; but normal wired connections don’t behave like that.

    It sounds like your problem was just between LXDM and sssd and selinux-policy. Obviously a bug, but I think it’s fair to say not a huge one – you’re using a reasonably unusual auth system with a non-core desktop. If you file the selinux alerts, I’m sure Dan or Miroslav will fix it pretty quick.

    The default install choices are not part of anaconda. They’re part of comps. So, whether vim is installed by default or not is nothing to do with anaconda. Complain to Bill (Nottingham) if you’re not happy. I think someone else wrote that ‘vi’ is installed by default, just not ‘vim’. Seems reasonable. There’s lots of us who wouldn’t touch vi with a 30-foot pole, believe it or not.

    I dunno, you seem to like making your config hard for yourself. :) Why not use KVMs for Fedora installs? KVM’s a whole lot nicer for Fedora than VMware, in most ways. No problems with GDM or Shell there. We test it.

    Feb 02, 2013 @ 15:39:11
  2. vdanen

    Well, I suppose you can sigh all you want, but to clarify: just because I work for Red Hat is supposed to mean I magically know all the in’s and out’s of a new Fedora release? For the audience reading.. there’s a whole lot more to Red Hat than Fedora and (fortunately or otherwise), I have no time for Fedora because I’m far too busy with dealing with other things… you know: Red Hat Enterprise Linux, a bunch of JBoss things, all the cloud stuff (OpenShift, OpenStack, CloudForms, etc.) and just a whole lot of things that have pretty much nothing to do with Fedora. Asserting that “Remember, you work for RH…people who read your blog are gonna assume you know what you’re talking about when you write about a Fedora release, not that you’re just poking around and guessing.” is a little bit of insult? Kinda like if I ranted about my experience with some piece of JBoss middleware that I’d never used before really shouldn’t have people up in arms about the fact that I work for Red Hat and have no idea how JBoss works.

    Just saying.

    As for the rest… documentation? Why on God’s green earth would I take the time to read docs when I barely have time to do the install itself anyways? Ok, I suppose I can’t blame anyone else but myself for that, but… well, I just did a FedUp in Parallels and I read the docs and they’re not fully there. I mean, there’s a bunch of “TODO” stuff in there. At any rate, perhaps I’m an oddity, but I turn to docs when I can’t figure something out. Kinda like I did when I was having issues with systemd. And then, lo and behold, I wrote some of my own to share that with others.

    And, whatever the reasons for Anaconda’s change, and despite the fact that I work for Red Hat (and not on Fedora), I’m still allowed to have an opinion I hope? Still not a huge fan. I liked the old way it worked because it suited me well. Since I’ve never used btrfs, and didn’t this time around, the changes to btrfs really don’t matter to me. They might in the future, but right now they don’t. I _am_ still allowed to use ext4, right? Oh, and perhaps a non-LVM setup? Or, as you said, LVM on RAID? Or just straight RAID? Forcing me into a particular LVM setup (and crashing when I decide I want to do something different), isn’t overly friendly. I suppose it will get better in time, but I’m writing about Fedora 18 here, not Fedora 18+N.

    Using kickstart is a good idea. I’ve never tried it on Fedora before, just RHEL. I’m going to have to give that a try.

    I am familiar with the Fedora policy on not auto-starting installed daemons and, in generally, I absolutely 100% agree with it. SSSD is a little bit different though. If install freeipa-client, and then you run the freeipa-client-install utility (which sets up SSSD, along with LDAP and Kerberos, etc.) one would assume that, since SSSD is pretty much a requirement to make any of that stuff work, that it would be set to start. I mean, all the cool auto-setup stuff the client installer does is pretty much useless when it doesn’t make a very important authentication subsystem start on boot. It’s kinda like asking if you want to allow remote logins, configures a tweaked sshd_config for you, tells you that you can now login remotely, and then doesn’t bother starting sshd for you. Somewhat defeats the purpose of the fancy config tool. (Don’t worry, I’ve not filed a bug but I’ve brought it up with the IPA developers directly, so they are aware of it).

    For IPA not working in Anaconda… well, it asks for your domain administrator password and username and then sits and thinks for a bit and then fails. But when I’m done the install and run “ipa-client-install” on the commandline, providing the same credentials, it works. Not really sure how else to explain it. It… doesn’t work. =) I’ve mentioned that to the IPA developers as well.

    No, I wouldn’t expect logging in as root to work if I could login at TTY2 as root. But since TTY2 has a GRUB error and there is nothing on the other TTY’s, I figured there had to be a way to get into the box as root…. and since no gettys are running… Having to reboot into multi-user.target to be able to look at a bloody logfile is highly annoying. And, FWIW, this happens on both the 32bit and 64bit VMs (so went through the process twice). No console login when you boot into graphical.target. And any attempt on my part to do so didn’t work (reading the Fedora and ArchLinux wiki entries on systemd and trying to follow the “adding more gettys” part).

    Yes, I was wrong about NetworkManager, which the second install showed me. I should have clarified that part when I was wrapping it up. I do recall having issues in the past with NM starting only after you login, but I think that may have been due to wireless networks or something. Can’t fully remember, just recalled the issue which is why I turned it off and used the old network service instead.

    The problem was pretty much definitely between LXDM/SSSD/SELinux although I think it’s probably a question of LXDM policies. On the other system, GDM/SSSD/SELinux work fine. If I get some time tomorrow, I’ll re-enable SELinux there and file some bugs.

    Finally, making it hard for myself? The host I’ve got these on isn’t a Fedora box, so unless someone ported KVM to OS X, I suppose you missed the “running on VMWare Fusion” bit (Fusion is an OS X product from VMware). I’ve got KVM running on my Red Hat Enterprise Linux 6 box, but since that’s for production VMs (and not scratch/test VMs), I can’t stick these images there. The VMware side of things isn’t too awful though. The tools compile, and the only real problem was the 3D graphics acceleration, so other than that (easy to solve), all the problems fall squarely on Fedora… I doubt KVM would have helped in that regard at all.

    Finally, I just upgraded a Fedora 17 Parallels VM to Fedora 18 using FedUp and that seemed to work quite nicely. So now that I’ve had some chances to play and figured out the quirks, I can start doing some upgrades on real hardware (which I assume will work a little nicer than the virtualized stuff).

    Anyways, thanks for the comments. Except for the vi comment. =)

    Feb 02, 2013 @ 17:29:39
  3. vdanen

    Ok, I should clarify the “no time for Fedora”. That was more “no time to follow Fedora”. I do use Fedora daily on a few systems, so I certainly have time for it. Just not time to read about the new shiny things, etc. For instance, I knew there was a new Anaconda, I just no idea how different it was. =)

    I’ll have to go find some docs on it at some point to see if there is an “expert mode” that can be enabled or something.

    Feb 02, 2013 @ 17:31:31
  4. Adam Williamson

    “Kinda like if I ranted about my experience with some piece of JBoss middleware that I’d never used before really shouldn’t have people up in arms about the fact that I work for Red Hat and have no idea how JBoss works.”

    That’s not really what I meant, no. I meant two things:

    1: this blog is public and syndicated, and written by an RH employee: news sites read such blogs and re-post stuff from them quite frequently. It would kind of suck if this post wound up as a post on Phoronix entitled ‘Even Red Hat Hates The New Fedora’, or something, right? This is the kind of crap that happens.

    2: you’re kind of pissing on a huge amount of hard work by your co-workers without even bothering to try very hard to figure out if what you’re saying is true or not, which seems like a crappy move. I mean, if your team instituted some kind of new security policy which somehow affected Fedora, and it caused me some kind of inconvenience, and I then went out and wrote a blog post saying how bad it was – with some inaccurate details – without even bothering to come and ask you whether I was actually right in my assumptions or not, or why the policy was necessary, wouldn’t that kind of annoy you? Imagine you’re one of the RH staff on the anaconda team, you finish nine months of backbreaking work on the new anaconda, then you come here and see a co-worker saying what a crap job it was, without even having bothered to read any of the docs or ask you if what he was saying was totally accurate – would that make you feel great? Probably not.

    “As for the rest… documentation? Why on God’s green earth would I take the time to read docs when I barely have time to do the install itself anyways?”

    Well, look, because it’s a frickin’ operating system installer. Have you looked at the design spec for an OS installer lately? It’s not a game of Pokemon. It’s pretty damn hard to write a completely new installer interface such that everyone who wants to use it can figure out exactly how it works just by playing with it. I’m not even saying you should read the docs going *in*, for Pete’s sake – just, maybe when you get into the installer, and find you’re having trouble doing what you want to do, maybe think ‘hmm, perhaps I should see if someone’s written some helpful instructions that would make this better for me?’ rather than ‘I think I’ll go write a blog post declaring that the new installer can’t do partitioning properly!’ It’s not like this stuff is hidden: the *release announcement* says “While the new installer should work well for most users in most configurations, there are inevitably a few teething problems in the first release of such a major revision: see the introductory guide to the new installer which includes a list of known limitations of the new installer in Fedora 18, and known significant bugs for more information.” (the two things that look like they should be links there, obviously are). The ‘introductory guide to the new installer’ links to the installation guide – https://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/ . Again, people put a lot of working into writing up all this information about the new installer, so it’s kind of sad when even someone who’s supposed to be on the same team decides to go about bashing the installer in public without even bothering to read the instructions on the tin. You say ” At any rate, perhaps I’m an oddity, but I turn to docs when I can’t figure something out.” – my complaint is that you don’t actually seem to have *done* that.

    ” I _am_ still allowed to use ext4, right? Oh, and perhaps a non-LVM setup? Or, as you said, LVM on RAID? Or just straight RAID?”

    Yes, yes, yes and yes. There’s a drop-down box on the Installation Options dialog with LVM, ext4 and btrfs as options. Whichever you pick is the filesystem that will be used by the installer for creating partitions automatically (if you go that route) or will be the default type for new partitions in the custom partitioner (if you go that route). If you go into the custom partitioner you can set up pretty much any layout you like, just like in the old installer. It _works_ differently, but the same capabilities are there.

    “Forcing me into a particular LVM setup (and crashing when I decide I want to do something different), isn’t overly friendly.”

    It doesn’t force you into a particular LVM setup, it defaults to one. There has to _be_ a default – what you get if you clicky clicky the simplest answer to every question. It’s the same as F17 in that regard, precisely the same. Any crash is obviously a bug, and I hope you reported any you hit. But there’s always going to be some crashes somewhere, it’s not practical to expect to catch every single one before release. Heck, you can crash the F17 installer easy enough in some ways. We can’t block on every single crash report. Still, file it, and it should get fixed.

    “For IPA not working in Anaconda… well, it asks for your domain administrator password and username and then sits and thinks for a bit and then fails.”

    Maybe I didn’t ask that question very well: are you sure we’re talking about anaconda here? Cos I can’t find IPA configuration anywhere. Are you maybe talking about firstboot’s ‘advanced user creation’ thing? Cos you’re way past anaconda at that point; the ‘advanced user’ thing from firstboot is actually just system-config-users. If that’s not working, it’s a bug in s-c-u. We don’t test IPA/SSSD auth as a release validation test, so it’s plausible it’s just broken OOTB; we could add it, but we only have so many testing resources, unfortunately…

    “No, I wouldn’t expect logging in as root to work if I could login at TTY2 as root. But since TTY2 has a GRUB error and there is nothing on the other TTY’s, I figured there had to be a way to get into the box as root…. and since no gettys are running…”

    Well, like I said, that’s clearly a bug. But it’s something to do with your installation config or the VMware platform or something, because it’s not a general bug. If that was happening to all F18 installs we’d have blocked the release. No idea what’s going on there, but it’s definitely a bug, and related to your particular config in _some_ way or other. You might try starting the getty@ttyX services manually and see if you get any errors? Check the output of ‘systemctl status getty@ttyX.service‘?

    “I suppose you missed the “running on VMWare Fusion” bit (Fusion is an OS X product from VMware)”

    I didn’t know Fusion is OS X-specific, nope.

    “the only real problem was the 3D graphics acceleration, so other than that (easy to solve), all the problems fall squarely on Fedora… I doubt KVM would have helped in that regard at all.”

    well it would help the 3D acceleration problem by virtue of the fact that it doesn’t *have* any. :) So you just wind up with software-rendered GNOME Shell, no failure. It’s slightly sluggish, but works well enough. And it is certainly possible that Fusion is _somehow_ to do with the tty problem, because I certainly haven’t seen that on any of my systems. More likely something to do with the SSSD/IPA auth stuff though I guess.

    Feb 03, 2013 @ 11:53:46
  5. vdanen

    I’m not going to get into a pissing contest with you over my opinion. =) So I’m going to (try) to be brief:

    1. If Phoronix wrote something, I would hope they actually read it first. I never stated I “hated” the new Fedora. What I said was “I’m not a big fan of the new Anaconda UI”. I said that twice. I didn’t say it sucked. I didn’t say I hated it. I didn’t saw it was a steaming pile of poo, or any variation thereof. What I stated was a _personal_ opinion, and it wasn’t even that bad. I’m not a big fan of beef either, but surely I’ve not insulted the Alberta Beef conglomerate (and any beef-eating person insulted by _my_ dislike for beef (when stated as “I don’t like beef” rather than “beef sucks”, really needs to learn to lighten up). Don’t try to read between the lines so much and attribute things to me that I didn’t say.

    2. I don’t see it as a crappy move. I’m expressing an opinion. I’m quite certain I’m not the only one, Red Hat employeer or otherwise, that doesn’t care for the Anaconda UI changes. And while I suppose that might hurt someone’s feelings, I somewhat doubt it’ll be a surprise. After all, you can’t make a change this drastic without _someone_ not liking it. So I just happen to be part of the percentage that is (as I’ve been saying), “not a huge fan”. And, so we’re clear, what instructions would have made it better? There are instructions about Anaconda crapping out when you try to do a (what used to be) fairly simple partition selection (or do those instructions say it doesn’t work — and if they did, is that supposed to make me feel better)? Are there instructions about the interaction between VMware 3D acceleration and GDM being a useless (albeit pretty) blue screen? Instructions about how to make IPA setups work? Oh, yes, the instructions on SSSD not running after installation and the instructions on no root GUI login. Perhaps the two most minor things I noted. Yeah, reading _that_ documentation would have saved me a lot of grief. I’m not sure what other issues I had noted that the documentation would have covered?

    Just to be fair, I’m looking at the docs now. Chapter 7: Booting the Installer doesn’t tell me how to get into an expert “old-style” mode. Chapter 9.2 is about the GUI. Nothing there about any kind of expert mode, but I do know how to take screenshots now. Good to know. Chapter 9.9 tells me I can select one type of environment at a time. Yup, figured that one out on my own. Still missing the individual package selection bits, but the documentation helpfully points out that I can’t do that during install. (Is the point to this that if it’s documented I’m not allowed to complain?). Again… not finding anything in the docs that would have helped my particular situation. Oh, wait! Section 17.2.1 talks about firstboot authentication configuration (so you’re right there, this is not Anaconda… my bad… one thing I got wrong). Except the docs don’t say anything about IPA, so moderately useless there. Talks about LDAP, but not quite the same thing.

    Ok, so the issues I had.. IPA setup failure: not documented (a bug). No gettys running in graphical.target: not documented (a bug). The SELinux/LXDM interaction is probably not documented (didn’t bother to look, also a bug). So what documentation did you think was going to help? It’s not like I’ve never installed an OS before. If by reading the documentation you mean to be aware of the shortcomings.. well, then you’re absolutely right. But because they are shortcomings, or bugs, I have no right to express my frustration and my experience? That seems a little like anything being syndicated on Planet Fedora and written by a Red Hat employee has to be all pro-koolaid, despite reality. One of the things I like about Fedora is “freedom”. That seems to be the #1 thing about Fedora. I would hope that stands for more than just “free software” but also free to help, free to contribute, free to change, free to use, and free to have an opinion (as well as free to express it).

    As an aside, when I said “forcing me into a particular LVM setup”… that might not have been the _aim_ but it was certainly the result. Also, to be fair, my initial posting made a passing mention of the partitioning issue because I didn’t care that much (it was a VM). What I had initially said (as my full and total critique of the partitioning) was “…until trying to change the partition layout killed Anaconda. Twice. After that I decided to let it do what it wanted since it was just a VM and I didn’t care enough to fight it.”. Not that evil of a comment, I think.

    WRT IPA in Anaconda, you’re right. That is in the firstboot thing. Whatever. That’s really semantics. The point is it’s broken. I suspect it might be because RHEL6 has IPA 2.x and Fedora 18 has 3.x and once RHEL6 gets a newer version of IPA it may work better (or some option may need to be specified for 3.x talking to 2.x). I’m not sure, but I’ve talked with the IPA guys about it so I expect it to be fixed in the future. It may even be fixed now (not sure if the firstboot changes pick up stuff from updates when installing from a DVD ISO or not).

    For the getty thing… seems pretty odd that anything in my setup would interfere with a getty starting. I doubt SSSD has anything to do with it (this is well pre-any-login-attempt), and if running it in VMware has something to do with it, that’s a pretty fantastic bug. But I’ll dig a bit. It’s Sunday and I have time.

    Interesting. On my 64bit VM the gettys are running (although it is well past install, and I didn’t have the same troubles on the 64bit VM as I did the 32bit VM — so at some point they either started working or they always worked in this one (I’ve done so many Fedora upgrades/installs this weekend I can’t honestly remember)). The 32bit VM doesn’t have the gettys running. “systemctl list-units -t target|grep getty” shows it’s loaded and active. Interestingly, on the 64bit VM I have only /etc/systemd/system/getty.target.wants/getty@tty1.service, but I have gettys on tty2 through tty6. On the 32bit VM I added getty@tty2.service and getty@tty3.service and have no gettys. Removing them and then doing “systemctl daemon-reload” and then “systemctl show getty.target” still shows tty1->tty3 in the After= line (but this After= line on the 64bit VM shows services for tty1->tty6).

    Hah! Neat. “systemctl restart getty.target” kicks me out of X and does start the right gettys. “systemctl isolate graphical.target” gets me back into X and… no gettys to be found. Grepping for getty in /var/log/* gives me squat. Interestingly ps shows me give instances of agetty running and “systemctl status getty@tty2.service” tells me it’s active and running. Rebooting (with the extra getty@ttyX.service symlinks removed) has me with no getty and getty.target telling me it’s going to start one on tty1, which is X anyways (and nothing in ps output).

    Now, considering it seems to be working fine on the 64bit VM, but not the 32bit VM, I’ve definitely stumbled on a bug of some sort but since both VM’s are virtually identical in configuration, I’m pretty sure that a) it’s not VMware and b) it’s not IPA/SSSD. Definitely something else. But it’ll take a bit more time to dig into.

    And for Fusion being a mac thing, I suppose you didn’t notice “these virtual machines run in VMware Fusion on my Mac Pro” in the first paragraph. =)

    Feb 03, 2013 @ 13:53:08
  6. Adam Williamson

    “What I had initially said (as my full and total critique of the partitioning) was” – well no, you also said this, and it’s this that mostly got my nose out of joint:

    “One of the things I appreciated about Anaconda in the past is that it was easy to use, but didn’t prevent me from doing “power things”, like partitioning disks the way I wanted to partition them. This seems to no longer be the case, and Anaconda does a lot of hand-holding.”

    That’s just not right. It _does_ let you partition disks the way you want to partition them. If you’d just asked, anyone familiar with it would have told you that. But you just made an assumption that it was ‘hand holding’ and not letting you do what you wanted to do: an assumption which _isn’t actually correct_. You can argue that it’s a flaw in the installer that you couldn’t find the way to do what you wanted to do, sure. I wouldn’t have minded if you’d said that. But that’s not what you said – you leapt from ‘I can’t find the way to do what I want to do’ to an assumption that it must not be _possible_ to do what you want to do. So far as the docs go:

    https://fedoraproject.org/wiki/Anaconda/NewInstaller#What_to_expect_when_using_the_new_installer

    has a rather comprehensive explanation of the storage workflow. It tells you how it works and how to get to the bit of it you want to go to. And:

    https://docs.fedoraproject.org/en-US/Fedora/18/html-single/Installation_Guide/index.html#s1-diskpartitioning-x86

    is the part of the installation guide which explains in quite decent detail how the custom partitioning screen works. You keep looking for some kind of ‘expert mode’, there is not an expert mode. You just don’t seem to have found the custom partitioning screen, or something.

    Feb 03, 2013 @ 14:27:55
  7. Adam Williamson

    As far as package selection goes, sure, that’s something that’s been intentionally simplified in the new design, and if you want to criticize it, go ahead. But it’d be nice to acknowledge the reasoning for the change, which isn’t hard to find or ask for. If you disagree with it, that’s fine, but it’s not just something that’s been done for ‘hand holding’ or whatever.

    Feb 03, 2013 @ 14:30:38
  8. Adam Williamson

    “If Phoronix wrote something, I would hope they actually read it first.”

    You obviously haven’t read much of Phoronix. Or Slashdot, lately. =) Or Sam freaking Varghese. I’m not saying they’d be _right_, I’m just saying it’s the kind of thing that’s happening, quite a lot lately. Alan Cox wrote a rant about F18, then three days later announced he was leaving kernel development for a while, and some bleeding journalistic champion wrote a story entitled “Linux Developer Alan Cox Leaves Intel, Slams Fedora 18″ – so now we have a bunch of people who think F18 is so terrible it drives major kernel developers to quit their jobs. Maybe I’m over sensitive to this stuff because I follow the news a lot, I don’t know, but it really happens.

    Feb 03, 2013 @ 14:39:18
  9. vdanen

    So, to “well no, you also said this, and it’s this that mostly got my nose out of joint”… fair enough. Perhaps saying Anaconda did hand-holding wasn’t entirely correct (but it sure felt like it when I considered the overall reduction of “clickiness” and options). When I have some free-ish time, I’ll have to go through the install process again (possibly reinstalling this wonky getty-less 32bit VM) and try to customize the storage setup. I suspect that, due to said lack of time, I was just impatient and when I didn’t get it quickly, I gave up and moved on (these are VMs for testing security issues so the partition layout doesn’t matter too much… if this was a new bare metal install, I probably would have spent more time on it, but as it stood I just needed to get some F18 VMs up and running for testing flaws and didn’t really have the time to spend farting around with it).

    The reason behind the change of package selection doesn’t really matter to me (so not sure why I need to acknowledge it). I don’t like it. But that’s probably because I’m used to another way. I’m not saying it isn’t better overall or for the majority of users. I’m expressing my opinion that _I_ don’t like it. =) I like to take the time to tweak what I want during install rather than doing it later because I find it easier. I’m also a creature of habit and I’ve been doing that for over 10 years.

    As for Phoronix… I can honestly say I’ve never read an article on there. I had to look it up when you mentioned it. Slashdot is becoming more of a gossip site than anything so I largely scan the headlines and don’t bother reading the majority of it. The deal with Alan Cox was silly. To say that one coincided with the other is pretty lame… but I guess it draws attention which feeds ad revenue. I suppose in light of that, you’re reaction/comments make some sense in that regard.

    Feb 03, 2013 @ 15:01:57
  10. Adam Williamson

    Yeah, I’m probably being a bit over-sensitive for sure. I just dread thinking what I’m going to find in my news feed some days. And yeah, most of the crappy journalism is about driving page views and ad revenue, that’s the name of the game :/

    Feb 04, 2013 @ 00:49:34
  11. vdanen

    Indeed. Need to be like me and not read them. =) But it is sad that journalism tends to suck so hard now.

    Feb 04, 2013 @ 09:26:41
  12. Razvan Vilt

    Try installing Fedora 18 in a VMWare UEFI machine. It worked like a charm in Fedora 16 and 17 but in 18 2-3 seconds after the X server starts it locks the screen. You can’t even install like that.

    Basically, add firmware=”efi64″ to the vmx file and you should be on your way to finding bugs in Fedora 18 in VMWare.

    That plus the missing DRM_VMWGFX_FBCON on EFI means that you get a broken console as soon as the X.org process starts.

    In (U)EFI the logic is the following: use the FB until you get a driver (such as the X.org vmwgfx or Nouveau). After you start the driver (say the Xorg driver), you should never go back to the EFI Framebuffer. For that reason, the kernel should have the framebuffer drivers integrated and not rely on the broken efifb driver.

    It’s broken because you can’t use it anymore after Xorg starts an accelerated driver and because it starts too late to be able to detect the resources. That is, Linux should also find and enable the GraphicsOutput Protocol during the Setup part before switching to protected mode and save the information of the FB somewhere where EFIFB can pick it up, if no other FB driver is available. In most cases GRUB does that, but if it’s not done by GRUB, Linux won’t do it for you and you don’t get EFIFB. The check for VGA on the other hand is done before Linux actually starts, even if VGA can be detected after startup (unlike GOP and UGA in EFI).

    I wonder, how long do we have to wait until all the framebuffer drivers get included in the kernel or the initrd and automatically loaded as needed based on hardware probing? Using vesa or efifb or vga as a framebuffer should be the fallback not the rule. That’s what every other OS out there does and what we should do also. Furthermore, if there are bugs, let’s solve the bugs not avoid using the drivers.

    Feb 04, 2013 @ 13:18:09

Leave a Reply

*