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/
_______________________________________________
Grub-devel mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/grub-devel