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

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

[Huangwei Fang]

Hi everyone,

When I boot a system, system takes me to the grub screen to select a 
boot entry. After I choose a boot entry, a black window pops out within 
the colorful grub screen. In that window, it prints out the "Loading" 
boot archive message and the progress. That black window gives the bad 
visual part of booting a system. I was wondering how can I disable this 
black window pop out. Does anyone know how to do it or can provide any 
help? Thanks in advance.

Best,

Henry

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

[Andrei Borzenkov]

On Tue, Aug 9, 2016 at 12:29 AM, Huangwei Fang <henry.fang@oracle.com> wrote:
> Hi everyone,
>
> When I boot a system, system takes me to the grub screen to select a boot
> entry. After I choose a boot entry, a black window pops out within the
> colorful grub screen. In that window, it prints out the "Loading" boot
> archive message and the progress. That black window gives the bad visual
> part of booting a system. I was wondering how can I disable this black
> window pop out. Does anyone know how to do it or can provide any help?

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.

If you are interested you could try it if it works for you.

While completely removing it may be technically possible (do not open
terminal window and add dummy output that does nothing) I'm not sure
it is good idea. You want to see errors if booting fails. Actually you
want to see where you are stuck as well - so I'd rather add more
output (like marking end of initrd loading).

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

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]

If no command outputs anything, terminal does not appear, so check that no
output guess to terminal.

Le mer. 10 août 2016 16:23, Andrei Borzenkov <arvidjaar@gmail.com> a écrit :

> On Tue, Aug 9, 2016 at 12:29 AM, Huangwei Fang <henry.fang@oracle.com>
> wrote:
> > Hi everyone,
> >
> > When I boot a system, system takes me to the grub screen to select a boot
> > entry. After I choose a boot entry, a black window pops out within the
> > colorful grub screen. In that window, it prints out the "Loading" boot
> > archive message and the progress. That black window gives the bad visual
> > part of booting a system. I was wondering how can I disable this black
> > window pop out. Does anyone know how to do it or can provide any help?
>
> 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.
>
> If you are interested you could try it if it works for you.
>
> While completely removing it may be technically possible (do not open
> terminal window and add dummy output that does nothing) I'm not sure
> it is good idea. You want to see errors if booting fails. Actually you
> want to see where you are stuck as well - so I'd rather add more
> output (like marking end of initrd loading).
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 2332 bytes --]

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

[Xen]

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/

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

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 12578 bytes --]

It's not about kernel but GRUB messages

Le mer. 10 août 2016 19:57, Xen <xen@dds.nl> a écrit :

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

[-- Attachment #2: Type: text/html, Size: 13982 bytes --]

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

[Xen]

Xen schreef op 10-08-2016 19:57:

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

Once you had a consistent interface to reference such "names" it would 
become easier to make the jump to a user-friendly operating system in 
terms of any pre-boot environment, is all I am saying.

disk:<tab> to see all the disk drives would be very easy to teach 
people.

disk:a:1 as a reference to the first partition on the first disk?

It wouldn't be a directory, it would be a device node.

At the same time it could allow the initrd root filesystem and the 
target root filesystem to be referenced by different names.

Just an idea, I don't say it would be elegant right from the start.

But it would be a user-centric way of approaching things. These days 
people use "root symlinks" (e.g. ln -s /sys/kernel/debug /debug) for 
these things. That's not a proper use of the root directory. It should 
be tidy, not littered with symlinks and other stuff you can't find a 
place for. I think the current wax in the expansion of the root 
filesystem (root directory) entries is alarming.

/sys was recently added, /srv, /snap, /run, and your particular brand 
may have more. On a 64-bit system you have at least three /lib versions. 
It is getting out of hand.

It is not something you can really navigate in a GUI.

MacOS solves it by not going there anyway. You can do the same. For a 
proper GUI proper display of those "labels" would be most convenient I 
think.

In the pre-boot rescue environment you could consider mounting disks and 
partitions under consistent and predictable locations as well as being 
accessed by e.g. "target:/" or ":target/".

The current location could then be "rescue:/" as the actual path that 
you are at.

"mount disk:a:1 target:" could then be even nomenclature for mounting 
that partition under that name. The real mount point would then be 
/mounts/target or /mnt/target. disk:a:1 would just point to 
/dev/disk/a/1 or something of the kind.

What you get is a prefix in path names that will hopefully alleviate 
some confusion even as it could add more if not properly done.

Honestly I still think those drive letters were best although there is 
no way to enumerate them.

But adding labels and namespaced labels is a possibility. Coupled with a 
structured way of mounting things you could at least use them as 
shortcuts for getting there.

Regards.

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

[Xen]

Vladimir 'phcoder' Serbinenko schreef op 10-08-2016 20:02:

> It's not about kernel but GRUB messages

Right. Apologies then ;-).

Maybe if someone is not booting from a prompt or edited menu entry those 
messages should not be displayed.

"Booting command list" after all seems to be quite incomprehensible.

Well unless you are a Grub developer perhaps.

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

[Huangwei Fang]

[-- Attachment #1: Type: text/plain, Size: 2323 bytes --]

Hi Andrei,

Thanks for your response for my question. I would like to ask where to find
patch that you mentioned in your reply. Also, I commented out all possible
outputs to terminal, but I still see an empty black window popping out.
Could you give me any idea about where to do not open terminal window in
source code? Thank you very much.

Thanks,
Henry Fang


---------- Forwarded message ----------
From: Mat Troi <mattroisang@gmail.com>
Date: Mon, Aug 22, 2016 at 5:37 PM
Subject: Fwd: A black window pop out after I select a boot entry in grub2
To: Fanghuangwei@gmail.com




---------- Forwarded message ----------
From: *Andrei Borzenkov* <arvidjaar@gmail.com>
Date: Wednesday, August 10, 2016
Subject: A black window pop out after I select a boot entry in grub2
To: The development of GNU GRUB <grub-devel@gnu.org>


On Tue, Aug 9, 2016 at 12:29 AM, Huangwei Fang <henry.fang@oracle.com>
wrote:
> Hi everyone,
>
> When I boot a system, system takes me to the grub screen to select a boot
> entry. After I choose a boot entry, a black window pops out within the
> colorful grub screen. In that window, it prints out the "Loading" boot
> archive message and the progress. That black window gives the bad visual
> part of booting a system. I was wondering how can I disable this black
> window pop out. Does anyone know how to do it or can provide any help?

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.

If you are interested you could try it if it works for you.

While completely removing it may be technically possible (do not open
terminal window and add dummy output that does nothing) I'm not sure
it is good idea. You want to see errors if booting fails. Actually you
want to see where you are stuck as well - so I'd rather add more
output (like marking end of initrd loading).

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

[-- Attachment #2: Type: text/html, Size: 3367 bytes --]

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

[Huangwei Fang]

[-- Attachment #1: Type: text/plain, Size: 2502 bytes --]

Hi Serbinenko,

Thanks for your answer to my question. I did delete all outputs to the
terminal window. However, I still see an empty black window popping out.
Could you give me any idea about it? Thanks.

Thanks,
Henry Fang


---------- Forwarded message ----------
From: Mat Troi <mattroisang@gmail.com>
Date: Mon, Aug 22, 2016 at 5:38 PM
Subject: Fwd: A black window pop out after I select a boot entry in grub2
To: Fanghuangwei@gmail.com




---------- Forwarded message ----------
From: *Vladimir 'phcoder' Serbinenko* <phcoder@gmail.com>
Date: Wednesday, August 10, 2016
Subject: A black window pop out after I select a boot entry in grub2
To: The development of GNU GRUB <grub-devel@gnu.org>


If no command outputs anything, terminal does not appear, so check that no
output guess to terminal.

Le mer. 10 août 2016 16:23, Andrei Borzenkov <arvidjaar@gmail.com> a écrit :

> On Tue, Aug 9, 2016 at 12:29 AM, Huangwei Fang <henry.fang@oracle.com>
> wrote:
> > Hi everyone,
> >
> > When I boot a system, system takes me to the grub screen to select a boot
> > entry. After I choose a boot entry, a black window pops out within the
> > colorful grub screen. In that window, it prints out the "Loading" boot
> > archive message and the progress. That black window gives the bad visual
> > part of booting a system. I was wondering how can I disable this black
> > window pop out. Does anyone know how to do it or can provide any help?
>
> 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.
>
> If you are interested you could try it if it works for you.
>
> While completely removing it may be technically possible (do not open
> terminal window and add dummy output that does nothing) I'm not sure
> it is good idea. You want to see errors if booting fails. Actually you
> want to see where you are stuck as well - so I'd rather add more
> output (like marking end of initrd loading).
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 3679 bytes --]

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

[Andrei Borzenkov]

23.08.2016 03:44, Huangwei Fang пишет:
> Hi Andrei,
> 
> Thanks for your response for my question. I would like to ask where to find
> patch that you mentioned in your reply.

It was long ago and I'm not sure whether this was patch or simply
transparent background, but it was combination of

https://build.opensuse.org/package/view_file/openSUSE:12.2/grub2/grub2-enable-theme-for-terminal-window.patch?expand=1

https://github.com/openSUSE/branding/commit/ca2953916aa3d06fae71f86ef64ac243277c8178

You can also see why it was dropped in

https://bugzilla.opensuse.org/show_bug.cgi?id=776244

> Also, I commented out all possible
> outputs to terminal, but I still see an empty black window popping out.
> Could you give me any idea about where to do not open terminal window in
> source code?

No :) It is just as mystery to me - I could not find where terminal
window gets displayed. Any pointers are welcome.

> Thank you very much.
> 
> Thanks,
> Henry Fang
> 
> 
> ---------- Forwarded message ----------
> From: Mat Troi <mattroisang@gmail.com>
> Date: Mon, Aug 22, 2016 at 5:37 PM
> Subject: Fwd: A black window pop out after I select a boot entry in grub2
> To: Fanghuangwei@gmail.com
> 
> 
> 
> 
> ---------- Forwarded message ----------
> From: *Andrei Borzenkov* <arvidjaar@gmail.com>
> Date: Wednesday, August 10, 2016
> Subject: A black window pop out after I select a boot entry in grub2
> To: The development of GNU GRUB <grub-devel@gnu.org>
> 
> 
> On Tue, Aug 9, 2016 at 12:29 AM, Huangwei Fang <henry.fang@oracle.com>
> wrote:
>> Hi everyone,
>>
>> When I boot a system, system takes me to the grub screen to select a boot
>> entry. After I choose a boot entry, a black window pops out within the
>> colorful grub screen. In that window, it prints out the "Loading" boot
>> archive message and the progress. That black window gives the bad visual
>> part of booting a system. I was wondering how can I disable this black
>> window pop out. Does anyone know how to do it or can provide any help?
> 
> 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.
> 
> If you are interested you could try it if it works for you.
> 
> While completely removing it may be technically possible (do not open
> terminal window and add dummy output that does nothing) I'm not sure
> it is good idea. You want to see errors if booting fails. Actually you
> want to see where you are stuck as well - so I'd rather add more
> output (like marking end of initrd loading).
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>