May I ask for your help in the following issues. In your replies please be specific since I am not an expert, just a fan of openSUSE.
My goal is to set up a laptop dual-booting Windows 8.1 64bit and openSUSE 13.1 64bit with KDE. The laptop is an Acer Aspire E1-572G bought new in January 2014.
The Yast - Hardware - Hardware Information dump file shows a Broadcom NetXtreme BCM57786 Gigabit Ethernet PCIe. Looking at Yast - Network Settings, tab Overview, the “Broadcom Ethernet controller” is “not configured” and refers to dmesg output which is here. The card works as tested under Windows.
I would appreciate your help to get this issue resolved. Thank you!
I had a similar issue, covered in another (long) thread. For a possible quick fix, edit the card and make sure it is set for dhcp. Change nothing else. I had forgotten that openSUSE was changing the handling of the ethernet card. Instead of being eth0, it will now be called something similar to enp2s0. Hope it is that simple for you.
Trying a few things following Prexy’s remarks, I could not arrive at any improvement. As they were not very specific, nor was the link to the mentioned thread included, I may have missed something.
I performed a repository switch to “Kernel” which updated the kernel-desktop to version 3.13.3-1.g7ccf96b. Rebooting the machine showed
Loading Linux 3.13.3-1.g7ccf96b-desktop ...
error: /boot/vmlinuz-3.13.3-1.g7ccf96b-desktop has invalid signature.
Loading initial ramdisk...
error: you need to load the kernel first.
Press any key to continue...
both in regular and in recovery mode, i.e., I could not login at all with kernel 3.13 and had to use the recovery mode of kernel 3.11. So I guess at this point I cannot really say if the newer kernel would help to run the network card!?
I’ve seen hints elsewhere that the following BIOS information might be useful.
Boot Mode: UEFI
Secure Boot: Enabled
Boot priority order:
1. opensuse-securebootST500LT012-9WS142
2. ATAPI CDROM: HL-DT-ST DVDRAM GU71N
3. Windows Boot Manager
4. USB FDD:
etc.
Thanks in advance for further suggestions.
ps: What does “recovery mode” actually mean and do? Pointers to some educational page? BTW, all pages at https://en.opensuse.org/ have taken ages to load recently. → ???
Hm, that’s strange.
Apparently something went wrong when installing the kernel.
Do you have a separate /boot partition maybe that ran out of space?
Please post the output of:
df -h
ps: What does “recovery mode” actually mean and do? Pointers to some educational page?
Recovery mode loads the kernel with options that should work under all circumstances, like disabling DMA, ACPI, multithreading and so on. And in particular it forces a general graphics driver like fbdev or vesa that should work with all graphics cards.
So /boot is on the root partition? Then there should be enough space.
Or is it a separate partition that is not mounted? (this would of course prevent the proper installation of the kernel as well)
Maybe try to just re-install it. (with /boot mounted of course if it’s a separate partition)
Click on the tick in the “Versions” tab for the 3.13 version until it gets changed to a green up-arrow (1 click should suffice), then press Accept.
Maybe it works then?
When I installed, I did not touch any of the /dev/sda1…5 which where all put in place by Win8.1. I deleted all suggestions for “higher” partitions which concerned swap, / and /home. I do not recall seeing a separate /boot suggestion. Therefore I did not implement one in the partition setup I manually created as displayed in the pasted screenshot.
I found the following file /boot/boot.readme which I am posting here in its completeness:
This file is for first help if you occur some problems during booting.
FAQ
Q: Kernel upgrade break my tuned bootloader settings, I want edit it manually.
A: set LOADER_TYPE="none" in /etc/sysconfig/bootloader. Hint is used /boot/vmlinuz and /boot/initrd symlinks as files which is already point to actual kernel. WARNING after kernel upgrade you must update also configuration manually, otherwise you cannot boot.
Configuration files for bootloader (if you want manually edit it)
/etc/sysconfig/bootloader - contain various settings for bootloader and is used by perl-Bootloader
for grub (x86*) or trustedgrub -
/boot/grub/menu.lst - main configuration for sections
/boot/grub/device.map - mapping of real device to grub device
/etc/grub.conf - batch file for grub if you need update your bootloader location
for grub2 (x86* or ppc)
/boot/grub2/grub.cfg - main configuration for sections
/boot/grub2/custom.cfg - custom user configuration file sourced by grub.cfg
/etc/default/grub - settings to control creation of grub.cfg used by grub2-mkconfig
for lilo ( x86* or ppc) -
/etc/lilo.conf - main configuration file
for elilo ( x86_64 or ia) -
/etc/elilo.conf - main configuration file
efibootmgr - utility for efi labels
/boot/efi/efi/SuSE/elilo.conf - configuration after elilo preprocess, use only if elilo break original configuration, in other case edit directly elilo.conf in /etc
for zipl (s390)-
/etc/zipl.conf - main configuration file
I don’t really have an idea about boot stuff, especially the new EFI method - is the above relevant? If yes, how?
May I assumed you used the method you described elsewhere? In my description of how I installed kernel 3.13.3 through Yast, I easily may have forgotten a detail. How about I uninstall all kernel 3.13.3 related, remove the Kernel repository, and use the zypper command in the way you described?
All this to say that I’m hesitant to go through another installation, but if we establish that it would really help…
OK. It’s just that this would have been a possible reason for the problem.
I found the following file /boot/boot.readme which I am posting here in its completeness:
This file is for first help if you occur some problems during booting.
I don’t really have an idea about boot stuff, especially the new EFI method - is the above relevant? If yes, how?
No.
Your boot is working, isn’t it?
It’s just that the 3.13 kernel cannot be loaded because it “has invalid signature”.
Now that you mentioned EFI, I do think that this is because of (U)EFI, secure boot in particular (which requires a kernel signed with a trusted key).
Unfortunately I have no experience with that stuff either.
But you should be able to turn off secure boot in the BIOS (UEFI actually ) settings.
Try this as a test to see if the kernel boots then and the ethernet card works.
You won’t be able to boot Windows 8.1 though with secure boot off, but it’s just for finding out whether it makes sense to follow up on the kernel.
May I assumed you used the method you described elsewhere?
Not quite. I directly downloaded the kernel package with a Webbrowser and installed it manually with “rpm”.
In my description of how I installed kernel 3.13.3 through Yast, I easily may have forgotten a detail. How about I uninstall all kernel 3.13.3 related, remove the Kernel repository, and use the zypper command in the way you described?
All this to say that I’m hesitant to go through another installation, but if we establish that it would really help…
No, the kernel package is installed and that’s all there is to it.
YaST and zypper do exactly the same thing anyway, as they both just use the underlying libzypp which in the end also just uses “rpm” to install the package.
>> ‘@robin_listas, #5’ (http://tinyurl.com/ofsduhd): Yes, I usually use
>> Firefox 24 (because of the missing “Next” function in more recent
>> versions) on openSUSE 12.3 64bit. Following your remark I checked with
>> Konqueror, it takes about half a minute to get the page at
>> https://en.opensuse.org/SDB:AMD_fglrx. A quick check on Windows Explorer
>> showed a delayed but bearable response.
> This seems to be a general (server?) problem. I saw that as well
> sometimes recently.
> Maybe related to this?
> http://lists.opensuse.org/opensuse-factory/2014-02/msg00143.html
No, at least my issue. I simply can not load some opensuse pages since
firefox 27.
The Acer UEFI version on my laptop allows for retaining UEFI Boot Mode, provided a “supervisor password” is set, and disabled Secure Boot at the same time (I do not understand how these items relate to each other).
Booting into kernel 3.13 now brings up a functioning ethernet card!
Amazingly, I can even boot into Win8.1 - although I don’t know why, and probably UEFI Secure Boot should not stay disabled. How to sign the kernel with a trusted key?
AFAIK UEFI is just a new (better? at least with more functionality) BIOS implementation.
Secure boot is for allowing to boot only boot loaders and kernels which are trusted. Some people say that was just an attempt by Microsoft to kill off competitors like Linux…:
But I don’t really want to comment on that here now.
UEFI and secure boot are actually independend of each other AFAIUI (and at least on “normal” computer systems the recommendation is to allow to turn off secure boot, but not all vendors might follow that and offer the possibility), but you need UEFI to have secure boot of course.
Booting into kernel 3.13 now brings up a functioning ethernet card!
That’s good to hear!
Amazingly, I can even boot into Win8.1 - although I don’t know why, and probably UEFI Secure Boot should not stay disabled. How to sign the kernel with a trusted key?
OK, if you still can run Windows 8.1 as well I would suggest to just leave it disabled. (at least for now)
You cannot sign the kernel with a trusted key. Actually this should be done by openSUSE, not sure if/why there’s a problem with that in the Kernel:stable repo (I think I do remember reading about an issue there, I will try to find a reference)
It should be possible to add a key to the (U)EFI partition (or to make it somehow trust that kernel), but I have absolutely no idea how.
I don’t even have an (U)EFI system myself.
I guess I got my hands on a piece of bleeding edge technology with my laptop.
Thank you, wolfi323 for your help so far! How is this issue expected to continue, e.g., with the next kernel update? Do I now have to take special precaution regarding updates etc.?
Is there a useful way to let the openSUSE kernel folks know about this thread and what we found out? Maybe I could help by embarking on a report somewhere?
Well, UEFI isn’t really bleeding edge anymore. But it is quite new, yes.
Thank you, wolfi323 for your help so far! How is this issue expected to continue, e.g., with the next kernel update? Do I now have to take special precaution regarding updates etc.?
No. Grub2 should always boot the highest versioned kernel.
If you’re satisfied with the current kernel, you might want to remove the Kernel:stable repo again, as it will get updates as well whenever there is a newer version released.
But as this repo is only for stable kernel versions, I don’t really think you should do that, and you should be quite safe.
And as I already mentioned, at least the previous kernel should always be available in “Advanced Options”, when you should have a problem after an update.
Is there a useful way to let the openSUSE kernel folks know about this thread and what we found out? Maybe I could help by embarking on a report somewhere?
You could make a bug report at http://bugzilla.novell.com/ (same username/password as here). Maybe they would backport the necessary fixes (or the whole driver if it is new), but I somehow doubt that.
In general openSUSE’s policy is to not provide new features as updates (as that might introduce new bugs).
It would depend of course on how easy/difficult it would be to add the necessary stuff to the 3.11 kernel I suppose.
I foolishly decided to test that (several hours ago). I opened a new firefox tab, and entered that URL. Firefox seemed to never load the page. I left it trying to load, and used a different tab.
I then tried the same url in konqueror. And that, too, seemed to never load. So, next, I tried it in chromium. The page was slow to load, but did eventually load. Then, after a while, the konqueror page loaded. Firefox still was not managing to load the page.
And then all hell broke loose. There was lots of disk activity. I was getting ready to kill firefox, when I realized that the whole desktop (KDE) was not responding. Fortunately, I had a terminal open. I used “top”. That showed “konqueror” as looping. I closed konqueror. The disk activity continued. And “top” showed konqueror as still looping. So I used the “kill” command. That stopped the disk activity, and the system became more responsive. I then closed “chromium” – I’m not sure it it was also looping.
Shortly after that, firefox told me that a script was not responding, and offered to stop the script. I said “yes”. Then I closed that tab. And then everything returned to normal.
I could see that I had used almost 1G of swap – with 8G of memory, I normally don’t see any swap being used. My guess is that there was an infinite recursion growing the konqueror stack to consume all memory. But that’s only a guess.
In any case, I prefer how “firefox” handled that to how “konqueror” handled it. There must be something broken on that web page.
Hm, I haven’t experienced anything like this, but then I didn’t really let it run that long. And I’m using KHTML normally, not WebKit. This might make a difference as well.
Strange enough, the page loaded fine (and fast) just now…
On 2014-02-18 22:56, nrickert wrote:
>
> robin_listas;2625611 Wrote:
>> There is both a bugzilla and a ticket with the domain admins, and no
>> activity nor solution in either.
>
> I foolishly decided to test that (several hours ago). I opened a new
> firefox tab, and entered that URL. Firefox seemed to never load the
> page. I left it trying to load, and used a different tab.
The admin people responded finally. They have found a bug in mediawiki,
which has been solved this afternoon.
The pages are not working because MediaWiki is trying to load resources
over port 80 using HTTPS. Found a bug in the
MW code that is causing this. Commenting the code fixed the issue.
Line 179 in WebRequest.php:
#if ( isset( $_SERVER'SERVER_PORT'] ) ) {
# $port = $_SERVER'SERVER_PORT'];
#} // else leave it as $stdPort
) settings.