Cristian Rodríguez wrote:

El 17/05/13 14:20, Per Jessen escribió:

...

This new network interface naming scheme is going to drive me up the wall :-)

With 13.1 M1 :

system A: "enp13s0" and "enp14s0"

system B: "enp3s1f0", "enp3s1f1", "enp6s2"

Yeah, That's expected, please read the udev documentation for details on how to disable or change if not wanted.

http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterface...

Hmm, I got a 404 on that one. Wasn't this discussed on opensuse-factory a little while ago? What was the outcome - that we make sure people can retain the ethX naming scheme if they so desire? Anyway, it's for 13.1 so probably not really on-topic here, but I thought those interface names were just hilarious. I wonder what vlans and ipip interface names will look like :-) -- Per Jessen, Zürich (11.7°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

[18.05.2013 12:29] [Andrey Borzenkov]:

В Sat, 18 May 2013 09:08:49 +0200 Per Jessen пишет:

...

but I thought those interface names were just hilarious.

They are just as good sequence of characters as any other. Why do you automatically assume that eth or wlan are any more meaningful? Just because you happen to speak English? There are languages that do not even use Latin alphabet.

It is a change in naming. From where to where does not matter. When you have a server that used to have a network interface named eth0 and it becomes enp13s0, you have the problem, that several pieces of network monitoring will not work (since they are configured for eth0), as well as several shell scripts have to be adapted (as they contain eth0). Looking at the scripts that exist, and their quite obfusc^Wunintuitive scripting style, changing will cause errors. It is similar to the renaming of /dev/hda to /dev/sda, which also caused a lot of calls for help everywhere. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----Original Message----- From: Andrey Borzenkov To: opensuse@opensuse.org Subject: Re: [opensuse] new network interfaqce naming scheme Date: Sat, 18 May 2013 18:35:41 +0400 В Sat, 18 May 2013 13:47:37 +0200 Werner Flamme пишет: For new installations one name is as good as another. I personally find new names more useful. If you want to disable them, it is trivial. You'll get whatever kernel gives you. -----Original Message----- I _strongly_ dis agree! I have lots of programs that interface with eth*** When i install them on another machine the just work These are just ethernet devices i i couldn't care less if the are from company A or from company B. With regards to hard-drive names: i don't mind _if_ they change it, but stick to the name (what ever it may be) This can get worse and worse: boards/xhips from broadcom will initially be named bcm01, but chips from broadcom made on FRYDAY will be named bcmf01, unless this friday was in the month December, in which case it becomes bcmd01...... Or like the name of the powerdeamon depends of the color of your power-plug! Or the name of your web-server-daemon can not be apache anymore, but is dependent on the name of your internet-provider and/or the name of your contract. One might suggest that _all_ interfaces that facilitate IP-communication should be given a name like "IP0001", disregarding the manufacturer, media-type, speed, 4/6-protocol. But then you forget that ethernet devices can be used for something else besides IP. So, lets call all ETHernet devices: eth0 -- eth99 hw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

В Sun, 19 May 2013 13:36:01 -0700 John Andersen пишет:

On 5/19/2013 7:58 AM, Hans Witvliet wrote:

It was me, not Hans. Just to make it clear :)

...

For new installations one name is as good as another. I personally find new names more useful. If you want to disable them, it is trivial. You'll get whatever kernel gives you.

Installations are only new once.

When you have a a short obsolescence schedule as found in OpenSuse, you have to upgrade in place more often than you fresh install.

New scheme is just last resort default. Give your interface name you like and it will be used. On update 70-persistent-net.rules is not deleted.

The big surprise of having interface names wander around or switch positions (like they did in one of the OS 10.x releases) can be pretty time consuming to sort out. Most of us that encountered this went back an imposed the old interface names because there were just too many things that were dependent on those names. Firewalls, Samba, cups, and various other daemons were all hard coded for those names back then. (and still today in some cases).

True, anyone using OpenSuse has volunteered to be a lab rat, and anyone relying on it for any critical business should be using SLED or SLES.

But it didn't always use to be that way, and some of us have been using some form of Suse long enough to remember those days.

I find zero benefit in any new naming convention for interfaces.

It was great when you could build a machine, grab your permanent marker and write ETH0 on the back of one nic and ETH1 on the other, and never expect to have to change that for the life of the hardware.

Hardware sometimes dies and needs replacement. At which point your permanent marks do not fit any more.

I was livid when an OS upgrade (somewhere after OS 9.3) decided to swap the order of nics and exposed an entire samba server to the wide wooly world.

One of goals for suggested naming scheme is to eliminate this problem in the future making it independent of scan order. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, 20 May 2013 14:07:07 Linda Walsh wrote: [...]

Have you ever use Windows and changed the bus slot on a piece of hardware? It thinks it's entirely new and, by default tries to go out and search for a NEW driver -- even though you just unplugged your mouse from one USB slot and plugged it into an adjacent slot. That's considered reliable or useful?

No, I've never had that happen to me - not on XP, Windows Server (2000-2008) or Windows 7 (never used Vista and avoid 8 like the plague).

...

One of goals for suggested naming scheme is to eliminate this problem in the future making it independent of scan order.

--- The new interface scheme makes it dependent on the position of the device on the particular bus -- so like I have seen above, those names change simply by moving a USB cable from one slot to the next.

That doesn't create a stable naming scheme.

That is stupidity. I cannot think of a single use-case where having the name of a device change when it is unplugged and re-plugged would be useful. -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au ============================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2013-05-22 00:19 (GMT+0930) Rodney Baker composed:

Linda Walsh wrote:

...

Have you ever use Windows and changed the bus slot on a piece of hardware? It thinks it's entirely new and, by default tries to go out and search for a NEW driver -- even though you just unplugged your mouse from one USB slot and plugged it into an adjacent

No, I've never had that happen to me - not on XP, Windows Server (2000-2008) or Windows 7 (never used Vista and avoid 8 like the plague).

You've never gone into XP's safe mode device manager and found multiples of several identical hardware devices, or gone into "Network Connections" and seen "Local Area Connection 2" in a machine that never had more than one ethernet device? If not, count yourself lucky. A BIOS upgrade or reset has certainly done it plenty of times here. So will moving a sole HD from one system to its identical twin, triplet or quadruplet. The MAC is different, so XP counts it as a totally different device regardless that it requires the same driver. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrey Borzenkov wrote:

В Sat, 18 May 2013 09:08:49 +0200 Per Jessen пишет:

...

but I thought those interface names were just hilarious.

They are just as good sequence of characters as any other.

I beg to differ. They make me smile, whereas 'eth0' doesn't.

Why do you automatically assume that eth or wlan are any more meaningful?

Please, I am not automatically assuming anything, I am expressing my opinion. When I have a server with four fixed ethernet interfaces numbered 1,2,3,4 by the manufacturer, and a fibre card with another two numbered 0 and 1, I tend to assign names eth0, eth1, eth2, eth3, eth4, eth5 corresponding to the manufacturer's numbering 1-4 and 0-1. To me that is more meaningful than this gibberish: enp13s0, enp14s0, enp3s1f0, enp3s1f1, enp6s2. Using eth0-9 is also more in line with the other enumeration schemes we use - ttyS0-3, scsi0-9, sda-sdz etc. etc. Three key issues that I see 1) The new naming will be different from machine to machine. 2) On some machines it doesn't even work. (probably due to BIOS-problems, but we have to live with those). 3) The names are difficult to express, regardless of which languages one speaks: enp14s0 = ee-en-pee-fourteen-ess-zero. enp3s1f0 = ee-en-pee-three-ess-one-eff-zero". I prefer 'eth0' = "ethernet-zero". -- Per Jessen, Zürich (21.0°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrey Borzenkov wrote:

В Sat, 18 May 2013 17:59:56 +0200 Per Jessen пишет:

...

Andrey Borzenkov wrote:

...

В Sat, 18 May 2013 09:08:49 +0200 Per Jessen пишет:

...

but I thought those interface names were just hilarious.

They are just as good sequence of characters as any other.

I beg to differ. They make me smile, whereas 'eth0' doesn't.

Well, this makes further discussion pointless.

You can continue to use eth0 further, it is easy to disable new naming scheme.

Yes, I know and I am grateful. If this new scheme had been forcibly imposed on everyone in a one-size-will-fit-all Microsoft way, you would have heard a much different reaction.

But one thing I wonder is

...

When I have a server with four fixed ethernet interfaces numbered 1,2,3,4 by the manufacturer, and a fibre card with another two numbered 0 and 1, I tend to assign names eth0, eth1, eth2, eth3, eth4, eth5

How exactly do you *assign* them?

Today it is done by way of /etc/udev/rules.d/70-persistent-net.rules using the MAC-address as the key. In my experience, the initial automatically generated rules are good for 90-95% of the cases. -- Per Jessen, Zürich (21.8°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

В Sun, 19 May 2013 09:19:22 +0200 Per Jessen пишет:

Per Jessen wrote:

...

Andrey Borzenkov wrote:

...

В Sat, 18 May 2013 17:59:56 +0200 Per Jessen пишет:

...

Andrey Borzenkov wrote:

...

В Sat, 18 May 2013 09:08:49 +0200 Per Jessen пишет:

...

but I thought those interface names were just hilarious.

They are just as good sequence of characters as any other.

I beg to differ. They make me smile, whereas 'eth0' doesn't.

Well, this makes further discussion pointless.

You can continue to use eth0 further, it is easy to disable new naming scheme.

Yes, I know and I am grateful.

Disabling the new naming scheme is easy, but what we need is an option to revert to the previous openSUSE behaviour of having persistent net names:

https://bugzilla.novell.com/show_bug.cgi?id=820589

The problem is, renaming of interfaces did not always work reliably. Which was the exact reason why it was dropped upstream. If you believe this decision is wrong and renaming can be done reliably you should really discuss it upstream and convince them to revert to old behavior. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

В Sun, 19 May 2013 09:59:39 +0200 Per Jessen пишет:

Andrey Borzenkov wrote:

...

В Sun, 19 May 2013 09:19:22 +0200 Per Jessen пишет:

...

Per Jessen wrote:

[snip]

...

Disabling the new naming scheme is easy, but what we need is an option to revert to the previous openSUSE behaviour of having persistent net names:

https://bugzilla.novell.com/show_bug.cgi?id=820589

The problem is, renaming of interfaces did not always work reliably. Which was the exact reason why it was dropped upstream.

Well, the new naming scheme also does not always work reliably (nor consistently). What do you propose we do - drop it too? :-)

If it will be found that it has problems that are too hard to solve - yes. I think it is too early to make any statement at this point.

...

If you believe this decision is wrong and renaming can be done reliably you should really discuss it upstream and convince them to revert to old behavior.

I am discussing it here where it is important, in an openSUSE user forum. If we don't want to alienate our user base, we should provide a way of reverting to the previous behaviour.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Werner Flamme wrote:

[19.05.2013 09:59] [Per Jessen]:

...

I am discussing it here where it is important, in an openSUSE user forum. If we don't want to alienate our user base, we should provide a way of reverting to the previous behaviour.

I think there is a way to switch back to the old behaviour, but it was nice if there was something like a checkbox during install where you can choose between old and new naming conventions.

Switching off PredictableNetworkInterfaceNames (it has to be the most in appropriately named feature in history) is easily done, but we would still need the persistent-net-name udev rules. AFAICS. I agree the Right Thing(r) would be to have such a checkbox. -- Per Jessen, Zürich (13.7°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez wrote:

On 05/19/2013 03:19 AM, Per Jessen wrote:

...

Per Jessen wrote:

...

Andrey Borzenkov wrote:

...

В Sat, 18 May 2013 17:59:56 +0200 Per Jessen пишет:

...

Andrey Borzenkov wrote:

...

В Sat, 18 May 2013 09:08:49 +0200 Per Jessen пишет:

> but I thought those interface names were just hilarious.

They are just as good sequence of characters as any other.

I beg to differ. They make me smile, whereas 'eth0' doesn't.

Well, this makes further discussion pointless.

You can continue to use eth0 further, it is easy to disable new naming scheme.

Yes, I know and I am grateful.

Disabling the new naming scheme is easy, but what we need is an option to revert to the previous openSUSE behaviour of having persistent net names:

https://bugzilla.novell.com/show_bug.cgi?id=820589

No! will you maintain out-of-tree code thst can break anytime just tonplease a few users ?

Sure, it is my right in our socalled "do-ocracy". When it's only about a few users, it won't break very often. In any case, I estimate that maintaining what has sofar worked quite well will be a lot less effort than adapting everything else to this new naming scheme, in particular for the interim period until everything uses the new scheme (likely several years).

STOP, this illusion of choice is incredible dangerous and demands quite a bit of human resources.

STOP yourself, you're a community member just like myself, why are you concerned about "human resources" instead of the plight of our users? As for illusion of choice - Cristian, choice is exactly what we have. The less user-friendly we make openSUSE, the more likely it is that people will choose to go elsewhere. Theirs and our _choice_. -- Per Jessen, Zürich (12.2°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez wrote:

STOP, this illusion of choice is incredible dangerous and demands quite a bit of human resources.

---- For someone who is not a SuSE employee, you seem to be saying that SuSE has no choice? What's the point of having different distro's if there is no choice? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/17/2013 02:23 PM, Werner Flamme pecked at the keyboard and wrote:

[17.05.2013 20:20] [Per Jessen]:

...

This new network interface naming scheme is going to drive me up the wall :-)

With 13.1 M1 :

system A: "enp13s0" and "enp14s0"

system B: "enp3s1f0", "enp3s1f1", "enp6s2"

So, you don't know Solaris, do you :-D

I guess the old adage of "don't fix it if it ain't broke" doesn't apply anymore. So what is broke with using eth# ? -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

[17.05.2013 22:00] [Cristian Rodríguez]:

El 17/05/13 15:43, Ken Schneider - openSUSE escribió:

...

I guess the old adage of "don't fix it if it ain't broke" doesn't apply anymore. So what is broke with using eth# ?

What has always been, for decades, network interface numbering is not persistent across reboots, so all distributions added their custom ways to try to solve the problem, all have bugs. there is now a set of udev rules to provide an unified way for all distributions to use.

Not persistent across reboots? What happened to my best friend, called /etc/udev/rules.d/70-persistent-net.rules, then? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

[17.05.2013 22:15] [John Andersen]:

On 5/17/2013 1:13 PM, Werner Flamme wrote:

...

[17.05.2013 22:00] [Cristian Rodríguez]:

...

El 17/05/13 15:43, Ken Schneider - openSUSE escribió:

...

I guess the old adage of "don't fix it if it ain't broke" doesn't apply anymore. So what is broke with using eth# ?

What has always been, for decades, network interface numbering is not persistent across reboots, so all distributions added their custom ways to try to solve the problem, all have bugs. there is now a set of udev rules to provide an unified way for all distributions to use.

Not persistent across reboots? What happened to my best friend, called /etc/udev/rules.d/70-persistent-net.rules, then?

I'm pretty sure that had you read what Cristian wrote, and what you quoted, you would have seen that he covered this.

I did read. But I do not understand the connection between two parts of his writing: - When the way via /etc/udev/rules.d/70-persistent-net.rules worked, why does Cristian say that "interface numbering is not persistent across reboots"? - Plus, when he speaks about "a set of udev rules to provide an unified way", what do the new names change or make better? The udev rules connect interface names to MACs, and the network configuration connects addresses to interface names. Why had the names to change? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

[18.05.2013 07:59] [Cristian Rodríguez]:

On 05/18/2013 12:58 AM, Werner Flamme wrote:

...

The udev rules connect interface names to MACs, and the network configuration connects addresses to interface names. Why had the names to change?

The rules are to expose new "net-id" functionality in udev, why the names have to change is explained in the relevant documentation.

I only find http://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNam..., and all the links there (all to http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterface...) show only a 404 error. But as I see it's in connection with systemd, so any discussion ist futile. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian RodrC-guez wrote:

On 05/18/2013 02:24 AM, Werner Flamme wrote:

systemd itself does nothing absolutely with network interfaces.

liar liar pants on fire. www/ Software/ systemd/ PredictableNetworkInterfaceNames Back to systemd Predictable Network Interface Names --- Why is the required? Because no booting from Harddisk with writable storage. Another reason why booting from initrd is bad. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2013-05-17 15:43 (GMT-0400) Ken Schneider - openSUSE composed:

So what is broke with using eth# ?

Nothing, but only as long as you only have a single network interface from installation time onward. :-( -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

From: Chuck Payne To: Felix Miata Cc: suse Subject: Re: [opensuse] new network interfaqce naming scheme Date: Fri, 17 May 2013 16:41:26 -0400 Are we going to the BSD style of naming? bge = boardcom igb = intel Or to the way Fedora doing it? p1p1 = eth0 boardcom I think the bsd nice because you can tell what card you work with. -----Original Message----- Absolutely horrible. It will break god-knows how many scripts. If you are so eager to find out some details about the card, use hwinfo or ethtool. If they need to give the interfaces some other name, that is already bad enough. But keep all ethernet interfaces the same name!!!!!!!! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hans Witvliet wrote:

From: Chuck Payne To: Felix Miata Cc: suse Subject: Re: [opensuse] new network interfaqce naming scheme Date: Fri, 17 May 2013 16:41:26 -0400

Are we going to the BSD style of naming?

bge = boardcom igb = intel

Or to the way Fedora doing it?

p1p1 = eth0 boardcom

I think the bsd nice because you can tell what card you work with.

-----Original Message-----

Absolutely horrible. It will break god-knows how many scripts.

And sysadmins :-) -- Per Jessen, Zürich (12.9°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Linda Walsh wrote:

They are whining about not having access to a permanent storage to store the mappings in (like the:

/etc/udev/rules.d/70-persistent-net.rules,

...

...

...

hard disk... <<<

THis is all related to booting from a ***ramdisk** -- no permanent storage... this brought this problem, so their fix is to do away with user allowed interfaces...

Um, no one out there interested in pushing direct boot from hard disks as being required boot option?

You mean without an initrd? Not me, I'm afraid. Using an initrd works very well for me, without exception. -- Per Jessen, Zürich (9.8°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Linda Walsh wrote:

Per Jessen wrote:

...

Linda Walsh wrote:

...

Um, no one out there interested in pushing direct boot from hard disks as being required boot option?

You mean without an initrd? Not me, I'm afraid. Using an initrd works very well for me, without exception. -=--- People were very happy with the horse drawn carriage too, before the automobile came around.

I'm not saying initrd doesn't make people happy, but that it does is a bit strange. Does anyone know why it is better on a specific system than having a system boot off a hard disk directly?

My systems all have a stock openSUSE-kernel plus a local custom-built initrd (bult by mkinitrd). I would prefer not having to maintain a custom-built kernel per system, it's much easier+faster building the initrd with mkinitrd.

You boot off the HD directly and instead of a 20-40M initHD, you load a 3-6M kernel. It generally boots quite a bit faster when optimized

I try hard to avoid booting my server systems. Boot-time is virtually irrelevant. My initrd is usually about 6M btw. Desktop systems are booted everyday, but again boot-time isn't critical. -- Per Jessen, Zürich (12.5°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

John Andersen wrote:

On 5/19/2013 11:54 AM, Per Jessen wrote:

...

...

I'm not saying initrd doesn't make people happy, but that it does is a

...

bit strange. Does anyone know why it is better on a specific system than having a system boot off a hard disk directly?

...

My systems all have a stock openSUSE-kernel plus a local custom-built initrd (bult by mkinitrd). I would prefer not having to maintain a custom-built kernel per system, it's much easier+faster building the initrd with mkinitrd.

But that's not even part of the argument here.

The discussion is WHY is mkinitrd even necessary, and not using initrd does not force you to build a custom built kernel.

Okay, then I probably don't understand what we're talking about. Can someone please enlighten me?

Initrd IS a custom-built kernel. So what you want to avoid, is already being done for you.

I don't understand how an initrd is a custom-built kernel. If I install e.g. openSUSE 13.1 on three different systems, the kernel installed is the same, but the initrd is built per system. -- Per Jessen, Zürich (13.2°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, 2013-05-20 at 13:58 -0700, Linda Walsh wrote:

Per Jessen wrote:

...

...

Initrd IS a custom-built kernel. So what you want to avoid, is already being done for you. I don't understand how an initrd is a custom-built kernel. If I install e.g. openSUSE 13.1 on three different systems, the kernel installed is the same, but the initrd is built per system. ==== He is saying that "initrd" is part of your boot image. The kernel may be a separate image, but are no longer booting from the kernel -- you are booting from a custom/per system image called initrd that has to be built after every kernel build and init script change. Vs. you only have to install the kernel after a new kernel build... init-script or systemd changes wouldn't require building a new initrd.

AND the consequence of the Vs. is that you are dramatically less likely to do an update and then discover your system 'boots' to a grub fail screen. die initrd die; eliminating it just eliminates a potential failure point. -- Adam Tauno Williams mailto:awilliam@whitemice.org GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Roger Oberholtzer wrote:

On Fri, 2013-05-24 at 16:14 -0400, Adam Tauno Williams wrote:

...

die initrd die; eliminating it just eliminates a potential failure point.

On one hand I agree. On the other, I wonder about things like diskless installs that boot over the network. Accessing a kernel and an initrd file via tftp is no problem. More than that seems complicated...

Machines in the 80's and 90's did it all the time. They didn't have the luxury of having enough RAM to put a file system on RAM. It's more straight forward than booting from an INITRD -- as you boot the kernel which already had all the drivers it needed for your hardware built-in.. Then it mounted a remote NFS root and brought up services from that. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 6/11/2013 2:23 AM, Per Jessen wrote:

Linda Walsh wrote:

...

Roger Oberholtzer wrote:

...

On Fri, 2013-05-24 at 16:14 -0400, Adam Tauno Williams wrote:

...

die initrd die; eliminating it just eliminates a potential failure point.

On one hand I agree. On the other, I wonder about things like diskless installs that boot over the network. Accessing a kernel and an initrd file via tftp is no problem. More than that seems complicated...

---

Machines in the 80's and 90's did it all the time. They didn't have the luxury of having enough RAM to put a file system on RAM. It's more straight forward than booting from an INITRD -- as you boot the kernel which already had all the drivers it needed for your hardware built-in.. Then it mounted a remote NFS root and brought up services from that.

Now that we do have the luxury of enough RAM, it's difficult to see the advantage of not using an initrd. From my (even if somewhat limited) perspective, loading one or two files over the network for a PXE boot makes no big difference. (yes, I have a number of boxes that boot over PXE, plus some that have root on NFS or iSCSI).

I have encountered a few different situations where the bios or the nic-bios could successfully load one file, but then that one file couldn't load anything else, or there wasn't all that much ram available for real-mode boot code even if there was many gigs installed. So, maybe the bios could load grub, but then grub couldn't load any kernels or initrds. Well if I had a kernel with the right drivers built in I'd be fine, the bios could load the kernel and the kernel could handle the rest. A kernel can be made to support infinitely more things than grub or any other bootloader can. grub2, being modular, is a start, sort of, but then how many hardware and filesystem and abstraction layer makers build grub2 modules to match their kernel modules, or worse yet their windows dll's? And you stiil have the problem of loading the modules which the initial part of grub can not do! Or maybe the bootloader can load both kernel and initrd but it's freedos, needed by firmware update flashers for everything from individual hard drives on up, but something about the motherboard is incompatible with freedos in grub or syslinux "memdisk" and it just crashes if you try to load either ems or xms drivers to access memory above 1M. In short, asking why someone doesn't want to use an initrd is the wrong question to start with. Just as wrong as it would be to ask why someone WOULD want to use and initrd. The answers are unpredictable and infinite in both cases. The question is what is the excuse for removing functionality and adding dependencies? There is none. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Brian K. White wrote:

On 6/11/2013 2:23 AM, Per Jessen wrote:

...

Now that we do have the luxury of enough RAM, it's difficult to see the advantage of not using an initrd.

It's nearly twice as slow than w/o it? It's easier to slip something unseen into your initrd than it is the kernel? just to think of a few...

In short, asking why someone doesn't want to use an initrd is the wrong question to start with. Just as wrong as it would be to ask why someone WOULD want to use and initrd.

Cuz your distro folks are doing everything in their power to force you to use it? Partly linux's fault I suppose, there's no autoconfig for building a custom kernel for your HW. It allows them to fake things like mounting by disk-label?

The question is what is the excuse for removing functionality and adding dependencies? There is none.

It's a cheaper and easier way to let them focus on all the problems systemd is bringing? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, 2013-06-11 at 12:01 +0200, Per Jessen wrote:

Linda Walsh wrote:

...

Brian K. White wrote:

...

On 6/11/2013 2:23 AM, Per Jessen wrote:

...

Now that we do have the luxury of enough RAM, it's difficult to see the advantage of not using an initrd.

---

It's nearly twice as slow than w/o it?

It's easier to slip something unseen into your initrd than it is the kernel?

just to think of a few...

No doubt those are valid reasons, although I had more functionality- oriented ones in mind. For my situation, those two reasons don't really apply: loading the initrd only takes slightly longer than loading the kernel, so a total of a few seconds (apprx 4Mb kernel + 6M initrd). In comparison, most servers take much longer to initiate/run the POST. I guess someone could "slip" something into mkinitrd and therefore into the initrd, but as I trust the distro and I trust mkinitrd, it's a "risk" I can live with.

And if needed components are all reterived as separate files via NFS, how does that protect against insertion? I would think that initrd is easier to monitor as it is a single file with a <fill in your favorite single file change detection mechanism>. As a minimum, changes from the last time it was deemed correct are straight forward to detect. An NFS mounted directory hierarchy would seem trickier (at least not easier) to monitor for things being slipped in. FYI, in our diskless use, the root file system is mounted over the network via a vblade server. So it does require any special amount of RAM on the machine. Blocks are retrieved as needed, much as would happen from a traditional hard disk. Perhaps a similar mechanism could be used for initrd. Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 6/11/2013 11:07 AM, Andrey Borzenkov wrote:

В Tue, 11 Jun 2013 03:22:41 -0400 "Brian K. White" пишет:

...

In short, asking why someone doesn't want to use an initrd is the wrong question to start with. Just as wrong as it would be to ask why someone WOULD want to use and initrd. The answers are unpredictable and infinite in both cases.

The question is what is the excuse for removing functionality and adding dependencies? There is none.

Could you remind which functionality was removed and which dependencies were added? I am serious, I lost myself in this thread. And how is it related to new network interface naming scheme? :)

Has almost nothing directly to do with naming the interfaces. Changes to the naming schedules may ultimately be caused by changes to please systemd, but I don't really know that first hand so I'm not stating that. There are infinite functionalities removed by using systemd instead of sysv init scripts simply because of the fact that you can write anything you want into a shell script, which you can not do in a systemd unit file. Even if the unit file specifies to run a script, that is already too late to do what the original script and init could be made to do. There are many other issues which it would be silly and tedious to try to relist here. Just google systemd sysv and read until you are sick of reading about the topic :) No one wants me to go into it here. It will be a very long post. Dependencies was a general comment, in this case mostly just requiring an initrd to boot in all cases instead of having it be an option. Initrd is a very useful thing. I don't hate initrd. In some cases I would like to stuff an entire OS into initrd. I wouldn't exactly consider it progress if the option to use an initrd went away. It just needs to be an *option* instead of a *requirement*. Other dependencies which kill me are things like the systemd binary syslog database instead of directly readable text by things as basic as cat, or even dd, or even the shell itself with no external binary at all not even cat. And the graphical boot/plymouth/splash stuff that ends up requiring a lot of stuff to be in intrd. And the merged /usr stuff that ends up requiring a lot of stuff in initrd also, simply because there is no longer a set of basics in "/" at boot, which is a "progress" driven by systemd. systemd requires a kernel that has cgroups. systemd requires dbus! yegads dbus in init. If you can have both initrd and plain kernels that is the best. Sometimes your initrd is good while your system is broken, sometimes your system is good while your initrd is broken. Neither way is the one true way. You need both. Or at least you need the option for both even if one is used 99% of the time. Options and freedom are always better and confer more advantages than the advantages conferred by having strict requirements and limited choices. The idea of limiting choices is standardization, which is a good thing as far as it goes. A little bit of choice-limiting to bring standardization ends up giving you freedoms you didn't have before. You have the freedom to make assumptions about how things work, which lest you do things you couldn't do otherwise. But you can get the benefits of standardization without removing choices. Good standardization just provides a framework from within which to have all the same choices. Good standardization is also *optional* instead of a hard requirement. Good standards try to account for every possible need. *Really* good standards recognize that this is a valid ideal, but merely an ideal to always strive for but is also impossible to actually attain, and so they include a *graceful* way to draw outside the lines when you have to. Only the worst kind of inconsiderate sophomore tells everyone else what they don't need. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Felix Miata wrote:

On 2013-05-17 15:43 (GMT-0400) Ken Schneider - openSUSE composed:

...

So what is broke with using eth# ?

Nothing, but only as long as you only have a single network interface from installation time onward.

I have never had that... and never had a problem. Keeping uniform naming allows firewalls and traffic shaping to work. So all that will now break? Great -- based on whatever slot you happen to put your card in? how lovely. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org