Re: A black window pop out after I select a boot entry in grub2

[Xen <xen@dds.nl>]

Andrei Borzenkov schreef op 10-08-2016 16:17:

> This is terminal window (same you get when entering CLI) where
> messages from commands are displayed (do not forget that menu entry is
> simply list of commands, so you *are* entering CLI in a sense). There
> is no way to disable it. Several years ago openSUSE tried to make it
> transparent, effectively hiding it; patch was dropped although I'm
> still not sure if this was some fundamental grub problem or simply
> unfortunate theme design.

Is this simply about the regular (Linux) terminal output that is getting 
hidden by plymouth (usually)?

Personally at this point I am just worried about disabling any kernel 
messages before Plymouth can hide it.

There are always a few messages that make it through in the beginning; 
usually some ATA soft reset or some PowerNow thing that doesn't work or 
something of the kind. This kinda pollutes the display when it was not 
really intended.

Given my current level of expertise I would probably just patch the 
kernel to make it easier, but then you have to deal with the whole 
ordeal of kernel upgrades.

They haven't (on Ubuntu/Kubuntu at least) managed to make it hidden, and 
if you install the nVidia driver which has no framebuffer driver, 
textual messages continually leak through the displayed text progress 
bar.

It kinda suprises me seeing the number of patches to grub that they've 
made to make the boot experience more seemless.

You can't usually read boot messages fast enough and if systemd doesn't 
make it to the "dumping everything in /var now" stage you are pretty 
much screwed in diagnosing your system.

So the value of boot messages is rather limited, even when designing my 
own systemd service to do anything I consistently have to look at 
journalctl output, the boot output is too fast for me even when I know 
what to expect, and *even* when I incur a 10 second pause.

Usually when something gets stuck it doesn't just get stuck, but systemd 
messages keep being repeated quickly clearing the previous log off 
screen.

I question the validity of having on-screen boot messages these days; 
certainly in the number and speed they flow over the screen.

If there were options for interrupting the thing using regular keys or 
being shown less but being able to expand it, it would be different.

I think showing the start of SystemD (or the end of initrd) would be a 
good thing. Most people not involved with Linux will have no clue about 
these different phases. I think it would be helpful if people could 
grasp if there were two stages (or actually perhaps, three).

Something like

Loading pre-boot environment.
Loading device drivers.
Handing control over to the system.



Or an expansion of that in the sense of:

Loading boot environment.
Loading device drivers.
Unlocking encrypted system drive.
Checking main volume for errors.
Connecting main volume.
Transferring control to main system.

The issue is that "root filesystem" is not a concept people can 
understand. It also makes it so troublesome to diagnose or fix root 
filesystem problems because you cannot get there very easily (you need a 
separate system).

To make the thing more user friendly (and therefore user-powerful) you 
would need to have at least the following:

- the ability to boot into a functional initrd environment that is not 
as alienating (there are only a few concepts that are important)
- the ability to enter this environment by shutting down your system 
(upon shutting down your system)
- an awareness that this "filesystem" you will see is not the same as 
your actual computer system
- ideally the ability to return to your main system after exiting the 
initrd environment, even if that means rebooting it from the environment 
(not sure if that would not complicate things further).

There are basically only 2 concepts in the initrd environment:

- loading and finding and unlocking your root filesystem
- passing control over to the installed system.

This would imply only a number of meaningful tasks:

- crypt unlocking
- raid assembling
- device enumeration
- filesystem mounting
- and/or passing control to a system that may not even have been mounted 
yet.

Such a system could be like the debian text mode installers.

It deals with the same concepts as the installation.

People don't understand "mounting" something. They also don't understand 
"root" filesystem. To make it meaningful "root" would have to be 
identified as a device. Windows (and DOS) did that by using drive 
letters. You were allowed to have many different roots, each pertaining 
to a device. These days you can also mount stuff in a Windows tree just 
fine.

So the only conceptual difference between Linux and Windows is that 
Linux has one tree and Windows just has many. There is no other 
difference here.

Linux is a single tree and Windows is a forest of up to 26 trees.

Identification of devices and where they connect is usually most 
important.

My real suggestion is honestly just to use drive letters or something 
that can simulate it; or to use other kinds of markings, or a new 
concept of namespaces that actually has meaning to people(?).

I know there are kernel namespaces but I still don't know what they mean 
(mount namespaces) and why they are important.

What you need to be user friendly is to give devices a name and to 
access them using that name as a form of namespace in which those names 
become primary access tokens.

Meaning any system that uses (flat) labels or even 'namespaced' labels 
(such as "nas:media" or "remote:backup") would fit the bill here.

In theory a Windows system is just:

root -- A:
      -- B:
      -- C:

The different trees are just aggregated under a root that is never 
mentioned and never used for access.

If you could employ the mentioned namespace-labels as user-centric 
access tokens that are recognised on the level of the kernel,

With a format such as:

/:root    (non-namespaced root label)
/this:root     (namespaced root label)

/this:root/etc   (directory on namespaced root label)

:root/etc   (not using absolute addressing)

nas:media/...  (not using absolute addressing)

You would have an easy to implement system really in which the only 
issues is : being an allowed character in filenames that mess with the 
functioning of certain tools (tar, rsync, scp).

In which the character actually serves the same purpose.

Under these conditions absolute targetting would be required to ensure 
that namespaces are not getting used (or labels) are not getting used by 
unpacking some tar archive that contains such filenames; and hence could 
be used to overwrite stuff that should not be targetted in that way.

Ie. you unpack some filename "here:root" that is a directory and 
suddenly the contents of that directory are written to the root 
filesystem.

Other than these issues there really aren't any other than the fact that 
for it to be really useful a check against these names has to be made
for every root (/) entry lookup and every AT_CWD lookup, possibly 
slowing down lookups slightly, while not being allowed for these lookups 
to make it to any dentry cache.

If you could alleviate the problems you would have a system that could 
at least be used quite proficiently as a kind of "toy" system (ie. 
consumer desktops) even if you wouldn't want that for a long time for 
harsher environments (servers).

The whole thing is only meant for user convenience, after all.

You would be able to integrate the various desktop environments in 
having the same "Places" infrastructure down below. No tools would need 
to be adjusted in order to use the system other than that "label" aware 
programs (I originally just called this Magical Symlinks :p) would want 
to prefix / internally (to make them absolute references) as well as 
shells as long as : remains a valid character in e.g. tar archives. Of 
course the : already creates problems on Windows systems. AT_CWD lookups 
should only be allowed for interactive use. And root entries should 
never contain a : (on the actual filesystem).

Given these constraints you could have something like this working in 
no-time if you had the skills ;-).

It's just that interactive tools would need to prefix / internally given 
that AT_CWD lookups like that can't really be allowed.

So the only constraints are:

- root entries cannot have : in them
- interactive tools must know about it (if safety is a concern)
- only absolute lookups using the /:name or /name:share syntax could 
ordinarily be allowed

The "here" namespace could reference filesystem labels on local disks.

If you labeled your filesystems "root" and "var" and "tmp" you would 
have here:root, here:var and here:tmp.

Servers could have their own namespaces with shares, such as nas:media, 
nas:backup, nas:home.

Such a namespace could even be tied to autofs (if it works, it doesn't 
always work for me).

The way it is these namespaces would do nothing other than references 
mounted locations on the local filesystem hierarchy.

But what they would provide would be a flat namespace and a namespaced 
(yes, confusing) namespace ;-) in which certain locations would become 
easier to access such as:

:media will refer to /media/<user> for the current user.

:home will be a bit easier to type than $HOME or ~ on many keyboard, AND 
it would work from graphical programs.

A program such as CloneZilla could use :partimag instead of abusing 
/home/partimag for that.

"m" could be a namespace referring to all mounted devices under :media, 
such as that m:<tab> would show a list of such devices.

So you might have your Kingston USB stick under m:KINGSTON/....

As well as, I guess, :media/KINGSTON/....

Or :m/<tab> would do the same.

Anyway.

It would all be faily easy to implement by having "real" symlinks under 
/proc/sys somewhere that are getting managed by a userspace tool or 
daemon and lookups for namespace:share or namespace:device would simply 
resolve to such a directory symlink in the same way that regular 
symlinks as a path component get "expanded" until the full path is 
found.

It would simply expand into a path that references /proc/sys/share or 
/proc/sys/name or something of the kind.

This in turn would be a symlink that gets resolved to the actual path. 
Such that e.g.

/proc/sys/share/main/root  would be a symlink pointing to / and 
resolving for :root.

/proc/sys/share/nas/media would be a symlink pointing to whatever and 
resolving for nas:root/

Or simply /proc/share.

I don't like /sys.

So the magical symlink implementation will simply catch the lookup being 
done, check for a : in it, only do it for / lookups when needed, prevent 
these lookups from being cached (they are in-memory anyway) perform a 
substitution in the path or return it as a "magical symlink" (my 
preference) that points to /proc, and let the system handle the rest.

There will simply be 2 symlink resolution steps for every lookup using 
that/those names.

The internal table is maintained by a module that updates /proc when 
accessed through the "management interface" and just serves these 
lookups in the meantime.

Well, enough, I guess.

I just think that would go a long way to making the system more 
comprehensible to an ordinary person. Another namespace could be

disk:

That would display all disk devices or part: that would display all 
partitions. You can go as crazy as you want.

Instead of /dev/sda you would use disk:sda or even disk:a

There is no interface where partitions are subdirectories of disks? 
There is no /dev/disk/sda/1/