<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "http://bugs.gentoo.org/bugzilla.dtd">

<bugzilla version="2.22.7"
          urlbase="http://bugs.gentoo.org/"
          maintainer="bugzilla@gentoo.org"
>

    <bug>
          <bug_id>218599</bug_id>
          
          <creation_ts>2008-04-20 16:04 0000</creation_ts>
          <short_desc>sys-boot/grub-0.97-r5: setup_boot_dir running grub.conf commands is dangerous</short_desc>
          <delta_ts>2008-06-04 20:44:14 0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>Gentoo Linux</product>
          <component>Core system</component>
          <version>2007.0</version>
          <rep_platform>All</rep_platform>
          <op_sys>Linux</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          
          <priority>P2</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          
          <everconfirmed>1</everconfirmed>
          <reporter>Martin.vGagern@gmx.net</reporter>
          <assigned_to>base-system@gentoo.org</assigned_to>
          <cc>boxcars@gmx.net</cc>
    
    <cc>pchrist@gentoo.org</cc>
    
    <cc>sven.koehler@gmail.com</cc>

      

      
          <long_desc isprivate="0">
            <who>Martin.vGagern@gmx.net</who>
            <bug_when>2008-04-20 16:04:49 0000</bug_when>
            <thetext>In current grub ebuilds, there is a section in setup_boot_dir that greps most commands from grub.conf, the grub boot menu file, and unconditionally executes them with the grub shell. I consider this dangerous and harmful.

Suppose you have a menu entry to setup grub on a floppy disk, and while emerging grub you accidentially have a floppy with some valuable data inserted? Or maybe your device maps don&apos;t fit, you have a menu entry for installing grub, and consequently grub overwrites the boot sector of the wrong drive?

You might allow for automatic reinstallation of grub on update, but for this, you should introduce a new config file, and not reuse grub.conf.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>pchrist@gentoo.org</who>
            <bug_when>2008-04-20 16:42:38 0000</bug_when>
            <thetext>You have a point but there is a DONT_MOUNT_BOOT variable. When it is non-zero, setup_boot_dir function will not be executed.

echo DONT_MOUNT_BOOT=\&quot;yes\&quot; &gt;&gt; /etc/make.conf

and you will be fine, i think

Panagiotis (pchrist)</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>Martin.vGagern@gmx.net</who>
            <bug_when>2008-04-20 17:35:28 0000</bug_when>
            <thetext>(In reply to comment #1)
&gt; You have a point but there is a DONT_MOUNT_BOOT variable. When it is non-zero,
&gt; setup_boot_dir function will not be executed.

Interesting point. Generally, I&apos;d think not running grub with these commands should probably be the default, to play it safe. Personally, I would want to have the grub files copied to the boot directory, which would be prevented as well by setting that variable.

But you could combine that variable and the auto-install commands file in an interesting way: introduce some &quot;${ROOT}&quot;/etc/grub-install.conf or &quot;${ROOT}&quot;/etc/grub.install or whatever file, and if it exists, mount boot and run that file thorugh grub shell, and if it doesn&apos;t, log some useful message instead, mentioning that possibility.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>robbat2@gentoo.org</who>
            <bug_when>2008-04-20 19:33:06 0000</bug_when>
            <thetext>The danger of not running the setup_boot_dir stuff is that if grub is updated, and stagefiles change, the /boot copy won&apos;t get updated, which in some cases can lead to an unbootable box.

If we do change this, we need to make sure that the handbook docs match, and that every user is aware of it, so that they always run &apos;emerge --config sys-boot/grub&apos; after an update.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>Martin.vGagern@gmx.net</who>
            <bug_when>2008-04-20 19:50:41 0000</bug_when>
            <thetext>(In reply to comment #3)
&gt; The danger of not running the setup_boot_dir stuff is that if grub is updated,
&gt; and stagefiles change, the /boot copy won&apos;t get updated, which in some cases
&gt; can lead to an unbootable box.

If you don&apos;t run this whole setup_boot_dir stuff, then the stages won&apos;t be overridden, but that just amounts to DONT_MOUNT_BOOT=yes, I guess. So the problem is copying the stages (in setup_boot_dir) but not installing them. The current approach will not always help against this, as my own bug #98768 prooves. I have no setup or install command in my boot menu. By the way, that&apos;s a condition that should be pretty easy to check, and might be useful for migration.

&gt; If we do change this, we need to make sure that the handbook docs match, and
&gt; that every user is aware of it, so that they always run &apos;emerge --config
&gt; sys-boot/grub&apos; after an update.

How about this:
1. Provide a install config file as part of the ebuild
2. Have that file contain &quot;setup (hd0)&quot; and/or &quot;setup (hd0,0)&quot; as comments, along with description
3. Have the ebuild check that file contains either setup or install outside a comment, if so run them (stripping all comments), otherwise ewarn the user to update the file or install grub manually, including copying of the stage files.
4. Update the manual to mention this file

Migration path: file is default, admin gets ewarn, updates file, runs emerge --config sys-boot/grub as requested by ewarn, and everything should be fine.

New users path: users read manual, learn about file, edit it, run emerge --config sys-boot/grub as (then) described in manual, and everything should be fine.

Update path: ebuild checks file, notices it&apos;s been worked on, automatically copies stages and executes commands from config file, thus updating automatically.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>nightmorph@gentoo.org</who>
            <bug_when>2008-04-20 20:24:26 0000</bug_when>
            <thetext>I&apos;d prefer to keep the behavior of grub and what&apos;s mentioned in the handbooks as-is. It&apos;s worked for all our users up to this point. This bug describes a theoretical edge case.

If you leave in a floppy you didn&apos;t want overwritten, well, tough luck. Same goes for rm -rf / -- changing documentation to force an additional step that&apos;s never been needed increases the chances of user error, not decreases.

One of the nice things about using grub is that you don&apos;t have to touch it after an update. Forcing --config after updating makes it little better than lilo.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jkt@gentoo.org</who>
            <bug_when>2008-04-20 21:17:16 0000</bug_when>
            <thetext>At a quick glance, executing all lines concerning &quot;root&quot; or &quot;install&quot; in grub.conf doesn&apos;t look like an excellent idea, but forcing the user to perform some manuall steps wouldn&apos;t be really user-friendly, either.

I guess that executing all commands before first &quot;title&quot; line won&apos;t work in following case:

title kernel
root (hd6,0)
kernel /linux</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>Martin.vGagern@gmx.net</who>
            <bug_when>2008-04-20 22:06:00 0000</bug_when>
            <thetext>(In reply to comment #5)
&gt; I&apos;d prefer to keep the behavior of grub and what&apos;s mentioned in the handbooks
&gt; as-is. It&apos;s worked for all our users up to this point.

How so? http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&amp;chap=10#doc_chap2 doesn&apos;t give any indication that install commands should be included in the menu. It does, on the other hand, describe ways to install grub manually on first run. So I&apos;d be surprised if automatic reinstalation would work for even a majority of users.

&gt; This bug describes a theoretical edge case.
&gt; If you leave in a floppy you didn&apos;t want overwritten, well, tough luck. Same
&gt; goes for rm -rf /

That&apos;s an invalid comparison. If I type the rm command, I can expect it to do what it will do. If I run an emerge -u, I will only expect it to update my software, not to wipe my floppies. So if the floppy get&apos;s wiped, I&apos;d not blame the users here, but the ebuild.

&gt; One of the nice things about using grub is that you don&apos;t have to touch it
&gt; after an update.

On the contrary, I have to make damn sure to configure it at least afer every second update, or I&apos;ll get bit by bug #98768.

&gt; Forcing --config after updating makes it little better than lilo.

I wasn&apos;t suggesting that. If users create a file describing how to install grub, then the ebuild can and should do so automatically. That&apos;s waht I described as &quot;Update path&quot; in comment #4. I merely don&apos;t want these commands in the boot menu, as the install step doesn&apos;t belong in the menu, and the menu commands don&apos;t belong with the install process.

(In reply to comment #6)
&gt; At a quick glance, executing all lines concerning &quot;root&quot; or &quot;install&quot; in
&gt; grub.conf doesn&apos;t look like an excellent idea, but forcing the user to perform
&gt; some manuall steps wouldn&apos;t be really user-friendly, either.

You definitely want manual steps at first install, at least show the users the defaults you would use and ask him to confirm. Otherwise Gentoo would be worse than Windows. If you remember these steps, you can automatically execute them on update.

&gt; I guess that executing all commands before first &quot;title&quot; line won&apos;t work in
&gt; following case:

Before the first title? The current ebuild would execute commands from al places, stripping title among others.

&gt; title kernel
&gt; root (hd6,0)
&gt; kernel /linux

Would do exactly nothing, as there is neither setup nor install command. That&apos;s pretty much the most simple scenario where automatic update will fail even without a floppy in the drive. I&apos;d consider it pretty common.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>vapier@gentoo.org</who>
            <bug_when>2008-04-21 01:27:21 0000</bug_when>
            <thetext>here&apos;s a generalization that i&apos;m sure the docs team will agree with: people dont read.  the updating of the boot loader needs to be automatic and safe.  if the only unsafe condition you can propose is the highly uncommon (and unlikely) scenario where people have lines in their grub.conf to boot/setup a floppy disc, and they happen to have a floppy disc in their drive at the time of the emerge, and the mbr may get clobbered, then that&apos;s tough love for you.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>nightmorph@gentoo.org</who>
            <bug_when>2008-04-21 04:36:31 0000</bug_when>
            <thetext>(In reply to comment #8)
&gt; here&apos;s a generalization that i&apos;m sure the docs team will agree with: people
&gt; dont read.  the updating of the boot loader needs to be automatic and safe.  if
&gt; the only unsafe condition you can propose is the highly uncommon (and unlikely)
&gt; scenario where people have lines in their grub.conf to boot/setup a floppy
&gt; disc, and they happen to have a floppy disc in their drive at the time of the
&gt; emerge, and the mbr may get clobbered, then that&apos;s tough love for you.

Exactly. Un-CCing the GDP, as there&apos;s nothing for us to do here.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>Martin.vGagern@gmx.net</who>
            <bug_when>2008-04-21 14:41:08 0000</bug_when>
            <thetext>Created an attachment (id=150501)
Sane automatic installation

This is my first shot at a patch to illustrate my suggestions.
Let&apos;s see what&apos;s new in here.

1. introduced grub.install, with full path in $instcfg. For the time being, I placed that in /etc, but one might as well put it in $dir/grub. Up to you.

2. Demoted warning about moved menu.lst, because there are more important notes in the new ebuild, and calling every message important is kind of pointless.

3. Create grub.install if it does not exist. Right now, its contents is included in setup_boot_dir within the ebuild, but it might be moved to $FILESDIR, and it might be installed in the install phase and thus be merged with full config protection. This would make automatic cutsomization of that file difficult, though.

4. If grub.conf exists and contains setup or install commands, these are appended to grub.install. The sed script basically takes all menu entries with a setup or install in them, so we don&apos;t get all those commands used to actually boot some system. From the general commands before the first title, only the root command is included, I&apos;d guess that should be enough.
If you are worried about this whole sed script, you may use the old egrep command instead, but I&apos;d prefer the sed, as it is more restrictive in what it takes, and thus closer to my original intent, while it still should work.

5. If there are setup instructions, either freshly extracted from grub.conf, or installed from a previous build and probably edited by the admin, then execute these commands in order to automatically update grub, even its stage 1.

6. Do some error checking. The return calue from the grub shell seems to be no indication of errors. At least for me, a &quot;setup (hd0,0)&quot; without prior root caused an error and still resulted in a zero return value. Therefore I redirected the whole output from the grub shell to a temporary file, and grepped for error messages. The return value would still be useful in case of signals.

7. If there are no automatic update commands, tell the user to update manually. Also, if this is an update, warn him especially that failure to update might result in an unbootable system - my favorite bug #98768. I changed the wording somewhat, as you don&apos;t have to install into the MBR but can install into a partiton boot sector, and what stage2 gets executed depends on if you have a stage1.5, i.e. if you refer to the stage2 by block list or file name.

On the whole, this should give you
- No warnings or other log entries for successful automatic updates
- More accurate messages when there is something to be done
- More information when an error occurs
- An independent file for the install instructions
- Automatic migration, expected without lost functionality or extra steps
- A pretty sane subset of commands to be migrated

Did some testing, with and without grub.install present, with and without a setup command in my grub.conf. So far, everything looks good. Comments?</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>robbat2@gentoo.org</who>
            <bug_when>2008-05-02 19:56:44 0000</bug_when>
            <thetext>I&apos;m going to consider this later for r6 or r7.
Just because I don&apos;t have time at the moment (going to Africa, back in 2 weeks).</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>sven.koehler@gmail.com</who>
            <bug_when>2008-05-07 02:22:07 0000</bug_when>
            <thetext>My comments about this:

- Updated my grub today
- Didn&apos;t have any problems, because i don&apos;t have a setup-command in my grub.conf (so grub actually does nothing, right?)
- So i have added a proper root- and setup-command to my grub.conf to see what happens.
- I was REALLY pissed to see, that i see nothing, because grub output is piped to /dev/null and nobody checks if grub has failed or not or if there was a setup-command or not.
- Is there any standard way to store somewhere, where grub should be installed? So there is a program called grub-install, but it doesn&apos;t have a config file and doesn&apos;t use grub.conf. Instead, it takes a device name as a parameter. Where is a program/script, that actually uses the configuration from grub.conf to (re)install grub? (If i configured it somewhere, i&apos;d like to be abled to easily execute it)
- In which device&apos;s bootsector grub is installed, might be crucial for future support of hibernate, altering the boot-sector/MBR before going to suspend to disk. Any clue, what hibernate might expect in the future?
- What if a grub.conf/grub.install or whatever exists, but i&apos;m actually currently using LILO? The ebuild should check, if grub is really installed. (read 512 from the device, grep for GRUB to test, whether GRUB is installed. Unfortunatly, i don&apos;t know a good tool, to analyse the boot sector/MBR and grub doesn&apos;t offer any, i think). Of course, the device&apos;s name is needed, but grub.conf only supplies something like (hd0,0) which is hard to map back to a device name while grub-install takes a good old plain device name like in &quot;grub-install /dev/sda2&quot;
- It&apos;s hard to have a good sane system for managing boot loaders. Don&apos;t do anything or do something really good. The current sollution is in between and therefor error prone.

Just my 50 cent.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>Martin.vGagern@gmx.net</who>
            <bug_when>2008-05-07 07:49:28 0000</bug_when>
            <thetext>(In reply to comment #12)
&gt; - In which device&apos;s bootsector grub is installed, might be crucial for future
&gt; support of hibernate, altering the boot-sector/MBR before going to suspend to
&gt; disk. Any clue, what hibernate might expect in the future?

I would assume that this would use grub-set-default or maybe scripted manipulation of /boot/grub/default rather than any low-level modification of the boot sector. But as hibernation never worked for me (due to binary drivers), I might be wrong.

&gt; - What if a grub.conf/grub.install or whatever exists, but i&apos;m actually
&gt; currently using LILO?

My suggested patch would log a message if grub.install was comments only and execute the setup/install comments if there were any, not caring about lilo. I would expect people to only edit grub.install when they are using grub. As there are some ugly guesses involved with checking for GRUB, just as you pointed out, I would rather not do this automatically.

&gt; Of course, the device&apos;s name is needed, but
&gt; grub.conf only supplies something like (hd0,0) which is hard to map back to a
&gt; device name while grub-install takes a good old plain device name like in
&gt; &quot;grub-install /dev/sda2&quot;

One might use /boot/grub/device.map for the drive, from where access to the partitions should be easier at least. I don&apos;t know how far we can trust the contents of that file, but as it is used by the grub shell as well, we&apos;d at least be consistent with the executed setup commands. One can have a look at grub-install to see how this file can be (re)created when it&apos;s not present.

&gt; Just my 50 cent.

Thanks!</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>robbat2@gentoo.org</who>
            <bug_when>2008-06-04 20:44:14 0000</bug_when>
            <thetext>grub.conf.install implemented.</thetext>
          </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>150501</attachid>
            <date>2008-04-21 14:41 0000</date>
            <desc>Sane automatic installation</desc>
            <filename>bug218599a.patch</filename>
            <type>text/plain</type>
            <data encoding="base64">LS0tIC91c3IvcG9ydGFnZS9zeXMtYm9vdC9ncnViL2dydWItMC45Ny1yNS5lYnVpbGQJMjAwOC0w
NC0wNyAxMDozODo0OC4wMDAwMDAwMDAgKzAyMDAKKysrIGdydWItMC45Ny1yNS5lYnVpbGQJMjAw
OC0wNC0yMSAxNjoyMDowNS4wMDAwMDAwMDAgKzAyMDAKQEAgLTE0Miw2ICsxNDIsNyBAQCBzcmNf
aW5zdGFsbCgpIHsKIHNldHVwX2Jvb3RfZGlyKCkgewogCWxvY2FsIGJvb3RfZGlyPSQxCiAJbG9j
YWwgZGlyPSR7Ym9vdF9kaXJ9CisJbG9jYWwgaW5zdGNmZz0iJHtST09UfSIvZXRjL2dydWIuaW5z
dGFsbAogCiAJW1sgISAtZSAke2Rpcn0gXV0gJiYgZGllICIke2Rpcn0gZG9lcyBub3QgZXhpc3Qh
IgogCVtbICEgLUwgJHtkaXJ9L2Jvb3QgXV0gJiYgbG4gLXMgLiAiJHtkaXJ9L2Jvb3QiCkBAIC0x
NTQsMTggKzE1NSwxMiBAQCBzZXR1cF9ib290X2RpcigpIHsKIAlpZiBbWyAhIC1lICR7ZGlyfS9n
cnViLmNvbmYgXV0gJiYgW1sgLWUgJHtkaXJ9L21lbnUubHN0IF1dIDsgdGhlbgogCQltdiAtZiAi
JHtkaXJ9Ii9tZW51LmxzdCAiJHtkaXJ9Ii9ncnViLmNvbmYKIAkJZXdhcm4KLQkJZXdhcm4gIioq
KiBJTVBPUlRBTlQgTk9URTogbWVudS5sc3QgaGFzIGJlZW4gcmVuYW1lZCB0byBncnViLmNvbmYi
CisJCWV3YXJuICJtZW51LmxzdCBoYXMgYmVlbiByZW5hbWVkIHRvIGdydWIuY29uZiIKIAkJZXdh
cm4KIAlmaQogCiAJaWYgW1sgLWUgJHtkaXJ9L3N0YWdlMiBdXSA7IHRoZW4KIAkJbXYgIiR7ZGly
fSIvc3RhZ2Uyeywub2xkfQotCQlld2FybiAiKioqIElNUE9SVEFOVCBOT1RFOiB5b3UgbXVzdCBy
dW4gZ3J1YiBhbmQgaW5zdGFsbCIKLQkJZXdhcm4gInRoZSBuZXcgdmVyc2lvbidzIHN0YWdlMSB0
byB5b3VyIE1CUi4gIFVudGlsIHlvdSBkbywiCi0JCWV3YXJuICJzdGFnZTEgYW5kIHN0YWdlMiB3
aWxsIHN0aWxsIGJlIHRoZSBvbGQgdmVyc2lvbiwgYnV0IgotCQlld2FybiAibGF0ZXIgc3RhZ2Vz
IHdpbGwgYmUgdGhlIG5ldyB2ZXJzaW9uLCB3aGljaCBjb3VsZCIKLQkJZXdhcm4gImNhdXNlIHBy
b2JsZW1zIHN1Y2ggYXMgYW4gdW5ib290YWJsZSBzeXN0ZW0uIgotCQllYmVlcAogCWZpCiAKIAll
aW5mbyAiQ29weWluZyBmaWxlcyBmcm9tIC9saWIvZ3J1YiBhbmQgL3Vzci9saWIvZ3J1YiB0byAk
e2Rpcn0iCkBAIC0xNzMsMTMgKzE2OCw3NiBAQCBzZXR1cF9ib290X2RpcigpIHsKIAkJW1sgLWYg
JHt4fSBdXSAmJiBjcCAtcCAiJHt4fSIgIiR7ZGlyfSIvCiAJZG9uZQogCi0JaWYgW1sgLWUgJHtk
aXJ9L2dydWIuY29uZiBdXSA7IHRoZW4KLQkJZWdyZXAgXAotCQkJLXYgJ15bWzpzcGFjZTpdXSoo
I3wkfGRlZmF1bHR8ZmFsbGJhY2t8aW5pdHJkfHBhc3N3b3JkfHNwbGFzaGltYWdlfHRpbWVvdXR8
dGl0bGUpJyBcCi0JCQkiJHtkaXJ9Ii9ncnViLmNvbmYgfCBcCisJaWYgW1sgISAtZSAke2luc3Rj
Zmd9IF1dIDsgdGhlbgorCQljYXQgPiAiJHtpbnN0Y2ZnfSIgPDwtRU9GCisJCQkjIENvbW1hbmRz
IHRvIGJlIHVzZWQgdG8gaW5zdGFsbCBncnViLgorCQkJIyBUaGVzZSBjb21tYW5kcyB3aWxsIGJl
IGV4ZWN1dGVkIHdoZW5ldmVyIGdydWIgaXMgdXBkYXRlZC4KKwkJCSMgWW91IGNhbiBhbHNvIHJ1
biB0aGVtIG1hbnVhbGx5IHVzaW5nIGVtZXJnZSAtLWNvbmZpZyBncnViLgorCQkJIyBTZWUgImlu
Zm8gZ3J1YiIgb3IgaHR0cDovL3d3dy5nbnUub3JnL3NvZnR3YXJlL2dydWIvCisKKwkJCSMgVGFr
ZSB0aGUgZmlyc3QgcGFydGl0aW9uIG9uIHRoZSBmaXJzdCBkcml2ZSBhcyB0aGUgYm9vdCBwYXJ0
aXRpb24KKwkJCSNyb290IChoZDAsMCkgCisKKwkJCSMgSW5zdGFsbCBncnViIGludG8gdGhlIE1C
UiBvZiB0aGUgZmlyc3QgaGFyZCBkaXNrIGRyaXZlOgorCQkJI3NldHVwIChoZDApCisKKwkJCSMg
SW5zdGFsbCBncnViIGludG8gdGhlIGZpcnN0IHBhcnRpdGlvbiBvZiB0aGUgZmlyc3QgaGFyZCBk
aXNrOgorCQkJI3NldHVwIChoZDAsMCkKKwkJRU9GCisKKwkJaWYgW1sgLWUgJHtkaXJ9L2dydWIu
Y29uZiBdXSAmJiBcCisJCQkJZWdyZXAgJ14oc2V0dXB8aW5zdGFsbCknICIke2Rpcn0iL2dydWIu
Y29uZiA+L2Rldi9udWxsOyB0aGVuCisJCQllY2hvID4+ICR7aW5zdGNmZ30KKwkJCWVjaG8gIiMg
RW50cmllcyBhdXRvbWF0aWNhbGx5IGNvcGllZCBmcm9tIHlvdXIgZ3J1Yi5jb25mOiIgPj4gJHtp
bnN0Y2ZnfQorCisJCQkjIGZyb20gZWFjaCBtZW51IGVudHJ5IGNvbnRhaW5pbmcgZWl0aGVyIGFu
IGluc3RhbGwKKwkJCSMgb3IgYSBzZXR1cCBjb21tYW5kLCB0YWtlIHRoZSB0aXRsZSBhcyBhIGNv
bW1lbnQsCisJCQkjIGFuZCBpbmNsdWRlIGFsbCBjb21tYW5kcyBiZXR3ZWVuIHRpdGxlIGFuZAor
CQkJIyBpbnN0YWxsL3NldHVwLgorCQkJIyBObyBwZXJsIHRvIGtlZXAgZGVwZW5kZW5jaWVzIGRv
d24sIHNvcnJ5LgorCQkJc2VkIC1uICcvXnJvb3RcfF5tYXAve3g7L14jIHRpdGxlLyF7eDtwO3h9
O3h9OworCQkJCUgKKwkJCQkvXnRpdGxlL3tzL14vIyAvO2g7ZH0KKwkJCQkvXmluc3RhbGxcfF5z
ZXR1cC97eDtwO3MvLiovIyBjb250aW51ZWQvO3h9JyBcCisJCQkJIiR7ZGlyfSIvZ3J1Yi5jb25m
ID4+ICIke2luc3RjZmd9IgorCQkJZWxvZworCQkJZWxvZyAiQ29tbWFuZHMgZm9yIGF1dG9tYXRp
YyBpbnN0YWxsYXRpb24gb2YgZ3J1YiBoYXZlIGJlZW4gZXh0cmFjdGVkIGZyb20iCisJCQllbG9n
ICJ5b3VyIGdydWIuY29uZiBhbmQgc2F2ZWQgaW4gL2V0Yy9ncnViLmluc3RhbGwuIgorCQkJZWxv
ZyAiUGxlYXNlIHJldmlldyB0aGF0IGZpbGUuIgorCQkJZWxvZworCQlmaQorCWZpCisKKwlpZiBl
Z3JlcCAnXihzZXR1cHxpbnN0YWxsKScgIiR7aW5zdGNmZ30iID4vZGV2L251bGw7IHRoZW4KKwkJ
ZWluZm8gIlJlaW5zdGFsbGluZyBncnViIHdpdGggY29tbWFuZHMgZnJvbSAke2luc3RjZmd9Igor
CQllZ3JlcCAnXlteI10nICIke2luc3RjZmd9IiB8IFwKIAkJL3NiaW4vZ3J1YiAtLWJhdGNoIFwK
IAkJCS0tZGV2aWNlLW1hcD0iJHtkaXJ9Ii9kZXZpY2UubWFwIFwKLQkJCT4gL2Rldi9udWxsCisJ
CQk+IiR7VH0iL2dydWJpbnN0YWxsLm91dCAyPiYxCisJCWxvY2FsIGdydWJfcmVzPSQ/CisJCWlm
IFtbICRncnViX3JlcyAhPSAwIF1dIHx8IGVncmVwICdFcnJvcicgIiR7VH0iL2dydWJpbnN0YWxs
Lm91dCA+L2Rldi9udWxsOyB0aGVuCisJCQllZXJyb3IKKwkJCWVlcnJvciAiR3J1YiBmYWlsZWQg
dG8gaW5zdGFsbCBhdXRvbWF0aWNhbGx5ISIKKwkJCWVlcnJvciAiUGxlYXNlIGluc3RhbCBpdCBt
YW51YWxseSIKKwkJCWVlcnJvcgorCQkJd2hpbGUgcmVhZCBncnViX3JlczsgZG8KKwkJCQllbG9n
ICIke2dydWJfcmVzfSIKKwkJCWRvbmUgPCAiJHtUfSIvZ3J1Ymluc3RhbGwub3V0CisJCWVsc2UK
KwkJCWNhdCAiJHtUfSIvZ3J1Ymluc3RhbGwub3V0CisJCWZpCisJCWVjaG8KKwllbHNlCisJCWV3
YXJuICJUaGVyZSBhcmUgbm8gY29tbWFuZHMgaW4gJHtpbnN0Y2ZnfSB0byBpbnN0YWxsIGdydWIg
YXV0b21hdGljYWxseS4iCisJCWV3YXJuICJUaGVyZWZvcmUgeW91IG5lZWQgdG8gZWl0aGVyIGlu
c3RhbGwgZ3J1YiBtYW51YWxseSwgb3IgZWRpdCB0aGlzIgorCQlld2FybiAiZmlsZSBhbmQgcnVu
IGVtZXJnZSAtLWNvbmZpZyA9JHtQRn0gYWZ0ZXJ3YXJkcy4iCisJCWlmIFtbIC1lICR7ZGlyfS9z
dGFnZTIub2xkIF1dIDsgdGhlbgorCQkJZXdhcm4gIiIKKwkJCWV3YXJuICIqKiogSU1QT1JUQU5U
IE5PVEU6IHlvdSBtdXN0IGluc3RhbGwgdGhlIG5ldyB2ZXJzaW9uIgorCQkJZXdhcm4gInRvIHlv
dXIgc3lzdGVtLiAgVW50aWwgeW91IGRvLCBjb25mbGljdGluZyB2ZXJzaW9ucyIKKwkJCWV3YXJu
ICJtaWdodCBjYXVzZSBwcm9ibGVtcyBzdWNoIGFzIGFuIHVuYm9vdGFibGUgc3lzdGVtLiIKKwkJ
CWViZWVwCisJCWZpCiAJZmkKIAogCSMgdGhlIGdydWIgZGVmYXVsdCBjb21tYW5kcyBzaWxlbnRs
eSBwaXNzIHRoZW1zZWx2ZXMgaWYKQEAgLTE5OCw3ICsyNTYsNyBAQCBwa2dfcG9zdGluc3QoKSB7
CiAKIHBrZ19jb25maWcoKSB7CiAJbG9jYWwgZGlyCi0JZWluZm8gIkVudGVyIHRoZSBkaXJlY3Rv
cnkgd2hlcmUgeW91IHdhbnQgdG8gc2V0dXAgZ3J1YjoiCi0JcmVhZCBkaXIKKwlyZWFkIC1wICJF
bnRlciB0aGUgZGlyZWN0b3J5IHdoZXJlIHlvdSB3YW50IHRvIHNldHVwIGdydWIgWy9ib290XTog
IiBkaXIKKwlbWyAteiAkZGlyIF1dICYmIGRpcj0vYm9vdAogCXNldHVwX2Jvb3RfZGlyICIke2Rp
cn0iCiB9Cg==
</data>        

          </attachment>
    </bug>

</bugzilla>