[RESOLVED] substitution of motherboard = loss of refind boot menu

camarao · 2014-02-24 02:46:20

Dear Arch users,

I am owner of an Dell inspirion 14R 3560, which I succesfully installed
installed beginning of 2013 the arch linux in dual boot with the win8 version
that came with the notebook. For booting I used refind and it was working wonderfully.
My arch booting images and refind archives are in the same partition as microsoft's.
But as age comes to equipment, unfortunately I had an problem with de webcam and the
motherboard needed to be changed.

Naturally, if I use refind the modified boot menu and order no longer would be on this
board. So I tried to generate an new bootable usb for arch and so boot from it entering
efibootmgr and directing the boot process to refind and the rest should still be correct.

Result

1. change of the motherboard, resulted the loss of the refind boot menu, but win8 still
booted fine.

2. I was unable to get an bootable usb drive. I tried different partitioning tables msdos,
gpt and using the rufus program in win8 I used the option bios and gpt. Always labeled the
pendrive as ARCH_201402 (present last archiso version). Partition was always formated as FAT32.
I tried to install from win8 as mentioned above, and dd in another linux machine with arch and
the manual way in linux. The pendrive formated as GPT was not recognized as an bootable drive
and all others ways started with for items in an menu (arch booting, EFI shell v1 and v2 EFI
default menu). If I tried to boot arch usb pendrive nothing happens, just a black screen.

3. Well not being able to generate an new workable bootable pendrive I though I could rewrite
the UEFI menu through the EFI shell v2 (using bcfg). Well although it's not recommended it seemed
my only way out. Well the result as I finally could regain the refind menu after rebooting. Result;
windows choice works fine, but arch booting stalls showing the configuration from refind linux conf,
which shows from which disk to boot. Unfortunately it points to /dev/sda7 rather than using UUID
form the disk.

4.Generated an CD from a new iso I've downloaded. It doesn't recognizes the DVD as an bootable DVD
it simply boots into win8 again.

What impresses me is that after finally redirecting the boot to refind and getting the refind menu to
appear, I thought that the rest would be ok, since nothing else was modified on the harddisk. Apparently
I am missing something, may be the harddisk is not beeing recognized as "sda" anymore!

At the moment I don't have an bootable linux version so I can not check the above mentioned and also I can't
get the UUID if I want to change it in the refind linux conf file.

Any other suggestions? I have looked at several other posts with unsuccesfull booting with refind.
I have also browsed around in the refind author site to find how to recover from such an disaster,
but I couldn't find any suggestion which matched or is similar to my problem (may be I just didn't
looked in the right place.).

My next step would be to generate an bootable pendrive with another linux to then change the config file
of the refind linux conf to match UUID rather than sdx nomenclature for an drive. I also would like
to know if I had used GRUB rather refind would I still have an similar problem?

thanks for any help.

Last edited by camarao (2014-03-01 06:15:53)

mcloaked · 2014-02-24 10:57:08

camarao wrote:

Dear Arch users,
1. change of the motherboard, resulted the loss of the refind boot menu, but win8 still
booted fine.
2. I was unable to get an bootable usb drive. I tried different partitioning tables msdos,
gpt and using the rufus program in win8 I used the option bios and gpt. Always labeled the
pendrive as ARCH_201402 (present last archiso version). Partition was always formated as FAT32.
I tried to install from win8 as mentioned above, and dd in another linux machine with arch and
the manual way in linux. The pendrive formated as GPT was not recognized as an bootable drive
and all others ways started with for items in an menu (arch booting, EFI shell v1 and v2 EFI
default menu). If I tried to boot arch usb pendrive nothing happens, just a black screen.

How did you create the usb rescue drive? If you use the February 2014 Arch install iso and write the file to a usb key using:

# dd bs=4M if=/path/to/archlinux.iso of=/dev/sdx && sync

making sure that "x" in sdx is your pendrive. Usually this method yields a successfully booted pendrive - and if your BIOS is set to boot UEFI only it should work, but if your BIOS is set to boot UEFI as well as legacy but with UEFI as priority then it should in principle still work. Once booted you can run the command:

# efivar -l

to check that the efi vars are listed.

Does that work and boot correctly? If so then mounting your EFI partition, and root partition, and then chrooting into the system partition should allow you to look at the partition structure on the disk as the system now sees it and check that the PARTUUID values are still consistent with those in the refind_linux.conf file.

Also with the new motherboard it is possible that you may need to regenerate the initalramdisk once you are chrooted into the rescue system as above, so doing:

# mkinitcpio -p linux

# mkinitcpio -p linux

may fix your initramfs so that linux will then boot with the changed motherboard. Since you can see the rEFInd graphical screen once the system boots and from there you can boot Windows that indicates at least that your EFI is being seen and your NVRAM entry is being recognised by the EFI boot process. On the other hand I would have thought that changing the motherboard would have its new NVRAM not contain your old boot entries, so I would have though that regenerating the NVRAM entry using efibootmgr when booted into the rescue system and chrooted into your root partition would have been needed.

It may be an idea to try to get an Arch install usbkey as per the dd method, and boot into it, mount your root and EFI partitions, and chroot in. Then run the efibootmgr command to check the NVRAM entries, and if they are not as they should be then use efibootmgr to write a new refind entry. If that is a problem then you can write a new entry with the bdfg command from a UEFI shell v2. Also you need to check that the refind NVRAM entry is the default boot entry. It is possible that your system is booting to Windows via the fallback entry which is usually detected automatically in the EFI.

I know that you said you had rewritten your "UEFI menu" using the bcfg command in an EFI shell v2, and you can still check the entries using efibootmgr if you can boot the Arch install iso as above.

When you mentioned that the refind graphical menu seems to boot the wrong partition for Arch - maybe you can check the partition PARTUUID values once you have an Arch usbkey using the

# blkid

command, in association with the output from

# lsblk -f

and then check that the value in the refind_linux.conf file matches what you expect?

This method should at least allow you to check what the disk designation sdX is seen as in your updated system, and also let you explore the details of the partitions.

Maybe these suggestions might help.

srs5694 · 2014-02-25 01:20:43

camarao wrote:

3. Well not being able to generate an new workable bootable pendrive I though I could rewrite
the UEFI menu through the EFI shell v2 (using bcfg). Well although it's not recommended it seemed
my only way out. Well the result as I finally could regain the refind menu after rebooting. Result;
windows choice works fine, but arch booting stalls showing the configuration from refind linux conf,
which shows from which disk to boot. Unfortunately it points to /dev/sda7 rather than using UUID
form the disk.

Please elaborate on what happens when you select the Linux option. Specifically:

What does the Linux option launch? A Linux kernel or another boot loader (GRUB, ELILO, SYSLINUX)? If the latter, you should look into its configuration.
If you're booting your Linux kernel directly from rEFInd, what is the content of your /boot/refind_linux.conf file? (Or if you're using a manual boot stanza, what is it?)
What do you mean by "arch booting stalls showing the configuration from refind linux conf"? It sounds like you're saying that when you select the Linux option, it shows the contents of refind_linux.conf. rEFInd never displays the complete contents of this file on the screen, although it will show the boot options for the current boot. If it's hanging at that point, you may be running into this bug. Consider posting a link to a digital photo of the hung screen, particularly if it contains lots of text.
You can try booting a live CD and using the "blkid" utility to obtain the UUID for your boot disk, then pasting that into refind_linux.conf or your manual boot stanza. That should work around a problem if Linux is somehow getting confused by the motherboard change and reassigning /dev/sda to some other identifier.

camarao · 2014-02-25 01:31:48

Dear mcloaked,

first of all many thanks for your tips and sorry for taking so long to answer you.
srs5694, I just saw your post now. I'll answer first mcloaked and in an separated post I'll answer you.

I'll try to clear some of your suggestions:

1. About the bootable USB pendrive: I've tried exactly the dd command you
described in your post. I also build one using the rufu's program through win8 as
described in the arch wiki. The only thing I did which is not described or
suggested anywhere was to try different partition tables on the pendrive before
installing the iso, although I'm no convinced this is the problem. I used cfdisk
in another arch linux machine (not EFI board), tried FAT32, GPT, EFI partitioning.
The only which brought me to the menu with the shell options was with FAT32.
I also tried to install it manually as suggested in the arch wiki.
If I understood well this new way to prepare the bottable arch pendrive should
be an hybrid system able to boot both type of partition tables (EFI and non-EFI MOBOs).
But for me this apparently is not working. Just for the sake of trying again
after you wrote me I used the pendrive with formated with win8 using rufu's
program and using the dd command installed the iso as you described in the
reply. Another test I did was to use it to boot my non-EFI notebook and it
booted fine up to the arch choice menu. So there must be something else which is
not allowing to boot in EFI mode.
So, without an bootable arch I was not able to check all the linux commands you
suggested. I'll try to create other linux pendrive (like manjaro linux)
just to see if I can boot into it. I know that I can not rebuild the initialradisk
because it's other linux flavor, but at least I can check if the MOBO change did
not affect something else, like the harddrive.

Just to clear the MOBO configuration I have on this replacement is the following:
Secureboot is disabled; legacy boot menu is enabled and UEFI menu is enabled. If
I remember well this was also the configuration on the damaged MOBO.

I really don't understand why after reconstructing the UEFI menu with the refind
option I'm still not able to boot the linux. The only answer that comes to my mind
is that drives are no longer recognized as "sda" for the hard drive and the pendrive is not
recognized as sdc, since the cd drive was sdb.

I understand that this new method to boot usb pendrives is an simplification in
relation to the previous one but it seems to me that there is still a long way
to clean things up so it can work flawlessly in any situation.As I wrote on my previous post
the burned DVD did not work as well.

Is there any other way to build an bootable pendrive? are there instructions for the previous
way to prepare usb pendrives so I could build an older iso where this new boot way
is not implemented

Anyway thanks for the tips, I'll try booting with another linux to check some of the
informations you suggested and continue to try in getting the arch pendrive to work.

camarao · 2014-02-25 02:55:02

SRS5694, I'll try to answer you in between your questions.

Please elaborate on what happens when you select the Linux option. Specifically:

-------------------------------------------------
What does the Linux option launch? A Linux kernel or another boot loader (GRUB,
ELILO, SYSLINUX)? If the latter, you should look into its configuration.

R.: you mean the refind menu with the harddrive arch option?

If it is this, then it gets to an black screen where on top there is a blue
ribbon written rEFInd - Booting OS and on the black screen
and below it:

Starting vmlinuz-linux.efi
Using load options 'root=/dev/sda7 ro rootfstype=ext4 systemd.unit=graphical.target
initrd=EFI\arch\initramfs-arch.img'

where sda7 is the "/" from the arch intallation

if i start the pendrive it writes on an similar screen:

Starting vmlinuz.efi
Using load options ' '

and stops there. the same with the previous one.

The refind boot menu I got working using the bcfg shell command.
After using the EFI shell I could start the installed refind with
all the options present in the previous MOBO.

----------------------------------------------------------------------

If you're booting your Linux kernel directly from rEFInd, what is the content of
your /boot/refind_linux.conf file? (Or if you're using a manual boot stanza,
what is it?)

R.: "Boot to X" "root=/dev/sda7 ro rootfstype=ext systemd.unit=graphical.target"
"Boot to console" "root=/dev/sda7 ro rootfstype=ext systemd.unit=multi-user.target"

--------------------------------------------------------------------------------

What do you mean by "arch booting stalls showing the configuration from refind
linux conf"? It sounds like you're saying that when you select the Linux option,
it shows the contents of refind_linux.conf. rEFInd never displays the complete
contents of this file on the screen, although it will show the boot options for
the current boot. If it's hanging at that point, you may be running into this
bug. Consider posting a link to a digital photo of the hung screen, particularly
if it contains lots of text.

R.: See above answer to 1st question, ok will provide one and post as soon I find
out how to post it here.Well the post you suggested as being an similar problem I
don't think it proceeds since it was everythink working before replacing the MOBO.
Those simptoms just started after the new MOBO was instaled.

---------------------------------------------------------------------------------

You can try booting a live CD and using the "blkid" utility to obtain the UUID
for your boot disk, then pasting that into refind_linux.conf or your manual boot
stanza. That should work around a problem if Linux is somehow getting confused
by the motherboard change and reassigning /dev/sda to some other identifier.

R.: The problem is, not even an cd is booting, so I can't get an linux shell to
get this information.

camarao · 2014-02-25 15:18:52

Hi folks,

I got some news. Today I tried to disable UEFI on the motherboard and run the
mobo on legacy mode. I put the pendrive and voi la, the pendrive got to the
choice menu and I booted arch and got the linux shell from the pendrive.

So it seems that this version of pendrive is not able to boot in an UEFI
environment (at least not formatting the way as explained in the wiki). The
previous mode of creating an UEFI compatible pendrive worked fine, but I can not
find any links to the pages where the instructions are. I guess that they were
deleted after this new hybrid pendrive system was introduced.

Well my best guess now is that this way of preparing the pendrive does not allow
booting any UEFI enabled mobo just legacy. The only thing I remember from the
previous way to prepare the pendrive is that I could not use cfdisk as
partitioning program, if I remember well. The program to use was gdisk or
cgdisk. I tried that with this new iso version, but I can try it again. Is there any way around
this problem?

I thought in getting an iso image from May or June last year. But even if I find one I still
do not remember how to create the pendrive the old way. I didn't wrote down the
procedure because I thought it would not change so soon. So if somebody still
has those instructions I'll will be very grateful if you can pass it to me.

Thanks again for both of you (mcloaked and SRS5694), and certainly all your
suggestions will be tested and as soon as I can I'll post them here.

PS.: Do you think that it might be a problem to chroot in legacy mode into
the installed arch version to correct things?

PS of PS.: I repatitioned the pendrive I had an created an GPT partition table on it, and using de "dd" command, I've installed opensuse 13.1 on it and tried to boot it and it worked. Conclusion, there is some problem with the arch iso archive which does not start it. Now I'll check if drives and other stuff is ok.

Last edited by camarao (2014-02-25 19:25:58)

srs5694 · 2014-02-26 00:54:38

I have a hunch that you're running into this bug:

https://bbs.archlinux.org/viewtopic.php?id=156670

It affects some users who use the EFI stub loader, particularly (but not exclusively) those with Lenovo hardware. It's sporadic; it affects some kernels but not others, and precisely which kernels are affected varies from one computer to another. Thus, it's entirely plausible that a motherboard swap would cause previously-working kernels to stop booting.

camarao · 2014-02-26 17:13:27

srs5694,

well I saw this post as well. But if I understood it in this case was an change
of kernels that generated that problem. In my case it is an mobo swap. There are
several aspects in that post that differs from my case:

1. In their case they could boot from an pendrive to test thing and even change root

2. their problem started after an kernel update

3. and last but not least, apart from the new mobo, nothing else changed. So Hard
drive is still being recognized as sda, partitions are the same, originally didn't
change a line in any conf file. Really the only difference is the new mobo.

As I mentioned as PS in the previous post, opensuse booted fine (so I could check
hd recognition and check the EFI partition. I burned an manjaro pendrive (0.8.9 version)
and it didn't boot as well. I'll try one or two more different flavors, which should work
with EFI boot procedures, to check which one works.

So my null hypothesis would be if everybody boots and arch not, there must be something
with the boot procedures in arch and their derivatives which prevents booting.

By the way, I'll tried to boot the arch pendrive and manjaro pendrive on another notebook
(not Dell but an Avell make, which works with UEFI) and it did not boot as well, neither
arch nor manjaro, opensuse i did no tested. On this notebook the only difference is
that it started udev to recognized the something (I guess the partitions to mount them)
and then it stopped the 4 colored dotted lines (with manjaro boot) and with arch boot
it stopped with an black screen. I'll try opensuse today on the avell notebook. I am
trying to find another dell notebook to see if I get the same behavior.

So it doesn't seem to be neither an refind specific problem or mobo problem it seems once
more to be boot procedure problem with the pendrive hybrid iso and probably a similar
or diferent problem with the installed arch.

I still have the question, if I boot with the opensuse pendrive, chroot into the arch
distribution would tehre be any problem if I regenerate the initialramdisk in the changed
root (arch install)?

I am getting out of options and I can't stay much longer without my linux, since I am not
an IT person. I really do not know where specifically to look for. Don't get me wrong I'll
love to troubleshoot it, informatic is an hobby for me and I love to know well my computers
so I don't get dependent on others, but at the same time I need to work and for this I need
my arch back.

If there is somebody with more boot procedure knowledge or even point me to some web page
with more detailed boot procedure in arch, I'll try to look at it. But I can not afford
going over another week without my notebook.

Sorry for this despair messages and I know arch is much of diy and as I said I learned to
appreciate it, but I got into an situation which apparently should be simple to correct and
at the end it transformed it self in an small monster.

PS.: I was browsing an release note from opensuse https://doc.opensuse.org/release-notes/ … c.123.uefi and found this information "Modern firmware has a garbage collector that collects deleted entries and frees the memory reserved for old entries. A problem arises when faulty firmware does not collect and free those entries; this may end up with a non-bootable system." I don't know what this should exactly mean because the win8 boots well but arch on HD don't, manjaro and now sabayon (it get stucks on acpi) so far don't boot from penderive as well, only opensuse. Well still looking for probem. keep you updated.

PS2.: Now I finally found out how to pass a starting command in an EFI shell v2 following this post here https://bbs.archlinux.org/viewtopic.php?pid=1248590. I did an simpler comand like "vmlinuz-arch.efi root=/sdax ro initrd=\EFI\arch\initramfs-arch.efi" it gives me an error message saying it can't open initramfs-arch.efi. Just to remember I have secure boot disabled on this board (or at least I disabled it on menu boot, which I did when I got the note to install arch). In the shell v1 it simply stuck on an black screen. So, one step further in the troubleshooting, still looking for an solution.

Last edited by camarao (2014-02-27 03:34:37)

mcloaked · 2014-02-28 10:16:00

Some people have had success using Win32 Disk Imager to write iso files to a usbkey and boot from the key. Since you did not have any success using the dd method maybe using Win32 Disk Imager from within Windows may get you a bootable usb install key that works. Anyway this is only a suggestion that may give an alternative method for getting a bootable usb key to use as a rescue system. The latest version is on sourceforge (it does not work with normal iso files but apparently it does support hybrid images created with Syslinux's isohybrid (http://sourceforge.net/p/win32diskimager/wiki/Home/) so maybe it would work with the arch install iso.

Last edited by mcloaked (2014-02-28 10:22:26)

ilkyest · 2014-02-28 14:58:58

I've using the "yumi boot manager"...
http://www.pendrivelinux.com/yumi-multi … b-creator/

Just run, select "arch linux" and voilá. Including you can add more distros with the right function. I don't want another to do it on windows

Just be carefully... yumi don't try read what "drive" is your pen-drive, so, if you plug the pen-drive, that has letter "E:\" and after you select on yumi D:\ drive, yumi will do normally your wish...

just be truth that you select the correct usb drive on yumi. After it, only smiles

Last edited by ilkyest (2014-02-28 15:00:47)

camarao · 2014-03-01 06:12:58

Hi for everybody,

before I go further, many, many thanks for your reply's mcloaked and ilkyest. But I think I found the problem and it lies probably in EFISTUB, which gummiboot (official boatloader from archs iso setup) and refind uses as well. I found it described in some web pages that EFISTUB may have an very unstable behavior from mobo to mobo (aparently even between mobos from the same maker model) and without any warning it could stop working for no reason. In this same site they described as GRUB2, legacy and elilo not using EFISTUB and would not be affected by it.

Since I had an opensuse pendrive booting and it used grub2 I looked a way to boot the installed arch on the harddrive directly from the grub cli and I found it. Quite tricky, it took me some time work it out (my IT ignorance), but voi la I was able to initialize the arch.

So long story simple solution, I'll change to GRUB2, although very few people advise to do it, because GRUB2 seems to have a lot of issues with efi. But I'll give it a go.

Once more thanks for all your help folks, it was nice to talk to you.

srs5694 · 2014-03-01 21:53:55

camarao wrote:

well I saw this post as well. But if I understood it in this case was an change
of kernels that generated that problem. In my case it is an mobo swap. There are
several aspects in that post that differs from my case:

The key take-away from the linked-to discussion, which even some of its participants miss, is that the bug involves a highly unpredictable interaction between the EFI stub loader, the firmware, the way that the EFI stub loader is launched, and perhaps other factors. The bug can manifest itself because of a change in any of these factors. Of particular interest to your problem, one person with Computer A can boot with kernels X and Y but not Z, whereas somebody with Computer B can boot with kernels X and Z but not Y. Thus, it's entirely plausible that a motherboard swap could cause the bug to manifest and the computer to stop booting. This inconsistency also makes it very difficult to test fixes; a change to the kernel code could produce a booting kernel, but that improvement might just reflect a lucky "roll of the dice" for that build and hardware.

camarao wrote:

But I think I found the problem and it lies probably in EFISTUB, which gummiboot (official boatloader from archs iso setup) and refind uses as well. I found it described in some web pages that EFISTUB may have an very unstable behavior from mobo to mobo (aparently even between mobos from the same maker model) and without any warning it could stop working for no reason. In this same site they described as GRUB2, legacy and elilo not using EFISTUB and would not be affected by it.

Which is exactly the bug I referenced -- or at the very least, it's got consistent symptoms with that bug. (I can't rule out the possibility of there being two or more bugs with similar symptoms, of course.)

As I mentioned as PS in the previous post, opensuse booted fine (so I could check
hd recognition and check the EFI partition. I burned an manjaro pendrive (0.8.9 version)
and it didn't boot as well. I'll try one or two more different flavors, which should work
with EFI boot procedures, to check which one works.

Unless you're changing the boot procedure, OpenSUSE boots via GRUB (or ELILO for earlier versions), and so is not using the EFI stub loader.

So my null hypothesis would be if everybody boots and arch not, there must be something
with the boot procedures in arch and their derivatives which prevents booting.

Yes: Arch relies on the EFI stub loader, which has this bug -- at least in Arch. I don't recall seeing a single reported case of this bug in other distributions, and as rEFInd's maintainer, I'd expect to have heard a report or two from people who've tried rEFInd with other distributions. Thus, I do suspect that there's something extra going on with Arch, too -- something about the Arch kernel build procedures that's causing the bug to manifest when it doesn't appear with other distributions. I can't be positive of that, though.

PS2.: Now I finally found out how to pass a starting command in an EFI shell v2 following this post here https://bbs.archlinux.org/viewtopic.php?pid=1248590. I did an simpler comand like "vmlinuz-arch.efi root=/sdax ro initrd=\EFI\arch\initramfs-arch.efi" it gives me an error message saying it can't open initramfs-arch.efi. Just to remember I have secure boot disabled on this board (or at least I disabled it on menu boot, which I did when I got the note to install arch). In the shell v1 it simply stuck on an black screen. So, one step further in the troubleshooting, still looking for an solution.

The usual cause of that symptom is a typo or other mistake in specifying the initrd file. In the past it was even worse, since the kernel didn't produce an error message; it would just hang. This was very frustrating for early adopters of the EFI stub loader. In fact, it was one of the things that motivated me to add automatic initrd detection to rEFInd; computer programs aren't as prone to typos as humans are, so the auto-detection made this work much more smoothly.

Arch Linux

#1 2014-02-24 02:46:20

[RESOLVED] substitution of motherboard = loss of refind boot menu

#2 2014-02-24 10:57:08

Re: [RESOLVED] substitution of motherboard = loss of refind boot menu

#3 2014-02-25 01:20:43

Re: [RESOLVED] substitution of motherboard = loss of refind boot menu

#4 2014-02-25 01:31:48

Re: [RESOLVED] substitution of motherboard = loss of refind boot menu

#5 2014-02-25 02:55:02

Re: [RESOLVED] substitution of motherboard = loss of refind boot menu

#6 2014-02-25 15:18:52

Re: [RESOLVED] substitution of motherboard = loss of refind boot menu

#7 2014-02-26 00:54:38

Re: [RESOLVED] substitution of motherboard = loss of refind boot menu

#8 2014-02-26 17:13:27

Re: [RESOLVED] substitution of motherboard = loss of refind boot menu

#9 2014-02-28 10:16:00

Re: [RESOLVED] substitution of motherboard = loss of refind boot menu

#10 2014-02-28 14:58:58

Re: [RESOLVED] substitution of motherboard = loss of refind boot menu

#11 2014-03-01 06:12:58

Re: [RESOLVED] substitution of motherboard = loss of refind boot menu

#12 2014-03-01 21:53:55

Re: [RESOLVED] substitution of motherboard = loss of refind boot menu

Board footer