Re: The Simple Things in Life

[Xen]

Martin Pitt schreef op 21-07-2016 7:09:


FWIW, this is the *only* reply to this thread that I will ever do. I'm
too busy following my secret agenda to reply to the other mails...


BTW, Martin.

https://piware.de/2016/12/last-day-at-canonical/

I knew you were ;-).












So Martin responded to a thread about systemd 
PredictableNetworkInterfaceNames.


I said that it was not in the interest of end users and that the choice 
to make this the default could be explained by putting business 
consumers first.


He considered that a conspiracy, and then 5 months later he is employed 
by that very same company that only has enterprise clients and that was 
pushing those changes. ;-).


--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: The Simple Things in Life

[Xen]

Matthew Paul Thomas schreef op 22-07-2016 12:28:


This technique could be extended to the rest of the startup. Instead of
the dots, show a determinate progress bar (that is, one that fills up).
In addition, *if* the progress bar hasn’t moved at all in the past ~5
seconds, show the most recent startup message below it.


I would probably suggest showing the current SystemD target being 
reached, or just having been reached.


In a sense you do not need the "show phases" thing to show technical 
information other than what part of the boot process is happening. In a 
sense, this is codified in the SystemD stages or targets such as the 
SysInit target and the Cryptsetup target.


But the startup messages are not saved, this is a huge issue for 
troubleshooting.


"Reached target Start Networking" ---<-- that is useful information.

KDE employs a 5-icon startup sequence or something like that. It is not 
hugely informational but at least illustrative.


I would prefer a startup sequence with either 5 icons (5 is the best 
number for this) or a progress bar, but both with text underneath such 
as "Starting Networking" or at worst, but still at best, if nothing else 
"Reached target XXX".


Checking filesystems
Starting networking
Mounting disks
Unlocking cryptography
Loading desktop

Those are candidates for "stages". They are also the most likely points 
where something can hang.


--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: The Simple Things in Life

[Matthew Paul Thomas]

John Moser wrote on 19/07/16 22:48:
>…
> I've been repeatedly distressed and confused by this hidden boot
> process.  I've sat and waited at blank screens and splashes that give
> no feedback, wondering if the kernel is hanging at initializing a
> driver, trying to find network, or making decisions about a disk.
> There is no standard flow which can be disrupted with a new, non-error
> status message curtly explaining that something is happening and all
> is well; there is a standard flow in which the machine displays a
> blank, meaningless state for a fixed amount of time, and deviation in
> that time by any more than a few tenths of a second gives the
> immediate, gut-wrenching feeling that the system has hanged during
> boot and is terminally broken in some mysterious and
> completely-unknown manner.

You can press Esc to see the startup messages so far. But that works
only for people who know about it. And if your PC won’t start up,
showing *all* the text is a poor way of communicating what’s stuck. It
doesn’t tell someone what to say, for example, when phoning their techie
friend/relative for help. “The screen’s gone black and it’s full of
writing.”

> What Ubuntu needs most is a simple, non-buried toggle option to show
> the boot process--including displaying the bootloader, displaying the
> kernel load messages, and listing which services are loading and
> already-loaded during the graphical boot.

The current graphical startup, and showing all the startup messages, are
two extremes of communication. A setting to choose between those
extremes wouldn’t stop them from being extremes.

When displaying progress of a task, a good rule of thumb is: it should
look different at least every few seconds, but text shouldn’t change
faster than people can read it.

The looping startup animation fails the first part of the rule, because
it looks identical now to how it did ~4 seconds ago and ~4 seconds
before that.

And showing all the startup messages would fail the second part of the
rule, because usually they’re too fast for most people to read. (Not to
mention that most of those messages are not written with end users in mind.)

Ubuntu does a decent job of this when checking a disk during startup.
It’s something that will make the startup take much longer than usual,
so steadily-changing text appears together with the usual graphics.

This technique could be extended to the rest of the startup. Instead of
the dots, show a determinate progress bar (that is, one that fills up).
In addition, *if* the progress bar hasn’t moved at all in the past ~5
seconds, show the most recent startup message below it.

>   Ubuntu's best current
> feature is the Recovery boot mode, aside from not having a setting to
> make this the standard boot mode sans the recovery prompt.

I expect most people would rate a Web browser or a file manager as a
better feature than a Recovery boot mode.

>…
> Even Android displays a count of system assemblies AOT cached during
> boots after update so as to convey to the user that something is
> indeed happening.

A roughly equivalent bug for Ubuntu Touch is “hook into system-image
updates to precompile policy prior to reboot”
.

-- 
mpt

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: The Simple Things in Life

[Xen]

C de-Avillez schreef op 21-07-2016 22:19:


But here you are referring to a mail thread on systemd-devel, and
ranting about how people that know what they are talking about (and
even tried to argue with you about it) do not agree with you.


I never said they didn't know what they are talking about. I said they 
apparently, evidence themselves, to have reasons, to deny the needs of 
real individual users, and favour only a select group of users that have 
needs that are now being met in some mediocre way (according to me, but 
I am sure a lot of people will agree with it) while costing all of those 
other people a whole lot, and then these costs are being downplayed and 
these benefits are being exaggerated.


Whenever something like that happens you just know something is fishy.

But just as the kernel developers are rumoured not to put up with 
bullshit, neither should I be expected to (or anyone).




So, no, this thread *is* important. It puts your comments in context.

https://www.mail-archive.com/systemd-devel%40lists.freedesktop.org/msg35744.html


Actually that was the second thread, apologies. I had forgotten there 
were two. That is also an annoying archive and it cost myself a great 
deal to find one that actually works, which is the main archive :p.


the threads (both of them, but I guess they are only one) are at 
https://lists.freedesktop.org/archives/systemd-devel/2016-April/thread.html 
and you can find them easily if you scroll down.




And, still, you antagonise people because you think they do not see
your PoV. You succeeded in getting Martin uninterested in discussing
this further with you.


You mean here? That is of no consequence. The discussion ended with Greg 
KH trying to explain to me that hardware was event driven and that as 
such devices could only make their presence known using events, as if 
speaking to a child, whereas *apparently* device drivers actually poll 
for devices (we were only talking about "onboard" devices here) and if 
they can't find any they quit - there is no wait time here that can 
suddenly extend for hours.


He even tried to explain to me that if hardware changes between boots 
(e.g. you add or remove hardware) that it would require "events" for the 
system to be notified about those changes.


Now you can stretch things very far but the system does not produce 
events while powered off.


But the only way I would get some truth on this (from my perspective) 
was apparently to just dive into the source code of some ethernet driver 
and see what it did.


At the same time they were /insisting/ that hardware can show up hours 
after booting the system (have you ever seen that happen, for onboard or 
physically-present devices?) and that as such, not only in a theoretical 
but also practical manner, the discovery phase of onboard hardware never 
ends, and that it therefore would be conceptually impossible to define 
any such end-point.


I'm sorry but I just don't like to be bullshitted in that way. It is 
completely obvious for any practical system such as my own, that all 
hardware is found within seconds.


So I don't know why this "theoretical implication" is important and they 
never revealed this, as such it was nothing more than a knock-down 
argument.


Greg apparently insisted on talking in hypotheses and never alluded to 
any real-world example. And based on this conceptual truth that was only 
demonstrated by talking about event-driven-hardware, where device 
drivers actually poll for hardware and if any events ever result from 
that, it is likened to a callback measure, and apparently very 
well-bounded in time (in any practical ,real system), based on this 
conceptual truth I was then supposed to accept that in practical terms 
any definition of an end-point in device discovery (for onboard devices, 
not usb or thunderbolt) would be unviable.


When it is completely obvious that in any real and functional system as 
we have today your hardware will be discovered within seconds. Many 
people alluded to having boot times measured in seconds for their 
systems.


If you can boot to your desktop in 5 seconds I am sure you can also 
discover your network devices within any bounded timeframe.


But I am repeating myself now.

They gave no good reason why a division in phases (device discovery, 
name remapping, network starting) would not be possible.


Other than by pointing to vague ideas of why it wouldn't work, refusing 
to become concrete with their statements, and keeping everything "up in 
the air" as to why it wouldn't work. I am a programmer myself and yes I 
did study operating systems although it was long ago.


If I don't understand something I like to get down to the core of it as 
to why that is so. And these answers did not suffice.


Now perhaps no one ever has a need or requirement to please this here 
person that I am, but that is not important.


The first three messages in the entire thread were these, and please 
apologize my 

Re: The Simple Things in Life

[C de-Avillez]

On Thu, 21 Jul 2016 22:02:53 +0200
Xen  wrote:

> C de-Avillez schreef op 21-07-2016 21:48:
> > On Thu, 21 Jul 2016 14:19:34 +0200
> > Xen  wrote:
> > 
> > 
> >   
> >> > FWIW, this is the *only* reply to this thread that I will ever
> >> > do. I'm too busy following by secret agenda to reply to the other
> >> > mails...  
> >> 
> >> Rightly so! This is important work you do. You should be proud of
> >> it ;-).  
> > 
> > 
> > How about you give us a link to the systemd-devel thread about this?
> > Then we will be able to read the source, instead of your
> > interpretation and attacks.  
> 
> If you wanted that, you would already have found it, so I don't think 
> you do.

...

> I don't give people stuff they are not interested in, or are only 
> interested in in order to break someone down, such as that you are 
> demonstrating here.

But here you are referring to a mail thread on systemd-devel, and
ranting about how people that know what they are talking about (and
even tried to argue with you about it) do not agree with you.

So, no, this thread *is* important. It puts your comments in context.

https://www.mail-archive.com/systemd-devel%40lists.freedesktop.org/msg35744.html

And, still, you antagonise people because you think they do not see
your PoV. You succeeded in getting Martin uninterested in discussing 
this further with you.

This is the end of the thread, for me as well. But the other subscribers
should have the source.

I am not interested in breaking anyone down. I am, though, interested in
understanding what is going on.

Cheers,

..C..




pgpWwtTi6gLEW.pgp
Description: OpenPGP digital signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: The Simple Things in Life

[Xen]

C de-Avillez schreef op 21-07-2016 21:48:

On Thu, 21 Jul 2016 14:19:34 +0200
Xen  wrote:




> FWIW, this is the *only* reply to this thread that I will ever do.
> I'm too busy following by secret agenda to reply to the other
> mails...

Rightly so! This is important work you do. You should be proud of it
;-).



How about you give us a link to the systemd-devel thread about this?
Then we will be able to read the source, instead of your interpretation
and attacks.


If you wanted that, you would already have found it, so I don't think 
you do.


I don't give people stuff they are not interested in, or are only 
interested in in order to break someone down, such as that you are 
demonstrating here.


Regards.

--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: The Simple Things in Life

[C de-Avillez]

On Thu, 21 Jul 2016 14:19:34 +0200
Xen  wrote:



> > FWIW, this is the *only* reply to this thread that I will ever do.
> > I'm too busy following by secret agenda to reply to the other
> > mails...  
> 
> Rightly so! This is important work you do. You should be proud of it 
> ;-).


How about you give us a link to the systemd-devel thread about this?
Then we will be able to read the source, instead of your interpretation
and attacks.

Cheers,

..C..


pgpiOPO1mGKBb.pgp
Description: OpenPGP digital signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: The Simple Things in Life

[Ralf Mardorf]

On Thu, 21 Jul 2016 17:27:38 +0200, Ralf Mardorf wrote:
>I just noticed, that on my machine the do-release-upgrade must have
>removed some very important configs, seemingly 
>/etc/modprobe.d/alsa-base.conf, too.  

Oops, it was only a false alarm. I don't know why it's missing, but
it's also missing in a backup I made before I upgraded, so it was not
removed by the do-release-upgrade. An /etc/security config I was
missing, is still were it should be, IOW it isn't missing. Perhaps I
made a typo when I tried to ls or to cat it.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: The Simple Things in Life

[Ralf Mardorf]

On Thu, 21 Jul 2016 16:27:57 +0200, Xen wrote:
>Ralf Mardorf schreef op 21-07-2016 15:44:
>> On Thu, 21 Jul 2016 15:14:28 +0200, Xen wrote:  
>>> You can't change installed PCI devices on the fly  
>> 
>> No, I need to turn of the computer and after removing or mounting a
>> sound card, I need to boot the Linux install. However, I only have
>> one network device, the mobo's on-board device and enp?s0 has not
>> always the
>> same number.  
>
>Inserting another device (such as some serial port controller) in a
>slot before the soundcard will also change the address of the
>soundcard, and it will "ruin" the sound configuration you had (at
>least in KDE) because it will deactivate (but not remove) your older
>registered devices and it will not find that they are actually the
>same.

You can enforce that a sound card becomes alsa hw:0 and nothing else is
required, since the sound servers use alsa.

Write a /etc/modprobe.d/alsa-base.conf with

options snd slots=driver_name

for example

$ cat /etc/modprobe.d/alsa-base.conf 
# ALSA module ordering
options snd slots=snd_hdspm,snd_ice1712,snd_ice1712

I just noticed, that on my machine the do-release-upgrade must have
removed some very important configs,
seemingly /etc/modprobe.d/alsa-base.conf, too.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: The Simple Things in Life

[Xen]

Ralf Mardorf schreef op 21-07-2016 15:44:

On Thu, 21 Jul 2016 15:14:28 +0200, Xen wrote:

You can't change installed PCI devices on the fly


No, I need to turn of the computer and after removing or mounting a
sound card, I need to boot the Linux install. However, I only have one
network device, the mobo's on-board device and enp?s0 has not always 
the

same number.


Inserting another device (such as some serial port controller) in a slot 
before the soundcard will also change the address of the soundcard, and 
it will "ruin" the sound configuration you had (at least in KDE) because 
it will deactivate (but not remove) your older registered devices and it 
will not find that they are actually the same.


--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: The Simple Things in Life

[Ralf Mardorf]

On Thu, 21 Jul 2016 15:14:28 +0200, Xen wrote:
>You can't change installed PCI devices on the fly  

No, I need to turn of the computer and after removing or mounting a
sound card, I need to boot the Linux install. However, I only have one
network device, the mobo's on-board device and enp?s0 has not always the
same number.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: The Simple Things in Life

[Xen]

Ralf Mardorf schreef op 21-07-2016 11:57:

On Thu, 21 Jul 2016 03:00:47 +, Xen wrote:

I still don't like seeing this enp4s0 (under the previous motherboard
it was enp3s0, go figure) whenever I look under the hood and detest it
to the bone.


Hi,

this number already changes for my mobo's only network device, if I
remove or add PCI sound cards. I solved it by using a wild card.

$ grep -A2 "dhcpcd_on()" /usr/local/sbin/alice-dhcp
dhcpcd_on() {
  echo ; dhcpcd $(basename $(ls -d /sys/class/net/enp?s0)) ; echo
}


I've also used that strategy somewhere; to just list all devices and 
take the head -1 of that.


Coincidentally, that is like the exact equivalent of what I was 
proposing, or what I proposed.


This "ls /sys/class/net/enp?s0 | sort" (as a manner of speaking) 
produces that condensed list I was talking about. You merely need to 
replace each item on the list with ethX where X is the sequence number 
in the list (index, order) and you've got the scheme I wanted.


You can't change installed PCI devices on the fly (hopefully, although 
they mentioned Thunderbolt which would complicate things) (but I think 
Thunderbolt is on a different naming scheme?) so this order and this 
list should always stay fixed during the operation of the machine.


But then Martin Pitt would know (probably ;-)) he or she is just not 
telling us ;-).


At least the systemd-devel discussion was not any form of vileness, it 
was a serious debate in that sense with disregard of some people that 
tried to turn it into dogfighting, but those were not named person and 
unnamed kernel developer, which were rather respectful both and good 
partners in any sense in a debate at all.


So thank you Martin Pitt for your cooperation there but I just did not 
like what the kernel dev was doing which was throwing up roadblocks 
which have no real merit in reality and I am just a 1000% sure of that.


I am a designer and developer myself. I know when something is bullshit 
okay.


You can smell it from a mile away if you have designed enough software 
already.


--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: The Simple Things in Life

[Xen]

Martin Pitt schreef op 21-07-2016 7:09:

Xen [2016-07-21  5:22 +0200]:

It was  ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules.

But that doesn't work, it used to work somewhere at some point.


It does work, other than for USB devices, which is LP: #1593379. It
got fixed in xenial-updates two days ago.

Perhaps you forgot to "update-initramfs -u" after that and have the
USB device already connected.


Oh you're right. Stupid me.

I keep forgetting that, of course it happens in the initrd . *hit 
self*



That thing is not mentioned on the man page 
(https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/).




FWIW, this is the *only* reply to this thread that I will ever do. I'm
too busy following by secret agenda to reply to the other mails...


Rightly so! This is important work you do. You should be proud of it 
;-).


More on a serious note, where are the serious notes gone to? I can't 
find them.


I think it is pretty obvious that the interests of regular people are 
not taken into account but the interests of non-regular people are. That 
is not right to me.


--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: The Simple Things in Life

[Ralf Mardorf]

On Thu, 21 Jul 2016 03:00:47 +, Xen wrote:
>I still don't like seeing this enp4s0 (under the previous motherboard
>it was enp3s0, go figure) whenever I look under the hood and detest it
>to the bone.

Hi,

this number already changes for my mobo's only network device, if I
remove or add PCI sound cards. I solved it by using a wild card.

$ grep -A2 "dhcpcd_on()" /usr/local/sbin/alice-dhcp 
dhcpcd_on() {
  echo ; dhcpcd $(basename $(ls -d /sys/class/net/enp?s0)) ; echo
}

Regards,
Ralf

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: The Simple Things in Life

[Martin Pitt]

Xen [2016-07-21  5:22 +0200]:
> It was  ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules.
> 
> But that doesn't work, it used to work somewhere at some point.

It does work, other than for USB devices, which is LP: #1593379. It
got fixed in xenial-updates two days ago.

Perhaps you forgot to "update-initramfs -u" after that and have the
USB device already connected.

FWIW, this is the *only* reply to this thread that I will ever do. I'm
too busy following by secret agenda to reply to the other mails...

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: The Simple Things in Life

[Markus Lankeit]

*chuckle*

I think you hit it on the head with the house numbers... Eventually, 
people will just get a house in a different neighborhood if things 
become too stupid where they live.


Thx also for the follow-up on the code.  Too bad there is no easy fix 
outside of boot params.


-ml

PS: in 12.04, one of my MB NIC's came in as dev "virbr0"... perhaps 
"en[whatever]" is not so bad after all...



On 7/20/2016 8:00 PM, Xen wrote:

Markus Lankeit schreef op 20-07-2016 23:54:

Hi Xen,

Thanks for going to bat for us on this--sorry that no one wanted to
hear you.  Odd that a Debian dev would balk at this... Last I loaded
the latest Debian (about a month ago), I got the good-old "ethx"
interface names.  Hmm

Totally agree with your assessment that the argument "for" this new
naming scheme is ludicrous and illogical...  Thankfully, there is a
relatively simple way to disable this scheme (
http://askubuntu.com/questions/767786/changing-network-interfaces-name-ubuntu-16-04). 



Yes. But... I don't like changing boot parameters for this (it means 
the sanity of my system is now wholly dependent on my bootloader's 
configuration file, which is a dependency I do not want to have; any 
form of alternative booting of the kernel now *also* needs to 
reference those parameters for the system to keep functioning as 
normal (if it uses any firewall scripts or the like) which is 
something I don't want and don't want to invest in.


It should be purely based on on-disk structures that either just 
belong to /etc, (preferably) or get added to the initrd.


The udev rule is convenient enough except that udev is 
incomprehensible so the only way to manage this is to keep a notition 
of this in some convenient internet location of your own because 
invariably you are going to lose access to wherever you have stored 
it, and you can't memorize this or produce it from memory.


Meaning, unless you have some trustworthy access to this information 
you will not be able to reproduce it when you configure a new system 
and you will just forget and not care.


Which seems to be the intent of the designers: that it is so hard or 
inconvenient that most people just won't bother and use the default.


Hence, more people using what they want.

I believe the way to turn off the system is to do:

ln -s /dev/null /etc/udev/rules.d/70-persistent-net.rules

Which I did in the beginning but I can never remember the name.

At a certain point I fixed my static IP in a central dnsmasq config 
file so my static IPs are getting fixed through DHCP but before I 
definitely didn't have this facility and simply preferred to use 
/etc/network/interfaces which became hideous under this system.


I still don't like seeing this enp4s0 (under the previous motherboard 
it was enp3s0, go figure) whenever I look under the hood and detest it 
to the bone.


It is like calling a house in a street with no other houses, house 
number 2530.


2530 Empty Street.

Why 2530? Well, the hash of the number of bricks used to built the 
house was 2530, that's why.


Makes sense right. right. Maybe I will use this thread to find this 
information ;-).


Regards.



-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: The Simple Things in Life

[Xen]

Xen schreef op 21-07-2016 5:00:


I believe the way to turn off the system is to do:

ln -s /dev/null /etc/udev/rules.d/70-persistent-net.rules


It was  ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules.

But that doesn't work, it used to work somewhere at some point.

But no longer.

So I have no clue how to turn it off other than passing a kernel 
parameter.


Which I don't want.

I guess I need to start patching more software, or something

--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: The Simple Things in Life

[Xen]

Markus Lankeit schreef op 20-07-2016 23:54:

Hi Xen,

Thanks for going to bat for us on this--sorry that no one wanted to
hear you.  Odd that a Debian dev would balk at this... Last I loaded
the latest Debian (about a month ago), I got the good-old "ethx"
interface names.  Hmm

Totally agree with your assessment that the argument "for" this new
naming scheme is ludicrous and illogical...  Thankfully, there is a
relatively simple way to disable this scheme (
http://askubuntu.com/questions/767786/changing-network-interfaces-name-ubuntu-16-04).


Yes. But... I don't like changing boot parameters for this (it means the 
sanity of my system is now wholly dependent on my bootloader's 
configuration file, which is a dependency I do not want to have; any 
form of alternative booting of the kernel now *also* needs to reference 
those parameters for the system to keep functioning as normal (if it 
uses any firewall scripts or the like) which is something I don't want 
and don't want to invest in.


It should be purely based on on-disk structures that either just belong 
to /etc, (preferably) or get added to the initrd.


The udev rule is convenient enough except that udev is incomprehensible 
so the only way to manage this is to keep a notition of this in some 
convenient internet location of your own because invariably you are 
going to lose access to wherever you have stored it, and you can't 
memorize this or produce it from memory.


Meaning, unless you have some trustworthy access to this information you 
will not be able to reproduce it when you configure a new system and you 
will just forget and not care.


Which seems to be the intent of the designers: that it is so hard or 
inconvenient that most people just won't bother and use the default.


Hence, more people using what they want.

I believe the way to turn off the system is to do:

ln -s /dev/null /etc/udev/rules.d/70-persistent-net.rules

Which I did in the beginning but I can never remember the name.

At a certain point I fixed my static IP in a central dnsmasq config file 
so my static IPs are getting fixed through DHCP but before I definitely 
didn't have this facility and simply preferred to use 
/etc/network/interfaces which became hideous under this system.


I still don't like seeing this enp4s0 (under the previous motherboard it 
was enp3s0, go figure) whenever I look under the hood and detest it to 
the bone.


It is like calling a house in a street with no other houses, house 
number 2530.


2530 Empty Street.

Why 2530? Well, the hash of the number of bricks used to built the house 
was 2530, that's why.


Makes sense right. right. Maybe I will use this thread to find this 
information ;-).


Regards.

--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: The Simple Things in Life

[Markus Lankeit]

Hi Xen,

Thanks for going to bat for us on this--sorry that no one wanted to hear 
you.  Odd that a Debian dev would balk at this... Last I loaded the 
latest Debian (about a month ago), I got the good-old "ethx" interface 
names.  Hmm


Totally agree with your assessment that the argument "for" this new 
naming scheme is ludicrous and illogical...  Thankfully, there is a 
relatively simple way to disable this scheme ( 
http://askubuntu.com/questions/767786/changing-network-interfaces-name-ubuntu-16-04).


Thx.

-ml


On 7/20/2016 1:56 PM, Xen wrote:

Markus Lankeit schreef op 20-07-2016 0:01:


Also, the whole network device naming scheme is just a fiasco...
Before, I could have a simple template for all my systems... now every
system requires a unique template that takes me to the HW level to
figure out what it might be.  And this is supposed to be more
intuitive and/or predictable than "eth0"?


I've tried to make a point of this recently on the systemd-devel list 
but one of the Ubuntu (and Debian) devs (Martin Pitt) would have none 
of it and a kernel developer tried to show me off into the woods by 
coming up with thought experiments as to why any other solution would 
not be viable.


Basically I just think they have an agenda and won't admit to it.

Many illogical decisions become logical the moment you know the truth.

There are probably some business customers that need flawless device 
recognition while requiring absolute zero configuration from the 
viewpoint of the boot process.


Any other strategy would work, including condensing the detected 
hardware list for onboard/unpluggable devices only.


They tried to tell me that a Linux system was capable of recognising a 
hardware device that was present during boot only hours after the 
system was booted - theoretically - and that because of this a stable 
"condensation" into names such as ethernet0 would not be possible.


Ie. what if after 3 hours of using the system, a network card will 
suddenly pop up? What then of your numbering? Now you have to insert 
another card in the number and your numbers won't be right anymore.


That is the ludicrous argument to my counterargument that they gave me.

Ie. I believe the network card detection works by trying all drivers 
and seeing if they can find any card they can manage, this is a pretty 
deterministic process and will probably end pretty fast for any driver 
seeing how fast the system boots these days (particularly with SSD) 
and never has a problem. If any driver cannot find any hardware, it is 
removed from the list and never tried again.


So apparently (according to kernel documents I read online) this is a 
pretty bounded thing with a guaranteed endpoint depending on whether 
any drivers do anything really weird, which I think they don't.


However lacking my real knowledge of the thing they were able to 
pretty much shove me off into the woods as indicated or at least give 
other people the impression that I didn't know what I was talking about.


I suggested a condensation of network devices (based on the current 
scheme) into a fixed list of ethernet0, ethernet1 and so on, that 
would at once be different from the old default (the kernel names) and 
that would be executed moments prior to the activation of the 
networking system and that would fix the networking instability with 
about as much grace as the current system can foster.


Meaning, I just wanted to map the current names into fixed lists (of 
devices) but only for hardware-devices-present-at-boot (unpluggables) 
and using the current "BIOS" names as the foundation for that mapping 
(in terms of order) such that the order of those devices would never 
change as long as the mapping was done after all the devices had been 
found.


Which seems not impossible, but they told me it was.

Existing mapping (renaming) to kernel device names caused race 
conditions when done on the fly. Mapping to another fixed namespace 
can never cause race conditions. And if the condensation is done prior 
to networking being started, there can never be an issue because 
conceptually networking cannot start until all required devices have 
been found.


Ie. you cannot start some firewall if one of the required devices is 
missing.


It is a complete and conceptual end-point (target, as per systemd 
jargon) that network device recognition must have completed prior to 
doing anything with those devices; that logically the former phase 
must be completed before the next can start.


So how you can start networking while accepting as some kind of basic 
reality and possibility that 3 hours down the line, a required 
networking device will suddenly surface, is beyond me.


Yet this is what Martin Pitt and others told me.

Which to me feels like "find reasons to not have to do this thing, 
quick".


"Give him the wrong directions, quick".

"Don't let anyone think his idea is actually capable of having life, 
quick".


:-/.

What else can I make of 

Re: The Simple Things in Life

[Xen]

Markus Lankeit schreef op 20-07-2016 0:01:


Also, the whole network device naming scheme is just a fiasco...
Before, I could have a simple template for all my systems... now every
system requires a unique template that takes me to the HW level to
figure out what it might be.  And this is supposed to be more
intuitive and/or predictable than "eth0"?


I've tried to make a point of this recently on the systemd-devel list 
but one of the Ubuntu (and Debian) devs (Martin Pitt) would have none of 
it and a kernel developer tried to show me off into the woods by coming 
up with thought experiments as to why any other solution would not be 
viable.


Basically I just think they have an agenda and won't admit to it.

Many illogical decisions become logical the moment you know the truth.

There are probably some business customers that need flawless device 
recognition while requiring absolute zero configuration from the 
viewpoint of the boot process.


Any other strategy would work, including condensing the detected 
hardware list for onboard/unpluggable devices only.


They tried to tell me that a Linux system was capable of recognising a 
hardware device that was present during boot only hours after the system 
was booted - theoretically - and that because of this a stable 
"condensation" into names such as ethernet0 would not be possible.


Ie. what if after 3 hours of using the system, a network card will 
suddenly pop up? What then of your numbering? Now you have to insert 
another card in the number and your numbers won't be right anymore.


That is the ludicrous argument to my counterargument that they gave me.

Ie. I believe the network card detection works by trying all drivers and 
seeing if they can find any card they can manage, this is a pretty 
deterministic process and will probably end pretty fast for any driver 
seeing how fast the system boots these days (particularly with SSD) and 
never has a problem. If any driver cannot find any hardware, it is 
removed from the list and never tried again.


So apparently (according to kernel documents I read online) this is a 
pretty bounded thing with a guaranteed endpoint depending on whether any 
drivers do anything really weird, which I think they don't.


However lacking my real knowledge of the thing they were able to pretty 
much shove me off into the woods as indicated or at least give other 
people the impression that I didn't know what I was talking about.


I suggested a condensation of network devices (based on the current 
scheme) into a fixed list of ethernet0, ethernet1 and so on, that would 
at once be different from the old default (the kernel names) and that 
would be executed moments prior to the activation of the networking 
system and that would fix the networking instability with about as much 
grace as the current system can foster.


Meaning, I just wanted to map the current names into fixed lists (of 
devices) but only for hardware-devices-present-at-boot (unpluggables) 
and using the current "BIOS" names as the foundation for that mapping 
(in terms of order) such that the order of those devices would never 
change as long as the mapping was done after all the devices had been 
found.


Which seems not impossible, but they told me it was.

Existing mapping (renaming) to kernel device names caused race 
conditions when done on the fly. Mapping to another fixed namespace can 
never cause race conditions. And if the condensation is done prior to 
networking being started, there can never be an issue because 
conceptually networking cannot start until all required devices have 
been found.


Ie. you cannot start some firewall if one of the required devices is 
missing.


It is a complete and conceptual end-point (target, as per systemd 
jargon) that network device recognition must have completed prior to 
doing anything with those devices; that logically the former phase must 
be completed before the next can start.


So how you can start networking while accepting as some kind of basic 
reality and possibility that 3 hours down the line, a required 
networking device will suddenly surface, is beyond me.


Yet this is what Martin Pitt and others told me.

Which to me feels like "find reasons to not have to do this thing, 
quick".


"Give him the wrong directions, quick".

"Don't let anyone think his idea is actually capable of having life, 
quick".


:-/.

What else can I make of it.

Sorry for not writing all that well. Regards.

--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: The Simple Things in Life

[John Moser]

On Tue, 2016-07-19 at 15:01 -0700, Markus Lankeit wrote:
> Adding my $0.02...
> 
> If you pick "samba file server" during install, libnss-winbind
> libpam-winbind are not installed by default.  It took me a long to
> time to track down why in 16.04 I can "join" an AD domain just fine,
> but domain users get "access denied" to samba file shares.  Not sure
> the logic behind not installing relevant packages...
> 
To be fair, configuring Samba is non-trivial, and I often think joining
a domain as a member rather than a domain controller is some incidental
feature that's a prerequisite for being a domain controller.  Samba
doesn't seem to support being a domain member very well at all, to the
point that searching on errors and asking Google how to get a Samba
domain member to authenticate to a different domain controller (because
you joined on a RWDC network and now need to authenticate against a
RODC) brings up documentation on configuring Samba as a domain
controller.
I configure Samba all the time; I have no idea how it works, and when
it breaks I'm lost.  To put this into perspective, I know how
*everything* works, and when it breaks I can project the entire
configuration and behavior and identify something I probably should
have seen before--something unfamiliar, which I haven't inspected, but
which I was able to assembly by simply throwing the state together in
my head and making myself aware that some problem exists somewhere.  I
have NO IDEA why my Linux servers can authenticate to Active Directory;
I just know I did things to PAM and nsswitch.conf and repeatedly ran a
dozen forms of net join until, despite consistently throwing errors and
failing, the server magically started authenticating.
More basically, Samba can be a Samba file server without joining an AD
domain.
> Also, the whole network device naming scheme is just a fiasco...
>   Before, I could have a simple template for all my systems... now
>   every system requires a unique template that takes me to the HW
>   level to figure out what it might be.  And this is supposed to be
>   more intuitive and/or predictable than "eth0"? 
> 
>   
> 
>   Thx.
> 
>   
> 
>   -ml
> 
> 
> 
> > On 7/19/2016 2:48 PM, John Moser wrote:
> 
> 
> 
> > > 
> >   > > On Tue, 2016-07-19 at 14:29 -0700, Jason Benjamin wrote:
> > 
> >   > > > 
> > > > > > I've
> > >   been irritated by so many obvious shortcomings of Ubuntu this
> > >   version (16.04).  So many of the most obvious fixes are easily
> > >   attributed to configuration files.  I don't know if those who
> > >   purchase the operating system directly from Canonical versus a
> > >   download are having to deal with the same problems or are
> > >   getting a supe> > > rior/better operating system.
> > >  operating system.
> > >    Some of  my main qualms that I am unable to deal with are the
> > >   theming.  Even using alternative themes most of them won't
> > >   even look right as supposed.  
> > > 
> > > > > > The
> > >   HIBERNATION itself seems to work fine on other closely related
> > >   distros (Elementary OS I tested).  but Ubuntu has problems
> > >   with it.  AFAIK the GRUB_CMDLINE breaks this if anything, and
> > >   alternatives such as TuxOnIce don't work either.  My guess is
> > >   that its Plymouth and there doesn't seem to be any clear
> > >   pointers to a solution.  After desktop session saving was
> > >   deprecated (or removed because of transition from Gnome?),
> > >   this seems like a serious and necessary *implementation* of
> > >   desktop application saving.  
> > > 
> > > > > > I've
> > >   seen a lot of these blogs that suggest installing extra
> > >   programs and such after the installation.  Here's mine:
> > > 
> > >   
> > 
> >   
> > 
> >   
> > 
> >   > > You just listed a bunch of odd things about hiding the boot
> > process.
> > 
> >   
> > 
> >   
> > 
> >   > > I've been repeatedly distressed and confused by this hidden
> > boot process.  I've sat and waited at blank screens and splashes
> > that give no feedback, wondering if the kernel is hanging at
> > initializing a driver, trying to find network, or making
> > decisions about a disk.  There is no standard flow which can be
> > disrupted with a new, non-error status message curtly explaining
> > that something is happening and all is well; there is a standard
> > flow in which the machine displays a blank, meaningless state
> > for a fixed amount of time, and deviation in that time by any
> > more than a few tenths of a second gives the immediate,
> > gut-wrenching feeling that the system has hanged during boot and
> > is terminally broken in some 

Re: The Simple Things in Life

[Nish Aravamudan]

On 19.07.2016 [15:01:46 -0700], Markus Lankeit wrote:
> Adding my $0.02...
> 
> If you pick "samba file server" during install, libnss-winbind
> libpam-winbind are not installed by default.  It took me a long to time to
> track down why in 16.04 I can "join" an AD domain just fine, but domain
> users get "access denied" to samba file shares. Not sure the logic behind
> not installing relevant packages...

Thanks for bringing this up -- I think this is due to libpam-smbpass
being removed/deprecated and being replaced with libpam-winbind. I will
file a post-release FFe bug (unless you've already filed a bug?) to
change the seed for xenial, we'll see what happens.  I've already
updated the 16.10 seeds to install libpam-winbind.

Note that earlier Ubuntu releases did not require (I'm guessing?)
libnss-winbind (libpam-winbind suggests it, but doesn't require it). In
your environment, is it strictly necessary in order to join the AD
domain?

Thanks,
Nish
-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: The Simple Things in Life

[Markus Lankeit]

Adding my $0.02...

If you pick "samba file server" during install, libnss-winbind 
libpam-winbind are not installed by default.  It took me a long to time 
to track down why in 16.04 I can "join" an AD domain just fine, but 
domain users get "access denied" to samba file shares. Not sure the 
logic behind not installing relevant packages...


Also, the whole network device naming scheme is just a fiasco... Before, 
I could have a simple template for all my systems... now every system 
requires a unique template that takes me to the HW level to figure out 
what it might be.  And this is supposed to be more intuitive and/or 
predictable than "eth0"?


Thx.

-ml

On 7/19/2016 2:48 PM, John Moser wrote:

On Tue, 2016-07-19 at 14:29 -0700, Jason Benjamin wrote:


I've been irritated by so many obvious shortcomings of Ubuntu this 
version (16.04).  So many of the most obvious fixes are easily 
attributed to configuration files.  I don't know if those who 
purchase the operating system directly from Canonical versus a 
download are having to deal with the same problems or are getting a 
*supe**rior*//better/ operating system.  Some of  my main qualms that 
I am unable to deal with are the theming.  Even using alternative 
themes most of them won't even look right as supposed.


The HIBERNATION itself seems to work fine on other closely related 
distros (Elementary OS I tested).  but Ubuntu has problems with it. 
 AFAIK the GRUB_CMDLINE breaks this if anything, and alternatives 
such as TuxOnIce don't work either.  My guess is that its Plymouth 
and there doesn't seem to be any clear pointers to a solution.  After 
desktop session saving was deprecated (or removed because of 
transition from Gnome?), this seems like a serious and necessary 
*implementation* of desktop application saving.


I've seen a lot of these blogs that suggest installing extra programs 
and such after the installation.  Here's mine:




You just listed a bunch of odd things about hiding the boot process.

I've been repeatedly distressed and confused by this hidden boot 
process.  I've sat and waited at blank screens and splashes that give 
no feedback, wondering if the kernel is hanging at initializing a 
driver, trying to find network, or making decisions about a disk. 
 There is no standard flow which can be disrupted with a new, 
non-error status message curtly explaining that something is happening 
and all is well; there is a standard flow in which the machine 
displays a blank, meaningless state for a fixed amount of time, and 
deviation in that time by any more than a few tenths of a second gives 
the immediate, gut-wrenching feeling that the system has hanged during 
boot and is terminally broken in some mysterious and 
completely-unknown manner.


What Ubuntu needs most is a simple, non-buried toggle option to show 
the boot process--including displaying the bootloader, displaying the 
kernel load messages, and listing which services are loading and 
already-loaded during the graphical boot.  Ubuntu's best current 
feature is the Recovery boot mode, aside from not having a setting to 
make this the standard boot mode sans the recovery prompt.  "Blindside 
the user with a confusing and meaningless boot process and terror at a 
slight lag in boot time because the system may be broken" is not a 
good policy for boot times longer than 1 second.


Even Android displays a count of system assemblies AOT cached during 
boots after update so as to convey to the user that something is 
indeed happening.





-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: The Simple Things in Life

[Xen]

John Moser schreef op 19-07-2016 23:48:


What Ubuntu needs most is a simple, non-buried toggle option to show
the boot process--including displaying the bootloader, displaying the
kernel load messages, and listing which services are loading and
already-loaded during the graphical boot.  Ubuntu's best current
feature is the Recovery boot mode, aside from not having a setting to
make this the standard boot mode sans the recovery prompt.  "Blindside
the user with a confusing and meaningless boot process and terror at a
slight lag in boot time because the system may be broken" is not a
good policy for boot times longer than 1 second.


It's really quite obvious isn't it. But you don't need to see 
everything.


See currently it is either all or nothing and that is how many people 
seem to think.


Either you see a splash screen with no information at all (save perhaps 
an encryption message or a leaked-through kernel command line bug or 
error during the boot process) or you see all of the systemd services 
starting and perhaps much more information as well.


Why not divide the boot process in 5 or 6 stages and then show the user 
when each stage has been completed? SystemD already has stages (targets) 
but it was not really meant for humans.


I mean how obvious is it that "one state" (such as the desktop being 
loaded) is not informative enough, while "1000 states" may be much too 
informative?


When do people learn to find the middle road?

--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: The Simple Things in Life

[John Moser]

On Tue, 2016-07-19 at 14:29 -0700, Jason Benjamin wrote:
> I've been irritated by so many obvious shortcomings of Ubuntu this
> version (16.04).  So many of the most obvious fixes are easily
> attributed to configuration files.  I don't know if those who
> purchase the operating system directly from Canonical versus a
> download are having to deal with the same problems or are getting a
> superior/better operating system.  Some of  my main qualms that I am
> unable to deal with are the theming.  Even using alternative themes
> most of them won't even look right as supposed.  
> The HIBERNATION itself seems to work fine on other closely related
> distros (Elementary OS I tested).  but Ubuntu has problems with it.
>  AFAIK the GRUB_CMDLINE breaks this if anything, and alternatives
> such as TuxOnIce don't work either.  My guess is that its Plymouth
> and there doesn't seem to be any clear pointers to a solution.  After
> desktop session saving was deprecated (or removed because of
> transition from Gnome?), this seems like a serious and necessary
> *implementation* of desktop application saving.  
> I've seen a lot of these blogs that suggest installing extra programs
> and such after the installation.  Here's mine:
You just listed a bunch of odd things about hiding the boot process.
I've been repeatedly distressed and confused by this hidden boot
process.  I've sat and waited at blank screens and splashes that give
no feedback, wondering if the kernel is hanging at initializing a
driver, trying to find network, or making decisions about a disk.
 There is no standard flow which can be disrupted with a new, non-error 
status message curtly explaining that something is happening and all is
well; there is a standard flow in which the machine displays a blank,
meaningless state for a fixed amount of time, and deviation in that
time by any more than a few tenths of a second gives the immediate,
gut-wrenching feeling that the system has hanged during boot and is
terminally broken in some mysterious and completely-unknown manner.
What Ubuntu needs most is a simple, non-buried toggle option to show
the boot process--including displaying the bootloader, displaying the
kernel load messages, and listing which services are loading and
already-loaded during the graphical boot.  Ubuntu's best current
feature is the Recovery boot mode, aside from not having a setting to
make this the standard boot mode sans the recovery prompt.  "Blindside
the user with a confusing and meaningless boot process and terror at a
slight lag in boot time because the system may be broken" is not a good
policy for boot times longer than 1 second.
Even Android displays a count of system assemblies AOT cached during
boots after update so as to convey to the user that something is indeed
happening.-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

The Simple Things in Life

[Jason Benjamin]

I've been irritated by so many obvious shortcomings of Ubuntu this 
version (16.04).  So many of the most obvious fixes are easily 
attributed to configuration files.  I don't know if those who purchase 
the operating system directly from Canonical versus a download are 
having to deal with the same problems or are getting a superior/better 
operating system.  Some of  my main qualms that I am unable to deal 
with are the theming.  Even using alternative themes most of them won't 
even look right as supposed.


The HIBERNATION itself seems to work fine on other closely related 
distros (Elementary OS I tested).  but Ubuntu has problems with it.  
AFAIK the GRUB_CMDLINE breaks this if anything, and alternatives such 
as TuxOnIce don't work either.  My guess is that its Plymouth and there 
doesn't seem to be any clear pointers to a solution.  After desktop 
session saving was deprecated (or removed because of transition from 
Gnome?), this seems like a serious and necessary *implementation* of 
desktop application saving.


I've seen a lot of these blogs that suggest installing extra programs 
and such after the installation.  Here's mine:




Top real things to do after

installing Ubuntu 16.04 LTS:



Fix splash at boot up

while root create file /etc/initramfs-tools/conf.d/splash and add the 
line: FRAMEBUFFER=y


then run sudo update-initramfs -u [-k all]

“-k all” refers to checking all graphics cards

Alternative recourse if the previous splash fix doesn’t cover 
everything


Comment out GRUB_HIDDEN_TIMEOUT and GRUB_HIDDEN_TIMEOUT_QUIET lines 
(both deprecated)


uncomment GRUB_TIMEOUT (preferably set to 0) and add 
‘GRUB_TIMEOUT_STYLE=hidden’


add boot option ‘fastboot’ to /etc/default/grub (to hide file 
system clean message at boot)


add ‘GRUB_GFXPAYLOAD_LINUX=keep’ to same file

run sudo update-grub

Disable upstart entry in grub menu

as root edit /etc/grub.d/10_linux and find line SUPPORTED_INITS and 
remove the option ‘upstart:/sbin/upstart’


run sudo update-grub

Remove Guest account from login

create new file /etc/lightdm/lightdm.conf and add following lines:

[SeatDefaults]

greeter-session=unity-greeter

user-session=ubuntu

allow-guest=false



Fix event sounds

for startup open startup applications and add “canberra-gtk-play -i 
desktop-login &”


as root in /etc/lightdm/lightdm.conf add the line: 
“session-cleanup-script=/usr/share/gnome/shutdown/libcanberra-logout-sound.sh”


Enable hibernate

First make sure your swap partition is large enough

the kernel that comes with Ubuntu is behind and has a bug that causes 
hibernate to crash when in practical situations


go to http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4.8-wily

download and install kernel headers and image

remove any older kernel packages

run sudo blkid and determine swap UUID

ensure UUID is the same in /etc/initramfs-tools/conf.d/resume

add the same line to /etc/default/grub at the end of 
GRUB_CMDLINE_LINUX_DEFAULT or to GRUB_CMDLINE_LINUX


run sudo update-grub and sudo update-initramfs -u

while root create 
/var/lib/polkit-1/localauthority/50-local.d/com.ubuntu.enable-hibernate.pkla 
and add following lines:


[Re-enable hibernate by default in upower]

Identity=unix-user:*

Action=org.freedesktop.upower.hibernate

ResultActive=yes


[Re-enable hibernate by default in logind]

Identity=unix-user:*

Action=org.freedesktop.login1.hibernate;org.freedesktop.login1.hibernate-multiple-sessions

ResultActive=yes



As root edit /usr/share/X11/xkb/symbols/inet and change XF86Hibernate 
key to  and comment out XF86Suspend line


run sudo dpkg-reconfigure xkb-data

*optional: edit /etc/systemd/logind.conf

find line “#HandleLidSwitch=suspend” and uncomment

change suspend to hibernate

Fix scaling to remove distortions

use dconf or gsettings

change /com/canonical/unity/interface/text-scale-factor to 0.95

change /org/gnome/desktop/interface/text-scaling-factor to 0.95

change /org/gnome/desktop/interface/document-font-name to Sans 12

change /org/gnome/desktop/interface/font-name to Ubuntu 12

*optional: install Unity Tweak

sudo apt install unity-tweak-tool
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss