Hi,

Can you please provide the following files:

- /boot/grub2/grub.cfg
- /boot/grub2/grubenv
- /boot/loader/entries/*.conf

And also the output of blkid.

Created attachment 1551437 [details]
grubenv

Created attachment 1551438 [details]
grub.cfg.bad

The grub.cfg generated by the upgrade

Created attachment 1551440 [details]
The old (working) grub.cfg

Created attachment 1551441 [details]
A tar of /boot/loader/entries

[root@major togo]# blkid
/dev/sda1: LABEL="spinnyroot" UUID="d8314979-8ace-401c-88df-728ad6b89cb5" TYPE="ext4" PARTUUID="000caf9a-01"
/dev/sda2: LABEL="fedoraboot" UUID="6374398e-cc8d-4230-b423-3dc043115abf" TYPE="ext4" PTTYPE="dos" PARTUUID="000caf9a-02"
/dev/sda3: UUID="oFAwO8-WRQK-Qhse-VPuS-b6RW-nP2N-aJDNCy" TYPE="LVM2_member" PARTUUID="000caf9a-03"
/dev/sdb1: LABEL="ssd-boot" UUID="abebee4b-b709-4e63-aa2a-41530f785544" TYPE="ext4" PARTUUID="000435d5-01"
/dev/sdb2: UUID="FGc0rb-g2Bm-tl04-kz1P-u5qq-tGwP-wHguZe" TYPE="LVM2_member" PARTUUID="000435d5-02"
/dev/sdc1: LABEL="Music30GBa" UUID="4cff6531-3aff-401e-bbc6-bf3f2540e3d9" TYPE="ext4"
/dev/mapper/main-crypt: UUID="0af33ca5-b8f5-4f9b-9431-371a43459e7b" TYPE="crypto_LUKS"
/dev/mapper/main-more: LABEL="more" UUID="1bc920db-d852-493a-9959-89006e4b58f3" TYPE="ext4"
/dev/mapper/main-Quantal: PTUUID="00026849" PTTYPE="dos"
/dev/mapper/main-Precise2: PTUUID="0009514f" PTTYPE="dos"
/dev/mapper/main-root: LABEL="fedoranative-roo" UUID="bb6a7a92-e770-4170-8d69-5a499814fdec" TYPE="ext4"
/dev/mapper/main-spinnyswap: UUID="0aa5f4f5-2560-47a6-a8d8-e56db66b1fab" TYPE="swap"
/dev/mapper/main-ubuntu16.04: PTUUID="62ab4c6b" PTTYPE="dos"
/dev/mapper/main-debian9: PTUUID="80b0af64" PTTYPE="dos"
/dev/mapper/main-fedora28a: PTUUID="f1d122ab" PTTYPE="dos"
/dev/mapper/main-archlinux: PTUUID="03fe3215" PTTYPE="dos"

The host has two disks:
  a) /dev/sda a spinny hard drive
  b) /dev/sdb an ssd that was added later (but a few years/upgrades ago!)

A lot of the /dev/mapper/main-* entries are images for VMs, except for crypt,more,root,spinnyswap.

Thanks for the information. I don't see anything wrong with the files.

You could try loading the BLS files from the GRUB prompt, i.e:

grub> blscfg (hd1,msdos1)/loader/entries

or an individual entry with:

grub> blscfg (hd1,msdos1)/loader/entries/7725dfc225d14958a625ddaaaea5962b-5.0.5-300.fc30.x86_64.conf

And also getting debug output with

grub> set debug=blscfg

Before executing these commands.

Finally, you can try to update your GRUB core with:

$ grub2-install /dev/sdb (if the GRUB first and second stages are installed there).

(In reply to Javier Martinez Canillas from comment #7)
> Thanks for the information. I don't see anything wrong with the files.
> 
> You could try loading the BLS files from the GRUB prompt, i.e:
> 
> grub> blscfg (hd1,msdos1)/loader/entries

ok, that's actually (hd0,msdos1) for me; and that gives a 'can't find command `blscfg`

> or an individual entry with:
> 
> grub> blscfg
> (hd1,msdos1)/loader/entries/7725dfc225d14958a625ddaaaea5962b-5.0.5-300.fc30.
> x86_64.conf
> 
> And also getting debug output with
> 
> grub> set debug=blscfg
> 
> Before executing these commands.
> 
> Finally, you can try to update your GRUB core with:
> 
> $ grub2-install /dev/sdb (if the GRUB first and second stages are installed
> there).

That fixes the problem; having done that, then both the blscfg command and switching to the generated
grub.cfg work fine.

So it looks like something somewhere forgot to upgrade grub (or updated the wrong disk??)

I ended up in the same situation with my desktop (bios based system). No entries in the grub.cfg. By copying the rpmsave made the system bootable again. My system has only one hard drive.

(In reply to Dr. David Alan Gilbert from comment #8)
> (In reply to Javier Martinez Canillas from comment #7)
> > Thanks for the information. I don't see anything wrong with the files.
> > 
> > You could try loading the BLS files from the GRUB prompt, i.e:
> > 
> > grub> blscfg (hd1,msdos1)/loader/entries
> 
> ok, that's actually (hd0,msdos1) for me; and that gives a 'can't find
> command `blscfg`
>


Interesting, so the blscfg command should had been copied to the /boot/grub2/i386-pc directory. Is /dev/sdb1 mounted in /boot ?
 
> > or an individual entry with:
> > 
> > grub> blscfg
> > (hd1,msdos1)/loader/entries/7725dfc225d14958a625ddaaaea5962b-5.0.5-300.fc30.
> > x86_64.conf
> > 
> > And also getting debug output with
> > 
> > grub> set debug=blscfg
> > 
> > Before executing these commands.
> > 
> > Finally, you can try to update your GRUB core with:
> > 
> > $ grub2-install /dev/sdb (if the GRUB first and second stages are installed
> > there).
> 
> That fixes the problem; having done that, then both the blscfg command and
> switching to the generated
> grub.cfg work fine.
> 
> So it looks like something somewhere forgot to upgrade grub (or updated the
> wrong disk??)

Yes, it seems that the blscfg module was not correctly copied to /boot/grub2/i386-pc for GRUB core to find it.

(In reply to Jussi Eloranta from comment #9)
> I ended up in the same situation with my desktop (bios based system). No
> entries in the grub.cfg. By copying the rpmsave made the system bootable
> again. My system has only one hard drive.

Can you please provide the files mentioned in Comment 1 (if you already replaced the grub.cfg, you can generate again the same that was generated on upgrade using grub2-mkconfig -o grub.cfg).

I regenerated grub.cfg with grub2-mkconfig and the system now boots OK. Unfortunately, I don't have any more the faulty one that was created during upgrade :-(

(In reply to Javier Martinez Canillas from comment #10)
> (In reply to Dr. David Alan Gilbert from comment #8)
> > (In reply to Javier Martinez Canillas from comment #7)
> > > Thanks for the information. I don't see anything wrong with the files.
> > > 
> > > You could try loading the BLS files from the GRUB prompt, i.e:
> > > 
> > > grub> blscfg (hd1,msdos1)/loader/entries
> > 
> > ok, that's actually (hd0,msdos1) for me; and that gives a 'can't find
> > command `blscfg`
> >
> 
> 
> Interesting, so the blscfg command should had been copied to the
> /boot/grub2/i386-pc directory. Is /dev/sdb1 mounted in /boot ?

Yes it is:

[dg@major ~]$ df
....
/dev/mapper/main-root 114256488  75166064  33915604  69% /
tmpfs                   4077972      1604   4076368   1% /tmp
/dev/sdb1                243823    190472     36455  84% /boot
...

> > > or an individual entry with:
> > > 
> > > grub> blscfg
> > > (hd1,msdos1)/loader/entries/7725dfc225d14958a625ddaaaea5962b-5.0.5-300.fc30.
> > > x86_64.conf
> > > 
> > > And also getting debug output with
> > > 
> > > grub> set debug=blscfg
> > > 
> > > Before executing these commands.
> > > 
> > > Finally, you can try to update your GRUB core with:
> > > 
> > > $ grub2-install /dev/sdb (if the GRUB first and second stages are installed
> > > there).
> > 
> > That fixes the problem; having done that, then both the blscfg command and
> > switching to the generated
> > grub.cfg work fine.
> > 
> > So it looks like something somewhere forgot to upgrade grub (or updated the
> > wrong disk??)
> 
> Yes, it seems that the blscfg module was not correctly copied to
> /boot/grub2/i386-pc for GRUB core to find it.

What was supposed to ensure that it got copied? Something in the f29->f30 upgrade? I've got a journalctl
log of the upgrade (f29-f30upgrade.log )

(In reply to Dr. David Alan Gilbert from comment #13)
> (In reply to Javier Martinez Canillas from comment #10)

[snip]

> > > 
> > > So it looks like something somewhere forgot to upgrade grub (or updated the
> > > wrong disk??)
> > 
> > Yes, it seems that the blscfg module was not correctly copied to
> > /boot/grub2/i386-pc for GRUB core to find it.
> 
> What was supposed to ensure that it got copied? Something in the f29->f30
> upgrade? I've got a journalctl
> log of the upgrade (f29-f30upgrade.log )

On grub2 package upgrade, the grub2-switch-to-blscfg script is executed and this copies the blscfg module from /usr/lib/grub/i386-pc/blscfg.mod to the /boot/grub2/i386-pc/ directory.

Upgrading from F29 to F30 my system also was switched to BLS (GRUB_ENABLE_BLSCFG=true). It also made my system unbootable as grub.cfg did not have any entries besides 'System setup'.

(In reply to Adrian Reber from comment #15)
> Upgrading from F29 to F30 my system also was switched to BLS
> (GRUB_ENABLE_BLSCFG=true). It also made my system unbootable as grub.cfg did
> not have any entries besides 'System setup'.

I assume your system was also a legacy BIOS installation like the original issue reported here and also that the blscfg.mod was not present in /boot/grub2/i386-pc ?

(In reply to Javier Martinez Canillas from comment #16)
> (In reply to Adrian Reber from comment #15)
> > Upgrading from F29 to F30 my system also was switched to BLS
> > (GRUB_ENABLE_BLSCFG=true). It also made my system unbootable as grub.cfg did
> > not have any entries besides 'System setup'.
> 
> I assume your system was also a legacy BIOS installation like the original
> issue reported here and also that the blscfg.mod was not present in
> /boot/grub2/i386-pc ?

Correct. It was a BIOS installation and then I switched to EFI at some point. I used to have /boot/grub2/x86_64-efi which includes a blscfg.mod, but right now I have nothing in /boot/grub2, except grubenv (link to ../efi/EFI/fedora/grubenv).

Hard to tell how the original /boot partition looked like, because trying to fix the non-booting system I change (too) many things.

Is it possible that an old grub install is incompatible with the newer
blscfg ?
I tried booting an old f20 vm, and copied in the new blscfg:

grub> insmod blscfg
grub> blscfg
error: ../../grub-core/commands/blscfg.c.
grub> 

now I hadn't done any of the other setup etc - but seems worth the question?

(In reply to Dr. David Alan Gilbert from comment #18)
> Is it possible that an old grub install is incompatible with the newer
> blscfg ?

That may be possible indeed.

> I tried booting an old f20 vm, and copied in the new blscfg:
> 
> grub> insmod blscfg
> grub> blscfg
> error: ../../grub-core/commands/blscfg.c.
> grub> 
> 
> now I hadn't done any of the other setup etc - but seems worth the question?

Yes, thanks about that. Could you please try to run the blscfg command with:

grub> set debug=blscfg
grub> insmod blscfg
grub> blscfg

That should give us more information about why the blscfg command is failing with the old GRUB.

(In reply to Javier Martinez Canillas from comment #19)
> (In reply to Dr. David Alan Gilbert from comment #18)
> > Is it possible that an old grub install is incompatible with the newer
> > blscfg ?
> 
> That may be possible indeed.
> 
> > I tried booting an old f20 vm, and copied in the new blscfg:
> > 
> > grub> insmod blscfg
> > grub> blscfg
> > error: ../../grub-core/commands/blscfg.c.
> > grub> 
> > 
> > now I hadn't done any of the other setup etc - but seems worth the question?
> 
> Yes, thanks about that. Could you please try to run the blscfg command with:
> 
> grub> set debug=blscfg
> grub> insmod blscfg
> grub> blscfg
> 
> That should give us more information about why the blscfg command is failing
> with the old GRUB.

Doesn't look like it wants to cooperate:
grub> set debug=blscfg
grub> insmod blscfg
commands/blscfg.c:1080: grub_mod_init got here
grub> blscfg
error: ../../grub-core/commands/blscfg.c.
grub>

(In reply to Dr. David Alan Gilbert from comment #20)
> (In reply to Javier Martinez Canillas from comment #19)
> > (In reply to Dr. David Alan Gilbert from comment #18)
> > > Is it possible that an old grub install is incompatible with the newer
> > > blscfg ?
> > 
> > That may be possible indeed.
> > 
> > > I tried booting an old f20 vm, and copied in the new blscfg:
> > > 
> > > grub> insmod blscfg
> > > grub> blscfg
> > > error: ../../grub-core/commands/blscfg.c.
> > > grub> 
> > > 
> > > now I hadn't done any of the other setup etc - but seems worth the question?
> > 
> > Yes, thanks about that. Could you please try to run the blscfg command with:
> > 
> > grub> set debug=blscfg
> > grub> insmod blscfg
> > grub> blscfg
> > 
> > That should give us more information about why the blscfg command is failing
> > with the old GRUB.
> 
> Doesn't look like it wants to cooperate:
> grub> set debug=blscfg
> grub> insmod blscfg
> commands/blscfg.c:1080: grub_mod_init got here
> grub> blscfg
> error: ../../grub-core/commands/blscfg.c.
> grub>

Ok, thanks. I'll try to install a F20 an figure out what's wrong here.

In the meantime you can do a grub2-install on that machine too to make sure that the GRUB core is also updated.

run in this sort of bug yesterday (NON-UEFI box). 

Problem: 
boot menue doesn't get updated anymore after grub2-mkconfig -o /boot/grub2/grub.cfg or even the error free kernel update from 5.0.6 to 5.0.7.

boot menue only showed 5.0.6 and no 5.0.7 !
- crtl-e'ed the boot menue and exchanged 5.0.6 with 5.0.7 box booted without errors -


Problem is now fixed with "cp /usr/lib/grub/i386-pc/blscfg.mod /boot/grub2/i386-pc/blscfg.mod" and a following grub2-mkconfig as you mentioned.


looking in /boot/grub2/i386-pc/ turns out that blscfg.mod and all other files still remaining from F29 (install date 09.02.2019).
A bugfree upgrade to F30 was last week or so  !


Question: 
aren't the files under /boot/grub2/i386-pc/ get updated/upgraded during upgrade F29 => F30 even if /usr/lib/grub/i386-pc/blscfg.mod (date 28.03.2019) and /boot/grub2/i386-pc/blscfg.mod differ  ?


your comment in #14 mentions this, but it's not the case: it seems /boot/grub2/i386-pc is complete untouched during upgrade F29 => F30


rpm -qa| grep grub:

grub2-pc-modules-2.02-75.fc30.noarch
grub2-tools-minimal-2.02-75.fc30.x86_64
grubby-8.40-30.fc30.x86_64
grub2-tools-extra-2.02-75.fc30.x86_64
grub2-tools-2.02-75.fc30.x86_64
grub2-common-2.02-75.fc30.noarch
grub2-tools-efi-2.02-75.fc30.x86_64
grub2-pc-2.02-75.fc30.x86_64

I was to quick and too blind :-(


comment #14 is CORRECT !!!!!
my bad, sorry !!!!!


/boot/grub2/i386-pc/blscfg.mod and /boot/grub2/i386-pc/increment.mod are both from 01.04.2019.

ONLY the OTHER files in /boot/grub2/i386-pc/ are from 09.02.2019 (F29 box install date)



anyhow:

a "diff /usr/lib/grub/i386-pc/blscfg.mod /boot/grub2/i386-pc/blscfg.mod" told a differ, so I was mislead by this and didn't double-check that particular file again even while the cp command fixed my problem ...

my bad, sorry, sorry, sorry, ... !!!!!

(In reply to sixpack13 from comment #23)
> I was to quick and too blind :-(
> 
>

Sorry I'm confused now about what your problem was. If the blscfg module was not copied correctly or if it was copied but didn't work. What was the Fedora release originally installed on that machine?

> comment #14 is CORRECT !!!!!
> my bad, sorry !!!!!
> 
> 

To elaborate a little bit on this, there is a postinstall scriptlet that calls to grub2-switch-to-blscfg:

# rpm -q --scripts grub2-tools
...
postinstall scriptlet (using /bin/sh):

if [ "$1" = 2 ]; then
    ! grep -q '^GRUB_ENABLE_BLSCFG=false' /etc/default/grub && \
      /sbin/grub2-switch-to-blscfg --backup-suffix=.rpmsave &>/dev/null || :
fi

And in the grub2-switch-to-blscfg script there is the following that copies the blscfg and increment GRUB modules:

if [ $arch = "x86_64" ] && [ ! -d /sys/firmware/efi ]; then
    mod_dir="i386-pc"
elif [ $arch = "ppc64" -o $arch = "ppc64le" ] && [ ! -d /sys/firmware/opal ]; then
    mod_dir="powerpc-ieee1275"
fi

if [ -n "${mod_dir}" ]; then
    for mod in blscfg increment; do
        cp ${prefix}/lib/grub/${mod_dir}/${mod}.mod ${grubdir}/$mod_dir/ || exit 1
    done
fi

So yes, only those two modules are updated on a system upgrade to F30 and all the others in /boot/grub2/i386-pc are not.

I'm not able to reproduce this issue when testing a F28 -> F30 and F29 -> F30 system upgrades. I see that the blscfg module is correctly copied and the GRUB menu is populated:

F28 -> F30

# sha256sum /usr/lib/grub/i386-pc/blscfg.mod /boot/grub2/i386-pc/blscfg.mod 
12813d88bb4d479501286e2e63d9739b52d443f70a432e05a96f589aafd41809  /usr/lib/grub/i386-pc/blscfg.mod
12813d88bb4d479501286e2e63d9739b52d443f70a432e05a96f589aafd41809  /boot/grub2/i386-pc/blscfg.mod

F29 -> F30

# sha256sum /usr/lib/grub/i386-pc/blscfg.mod /boot/grub2/i386-pc/blscfg.mod 
12813d88bb4d479501286e2e63d9739b52d443f70a432e05a96f589aafd41809  /usr/lib/grub/i386-pc/blscfg.mod
12813d88bb4d479501286e2e63d9739b52d443f70a432e05a96f589aafd41809  /boot/grub2/i386-pc/blscfg.mod

I'm confused too.

thanks for the checksum, turns out for my backup'ed blscfg.mod (the bad one) :

53274998a486739ae35c3317829a00b1d68a96653b20c27185c64925a12fe8fd  /run/media/ron/BackupHD/BACKUP/boot/grub2/i386-pc/blscfg.mod

-rw-r--r--. 1 root root 14016  1. Apr 19:05 /run/media/ron/BackupHD/BACKUP/boot/grub2/i386-pc/blscfg.mod
-rw-r--r--. 1 root root 14012 11. Apr 19:29 /boot/grub2/i386-pc/blscfg.mod

as you can see checksum and size differ !
the second one is the copy from /usr/lib/grub/i386-pc/blscfg.mod


and to make the confusion complete: 

my box was working since updgrade (I guess it was at 01.04.2019) until yesterday with that blscfg.mod.

My problem was that the boot menue wasn't updates anymore suddenly yesterday.


I only touch files under /boot during in- and de-installing home-brewed kernels:

install goes like this: 
sudo make modules_install && sudo make install && sudo rm -rf /boot/{System.map,vmlinuz} && sudo /sbin/grub2-mkconfig -o /boot/grub2/grub.cfg


de-install goes like this: 
sudo rm -rfv /boot/loader/entries/*MY*;
sudo rm -rfv /boot/*MY* /lib/modules/*MY* && sudo grub2-mkconfig -o /boot/grub2/grub.cfg;

all my kernels are named like this "/boot/vmlinuz-5.0.7_MY", with "_MY" as appendix to distinguish from distro kernels.


that all I do under /boot !

why and how the blscfg.mod was modified and why is was working until yesterday: DON'T know !!!



wait, got a VM with F30 installed from dvd (not 100 % sure but I guess Fedora-Workstation-Live-x86_64-30_Beta-1.8.iso) 

-rw-r--r--. 1 root root 14016  5. Apr 22:13 /boot/grub2/i386-pc/blscfg.mod

53274998a486739ae35c3317829a00b1d68a96653b20c27185c64925a12fe8fd  /boot/grub2/i386-pc/blscfg.mod


size and checksum are identical what I'm having on my backup disk, the bad blscfg.mod.

VM was created for radicale tests only, NO home-brewed kernel install or the like, so I never touched something under /boot/ myself !


bad, I got a shortage of time now.
I'm willing to install a new VM from DVD and report some hours later, maybe tonight...

a fresh VM install with 

Fedora-Workstation-Live-x86_64-30_Beta-1.8.iso

e7bfcf674cf3318202804a777a990a125f6dd8cdef20f6a10818199ca2854d0f  Fedora-Workstation-Live-x86_64-30_Beta-1.8.iso 


and un-updated shows

sha256sum /usr/lib/grub/i386-pc/blscfg.mod /boot/grub2/i386-pc/blscfg.mod

53274998a486739ae35c3317829a00b1d68a96653b20c27185c64925a12fe8fd  /usr/lib/grub/i386-pc/blscfg.mod
53274998a486739ae35c3317829a00b1d68a96653b20c27185c64925a12fe8fd  /boot/grub2/i386-pc/blscfg.mod

ll /boot/grub2/i386-pc/blscfg.mod
-rw-r--r--. 1 root root 14016 Apr 12 17:09 /boot/grub2/i386-pc/blscfg.mod


and after an dnf update:

sha256sum /usr/lib/grub/i386-pc/blscfg.mod /boot/grub2/i386-pc/blscfg.mod

12813d88bb4d479501286e2e63d9739b52d443f70a432e05a96f589aafd41809  /usr/lib/grub/i386-pc/blscfg.mod
53274998a486739ae35c3317829a00b1d68a96653b20c27185c64925a12fe8fd  /boot/grub2/i386-pc/blscfg.mod


ll /boot/grub2/i386-pc/blscfg.mod /usr/lib/grub/i386-pc/blscfg.mod
-rw-r--r--. 1 root root 14016 Apr 12 17:09 /boot/grub2/i386-pc/blscfg.mod
-rw-r--r--. 1 root root 14012 Mar 28 17:29 /usr/lib/grub/i386-pc/blscfg.mod

(In reply to sixpack13 from comment #26)
> a fresh VM install with 
> 
> Fedora-Workstation-Live-x86_64-30_Beta-1.8.iso
> 
> e7bfcf674cf3318202804a777a990a125f6dd8cdef20f6a10818199ca2854d0f 
> Fedora-Workstation-Live-x86_64-30_Beta-1.8.iso 
> 
> 
> and un-updated shows
> 
> sha256sum /usr/lib/grub/i386-pc/blscfg.mod /boot/grub2/i386-pc/blscfg.mod
> 
> 53274998a486739ae35c3317829a00b1d68a96653b20c27185c64925a12fe8fd 
> /usr/lib/grub/i386-pc/blscfg.mod
> 53274998a486739ae35c3317829a00b1d68a96653b20c27185c64925a12fe8fd 
> /boot/grub2/i386-pc/blscfg.mod
> 
> ll /boot/grub2/i386-pc/blscfg.mod
> -rw-r--r--. 1 root root 14016 Apr 12 17:09 /boot/grub2/i386-pc/blscfg.mod
> 
> 
> and after an dnf update:
> 
> sha256sum /usr/lib/grub/i386-pc/blscfg.mod /boot/grub2/i386-pc/blscfg.mod
> 
> 12813d88bb4d479501286e2e63d9739b52d443f70a432e05a96f589aafd41809 
> /usr/lib/grub/i386-pc/blscfg.mod
> 53274998a486739ae35c3317829a00b1d68a96653b20c27185c64925a12fe8fd 
> /boot/grub2/i386-pc/blscfg.mod
> 
> 
> ll /boot/grub2/i386-pc/blscfg.mod /usr/lib/grub/i386-pc/blscfg.mod
> -rw-r--r--. 1 root root 14016 Apr 12 17:09 /boot/grub2/i386-pc/blscfg.mod
> -rw-r--r--. 1 root root 14012 Mar 28 17:29 /usr/lib/grub/i386-pc/blscfg.mod

Yes, that's expected because the grub2-switch-to-blscfg script is the one that copies the blscfg module when switching to a BLS configuration. But since on an F30 install, the BLS is enabled on installation the the blscfg module is not updated.

The idea is to allow older installations to have the blscfg module, not to update the module on each install (since we didn't update GRUB core and modules before).

okay, thx for info and support !

- wondering what caused my problem -

*** This bug has been marked as a duplicate of bug 1652806 ***