It's not about kernel but GRUB messages Le mer. 10 août 2016 19:57, Xen <x...@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 >
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
