[ale] eth numbering change

[Steve Litt]

On Thu, 9 Feb 2017 13:38:07 -0800
Alex Carver <agcarver+ale at acarver.net> wrote:

> On 2017-02-09 12:44, Phil Turmel wrote:
> > On 02/09/2017 12:19 PM, Alex Carver wrote:  

> >> I wouldn't say never.  I had one installation that steadfastly
> >> refused to boot properly with UUIDs for the disk.  It was a very
> >> recent kernel, too, which made it much more confusing.  I had to
> >> force it back to using /dev/sdAN references to get things
> >> working.  
> > 
> > The kernel doesn't process any of the naming schemes.  It all goes
> > to udev, which must be in the initramfs to boot off of a LABEL or
> > UUID root.  What you described is an initramfs failure.
> >  
> 
> <shrug> I'm just the end user of initramfs so if the developer breaks
> it in such a way that UUIDs or other device IDs don't work right then
> I've got nothing other than a workaround which happens to work.
> Given that initramfs is linked with kernel work then there was a nice
> breakdown somewhere between the kernel version and the initraamfs
> generation. Fortunately skipping UUIDs entirely allowed the system to
> boot normally even though the initramfs build process would complete
> "without errors".

In addition to what Alex writes in the preceding paragraph, some people
prefer not to have initramfs at all.

The purpose of initramfs is ONLY to get the root partition readable
enough to process /etc (let's forget about crazycases where /etc is a
mountpoint), after which the boot process can do what it's supposed to
do: Pull itself up by the bootstraps. The initramfs' init script should
have been an easy, tiny shellscript in most cases.

Unfortunately, over the years, initramfs has accumulated more
inappropriate useage than social security numbers. Now initramfs has
drivers for everything, and an init script no human can follow: Heck,
the init script is created by an application,  usually dracut these
days, so the initramfs init script is an intermediate file. Meanwhile,
the systemd crew has taken over development of dracut, and you know
it's only a matter of time before dracut stops working outside the
presence of a systemd PID1.

My personal observation tells me that with kernels ancient and modern
(I'm using 4.9.x right now) and everything inbetween, disk device names
are stable between boots. So personally, I might consider using the
device name in order to perhaps compile ext4 drivers into my kernel and
getting rid of the entire initramfs.

 
SteveT