Fedora 19 RC discussion

[nirik]

Gnome/desktop and KDE are targeting 1GB USB, not cd size anymore.

LXDE, MATE-Compiz, XFCE, SoAS are all targeting 700MB Cd.

See: http://fedoraproject.org/wiki/Releases/19/Spins

[matthewjavelet]

I don't know if it's their apache or what that determins the filesize but it always says 1.0GB from /pub/alt/stage for gnome and 878MB for KDE. Oh well. I think the last actual CD-R of fedora I have is from Fedora Core 3 which I think is 3 or 4 CD-R's and Fedora 16. I somehow always manage to ruin my usb drives and every linux os I install onto my usb I get some cool SELINUX 4.02 message that just stays on my screen all day.

---------- Post added at 04:10 PM ---------- Previous post was at 04:05 PM ----------

Gnome/desktop and KDE are targeting 1GB USB, not cd size anymore.

LXDE, MATE-Compiz, XFCE, SoAS are all targeting 700MB Cd.

See: http://fedoraproject.org/wiki/Releases/19/Spins

Oh well, I guess I can put the netinstall iso onto a cd. I think that's what I've been doing anyways.

[AdamW]

This may be off topic, but if someone has a at RedHat dot com email address, does this mean he or she is a RH employee?

Yes, it does.

Just wondering cause if I had RH licensed linux on my boxes, would I be in a RH forum with a RH dot com possible address?

No, we do not give out courtesy redhat.com addresses. (Even employees who leave don't get to keep their @redhat.com; it is strictly current employees only). If you have a FAS account I believe you have an alias of the form fas_username@fedoraproject.org, mails to which will be forwarded to the email address specified in your FAS account. That's about the closest thing.

[AdamW]

I don't know if it's their apache or what that determins the filesize but it always says 1.0GB from /pub/alt/stage for gnome and 878MB for KDE. Oh well. I think the last actual CD-R of fedora I have is from Fedora Core 3 which I think is 3 or 4 CD-R's and Fedora 16. I somehow always manage to ruin my usb drives and every linux os I install onto my usb I get some cool SELINUX 4.02 message that just stays on my screen all day.

The KDE image just doesn't use up its full size target. There's nothing else they want to add to it.

The GNOME image is stuffed right to the brink; its official size limit is 1000000000 bytes (a power-of-ten gigabyte), the x86_64 image is 997195776 bytes, just 2.8MB under.

[GoinEasy9]

Another thing I noticed during the install:
When setting up the Ethernet connection I noticed the name given it was "enp8s0". I also notice that the name was editable, so, I changed it to "eth0". In /etc/sysconfig/network-scripts, I don't have an ifcfg-eth0, but a ifcfg-enp8s0, which includes a line that reads Name="eth0". Ok, so, I just changed the name, which shows up in Network-Manager. Although, the connection in Network-Manager, and, in gkrellm, is listed as p33p1, a label that I've seen before on this machine.

I'm familiar with posts that talk about biosdevname, and, if needed, how to return the naming scheme to eth0, wlan0, etc, but, that's not a problem I need to solve. What I would like explained, somehow, would be how ifcfg-enp8s0 is somehow read as p33p1 by Network-Manager and gkrellm. Shouldn't there be an ifcfg-p33p1 as I had in my earlier installs?

[AdamW]

Yike, I hope this isn't going to cause too much trouble. So, this one of those things that is kind of boneheaded.

We got the 'biosdevname' thing which was supposed to do 'consistent interface naming' a couple of releases back - 17 or something, I forget.

Now for 19 apparently we decided you must be getting bored of those names now, so now systemd is supposed to be handling 'consistent interface naming' - naturally, using a different naming scheme to biosdevname.

For bonus points no-one remembered to take biosdevname out of comps, so default F19 installs have both biosdevname and the new thing installed, and we'll have some fun figuring out what goes on with that...I think at least in some cases you'll get the systemd name during install but the biosdevname name in at least some contexts post-install. Fun, huh? You might want to try 'yum remove biosdevname' to see whether things change with it gone. If you just want to turn all this crap off, I think 'yum remove biosdevname' then 'ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules' should turn it all off and give you back 'eth0'.

The 'name' you set in the installer is indeed not the actual interface name, but NetworkManager's name for the *connection*, which is not the same thing.

EASY RITE?

I think the new system has been special-cased so that for _most_ systems the first interface will be named the same as it was under biosdevname - em1 - but this won't apply to absolutely everything and certainly not to multiple interfaces.

https://fedoraproject.org/wiki/Featu...InterfaceNames is the feature for the new systemd bit.

edit: https://bugzilla.redhat.com/show_bug.cgi?id=965718 may be the thing to follow to at least get it thrashed out exactly how F19 is behaving. There are some gotchas I didn't catch in my above description. Bill seems to have a handle on it, so I'm going to wait for a reply from him.

[GoinEasy9]

Thanks AdamW

I asked for an explanation, and, the bugzilla certainly explained it.

anaconda/systemd put enp8s0 into intramfs, and, that is the reason Ethernet connection is working.
biosdevname created p33p1 which is being read by NetworkManager and gkrellm.

I don't have an /etc/udev/rules.d/80-net-name-slot.rules, and, since everything is working so well, I'll just live with it for now, and keep my eyes on the bugzilla and see what gets decided.


Edit: Or is it anaconda/biosdevname that put p33p1 into intramfs? Whatever, it seems that the only occurrence of "enp8s0" is in the /etc/sysconfig/network-scripts/ folder as ifcfg-enp8s0, whereas p33p1 seems to be the predominate interface name in all network configuration files.

[AdamW]

p33p1 looks like biosdevname syntax to me, enp8s0 looks like systemd.

[GoinEasy9]

That's the way it appeared to me also, AdamW. But, I thought F19 was supposed to have removed biosdevname,so, I was looking into removing biosdevname and using the systemd naming scheme (That's what I get for reading bugzillas and investigating), but, it looks saner to just to leave it the way it is. It's not causing any problems, so, I'll let the anaconda guys work on it for F20. It would be nice to have consistent names across the board though.

[AdamW]

According to the bug report, just removing the biosdevname package likely won't change anything as anaconda writes a specific if name into the ifcfg file...

[DBelton]

Now for 19 apparently we Lennart decided you must be getting bored of those names now, so now systemd is supposed to be handling 'consistent interface naming' - naturally, using a different naming scheme to biosdevname.

Corrected that for ya, Adam

[bob]

Well now! Decided to beat the rush and throw on RC-3 a day ahead of Final. Must say it was a nice install all in all. Purposely did not read the literature ahead of time to make it a "noob-test" and even failed a couple of mandatory selections or steps to see what would happen. All was covered pretty well and I was blocked from total melt-down.

Got to mention that it could be a bit confusing if you're trying to install on a partition of your drive. The drive comes up, you either click on it or select some other option. If you bypass the drive, and you don't have another place in mind, you've got a fail. SO, eventually you do click on the drive and go forward.

Once on the NEXT screen, then you've got the advanced options, to select your partitions for installation, but it would have been nice to know that was coming up instead of fearing that you'd take up the whole drive with F19.

Aside from that, it's beautifully done, IMHO. Nice job, guys!

[GoinEasy9]

Here's something interesting about F19. I added Debian 7.1 to my collection of distros on the UEFI box. Unfortunately, it formatted the swap partition and gave it a new UUID, even though I didn't press the "erase all data on the partition" button. I was able to enter F19 with the rescue option and changed the UUID of swap, but, still no boot.

So, I found this in the release notes:
Boot speed is improved by removing unused features from the initramfs. If new hardware is added, boot into the rescue initramfs and use the command dracut --regenerate-all --force to rebuild and replace the old initramfs.

So, I ran dracut --regenerate-all --force to rebuild and replace the old initramfs, and, bingo, all fixed.

On my UEFI box, I don't think I'll be moving the hard disk over to another box, so, this new custom intramfs that targets the hardware on the box it is installed on, is kind of nice, and, it does speed up boot. I still haven't decided how useful it is when I'm swapping legacy bios installs from one machine to another, but, there's always the dracut-nohostonly rpm package for those installs.

At least there's a rescue kernel in grub. As soon as I found out what to do, it made it easier to fix it.

[AdamW]

dbelton: well, it does kinda make sense for systemd to be doing it. It's mostly just unfortunate timing that we decided to pick up biosdevname and then systemd started doing the same thing shortly after. A lot of us do wish they could at least use broadly similar naming schemes, but systemd even has an answer for that (they have some plausible reasons why the biosdevname scheme is not great). So, sigh, whaddayagonnado.