12.3, Gnome 3.8, Nvidia/Nouveau, Suspend vs Resume. Headache ensues.

Hello! I’m trying to work out an issue with my desktop. Since my trials with openSUSE have been going well on my laptop I wanted to give it a shot full time. I’m no stranger to Linux, but a fresh barely week old openSUSE user.

My desktop hardware is an i3 processor, Nvidia GT440 graphics card, H61m board, 60GB SSD for root, and 2x1TB (mdadm RAID 1) for /home. I am running openSUSE 12.3 and I upgraded to Gnome 3.8 via a repo available here.

So I have two problems on the table. For one, if I install the Nvidia drivers, my desktop goes into a weird phase. If I boot up, it looks like the screen flashes a bit to get the login screen up, but ultimately gets no where. I see diagonal black and white lines that look very heavily pixelated. It looks like I’m in some sort of minecraft maze. I get no where otherwise and end up having to force the system off. Fortunately I planned ahead and backed up an image of my root partition just before adding the Nvidia driver, so I was able to flash the old image back in less than 2 minutes.

On to the flip side, when using Nouveau, I cannot resume from suspend. It looks like my system goes into suspend as it should, but when I resume it comes up with a gray screen. Then it’ll turn white after a few seconds, then gray again. Ultimately I get no where, and I have to force the system off.

With this exact system I had suspend working flawlessly in Ubuntu. That said, I’m a little unsure if I was ever on kernel 3.7 on Ubuntu. I used 12.04, which I believe used kernel 3.2 up to maybe 3.5. (I’m really unsure but I thought I saw 3.5 at some point). Likewise, I also had 13.04 beta installed for about a week, which I believe was on 3.8. I can’t positively recall but I’m just not sure “Ubuntu” and “3.7” was ever a combination used on my desktop. That said, I DID have suspend working, so I at least know the hardware and Linux kernel is capable of making this happen.

So basically… I’m stuck on Nouveau because I can’t install Nvidia, but I’d like to install Nvidia to see if it solves my resume/suspend issues that I’m currently facing. Ultimately I’m having two issues that kind of isolate me into a corner of having to power the system off and back on whenever needed… which is fine… but I kind of expected a little more success than where I’m at now.

Does anybody have any insight on what I can do?

Thanks!

No ubuntu doesnt use kernel 3.7
it uses kernels 3.2 (older ubuntu 12.04), 3.5 (12.04.2 and 12.10) and 3.8 (13.04)
want to try 3.8?
https://forums.opensuse.org/blogs/jdmcdaniel3/opensuse-installing-new-linux-kernel-versions-134/

Its is easy to do though you will have to use the command line a little.
Why not give it a shot?

Am I correct in understanding that all I have to do is add the repo for Kernel-Stable and the repo does the rest? The multiple lines of commands confused me as I wasn’t sure if the bottom part was applicable to ALL ways of obtaining the kernel or just if you compile yourself. During the output I saw it say it was installing kernel 3.8 so I figured it was doing all of the work on its own.

And then… “it” happened.

:~> sudo zypper in --from Kernel-Stable kernel-desktopLoading repository data...
Reading installed packages...
Resolving package dependencies...


The following NEW package is going to be installed:
  kernel-desktop 


1 new package to install.
Overall download size: 39.5 MiB. After the operation, additional 154.7 MiB will 
be used.
Continue? [y/n/?] (y): y
Retrieving package kernel-desktop-3.8.7-1.1.x86_64
                                           (1/1),  39.5 MiB (154.7 MiB unpacked)
Retrieving: kernel-desktop-3.8.7-1.1.x86_64.rpm ............[done (785.1 KiB/s)]
(1/1) Installing: kernel-desktop-3.8.7-1.1 ...............................[done]
Additional rpm output:


Kernel image:   /boot/vmlinuz-3.8.7-1-desktop
Initrd image:   /boot/initrd-3.8.7-1-desktop
KMS drivers:     nouveau
Root device:    /dev/disk/by-id/ata-Corsair_Force_GT_12056504000010711165-part2 (/dev/sdc2) (mounted on / as ext4)
Resume device:	/dev/disk/by-id/ata-Corsair_Force_GT_12056504000010711165-part1 (/dev/sdc1)
Kernel Modules:	thermal_sys thermal processor fan scsi_dh scsi_dh_hp_sw scsi_dh_emc scsi_dh_rdac scsi_dh_alua button wmi video mxm-wmi i2c-algo-bit drm drm_kms_helper ttm nouveau xhci-hcd hid-logitech-dj 
Features:       acpi kms plymouth block usb resume.userspace resume.kernel
Perl-Bootloader: 2013-04-15 00:31:54 <3> pbl-2331.2 Core::RunCommand.1642: Error: Command '/usr/sbin/grub2-install --target=i386-pc --force --skip-fs-probe "(hd0)" >/var/log/YaST2/y2log_bootloader 2>&1' failed with code 256 and output: /usr/sbin/grub2-bios-setup: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
/usr/sbin/grub2-bios-setup: error: embedding is not possible, but this is required for cross-disk install.


There was an error generating the initrd (1)



As a disclaimer, I ran into an issue when I installed openSUSE that seemed identical to this. I forget what I did, but something about my boot configuration wasn’t right. My system reports sda and sdb as my 1TB HDDs that are in a RAID 1 via mdadm, while sdc comes in as my SSD. Well, my SSD is where I want root, so it makes things semi weird since sdc is the primary drive. During the installation on the summary page I opened the boot settings and changed sdc to be first on priority, then it installed the MBR there. After that, I have had no booting issues. But at any rate, I wanted to explain this in case it was relevant, since the error I got during the installer before was oddly similar, even though I worked around it.

When I booted back up to openSUSE, I selected the advanced option to make sure 3.8 wasn’t hiding there. Only 3.7 was listed.

Any insight on what to do? I appreciate your help!

the first box of commands will do so stick with them

That’s what I did. The code text I pasted above was the result of the 3rd command from the first set on the link you provided.

sudo zypper ar http://download.opensuse.org/repositories/Kernel:/stable/standard/ Kernel-Stable
sudo zypper refresh
**sudo zypper in --from Kernel-Stable kernel-desktop**

Clearly there’s a bigger issue here, as I followed instructions and I got that crazy output. Is it possible it’s an issue with my SSD? Perhaps the alignment is throwing it off or something? I have no idea… just struggling to get this box working with as little fuss as possible. :stuck_out_tongue:

Thanks!

Ensure that you have added your “user” to “video” group using YaST or command line command described in the link
Refer :- https://www.suse.com/releasenotes/i386/openSUSE/12.3/RELEASE-NOTES.en.html#idm1261534012

I did, and it makes no difference. Keep in mind, openSUSE isn’t even booting yet, so my user enrollment to certain groups would mean nothing.

Further discussion with other users seems to indicate that I should have a bios_grub partition around 1 MiB in size, along with a dedicated /boot partition. Some users said the bios_grub partition is key to have on a GPT partition table, which my SSD has. Perhaps that’s where things are getting held up when the Nvidia driver attempts the install…

Are you using BIOS or EFI boot? Which disk is your boot disk (you install on sdc which implies you have sda and sdb)? What is content of /etc/default/grub_installdevice?

sda = 1TB HDD
sdb = 1TB HDD
sdc = 60GB SSD

/ = sdc
/home = /dev/md0 (sda and sdb in RAID 1 mirror)

I can’t tell you the grub_installdevice right now as I’m not at that system… and I have no idea about BIOS or EFI boot… I just know my desktop is an i3 with an H61m ASRock board and I installed openSUSE and countless other distros without issue in the past. Also, during the installer on the summary page I clicked on “Booting” and hit the one options menu. I made sdc the top device so the MBR got installed to sdc, which is what I wanted. I wanted sda and sdb untouched as they’re part of the RAID. I have no idea why my system aligns the drives like that… perhaps SATA2 ports just get precedence over SATA3 (SATA2 for sda and sdb, SATA3 port for sdc). It was like that in Ubuntu and several other distros I tried on the same hardware.

I was talking with some other users about this. They seem convinced that due to the cross disk error I got that there are some sort of boot instructions on another drive. It’s interesting they brought that up because when I first installed openSUSE, I had no idea I was effectively installing the boot loader (MBR) to sda. As I said, sda is one of my RAID drives. This of course caused some issues, so I found on the Arch wiki I can wipe the MBR by using some sort of dd setup… where I dd /dev/zero bs=446 or something. 446 is evidently the entirety of the MBR, whereas 447 and onward is the partition table.

After doing that, technically, the MBR should be wiped. Then I dropped sda from the array and re-added it to do a full rebuild. Then I reinstalled openSUSE, but this time I went into the “Booting” section of the summary page at the end of the installer. I went into the Boot Loader Options and bumped sdc to be at the top of the list… therefore the MBR was installed to sdc, which is what I wanted all along.

But this user indicating that there are boot instructions elsewhere on other disks made me wonder… what do you folks think about that? I thought through the dd /dev/zero 446 thing I was in the clear… I’m becoming increasingly confused and frustrated that I’m running into these issues. I’m half tempted to wipe my array and rebuild it from scratch and then do a fresh install full well knowing that I need to bump sdc to the top this time, just to wipe any degree of lingering errors from the table. But that just seems like overkill for what should otherwise be a simple fix… I would think…

Edit /etc/default/grub_installdevice and replace “(hd0)” with “/dev/disk/by-id/ata-Corsair_Force_GT_12056504000010711165”. Then error should go away.

Thanks for your quick insight. I’ll give that a shot when I’m back with the system in question. To be candid, I don’t like fixing things and just moving on… I like understanding what it is that was wrong and exactly how to repair it. Can you offer any additional insight with how you came to this solution and what it was that I did wrong during the installer?

Thanks so much! I hope this does the trick. :slight_smile:

I didn’t see any instance of “(hd0)”

Here’s the contents:

  GNU nano 2.3.1                                          File: grub                                                                                          

# Modified by YaST2. Last modification on Sun Apr 14 12:13:24 EDT 2013
# THIS FILE WILL BE PARTIALLY OVERWRITTEN by perl-Bootloader
# For the new kernel it try to figure out old parameters. In case we are not able to recognize it (e.g. change of flavor or strange install order ) it it use$


# If you change this file, run 'grub2-mkconfig -o /boot/grub2/grub.cfg' afterwards to update
# /boot/grub2/grub.cfg.
GRUB_DISTRIBUTOR="openSUSE 12.3"
GRUB_DEFAULT=saved
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=8
GRUB_CMDLINE_LINUX_DEFAULT=" resume=/dev/disk/by-id/ata-Corsair_Force_GT_12056504000010711165-part1 splash=silent quiet showopts"
# kernel command line options for failsafe mode
GRUB_CMDLINE_LINUX_RECOVERY="showopts apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe"
GRUB_CMDLINE_LINUX=""
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
# Uncomment to disable graphical terminal (grub-pc only)
GRUB_TERMINAL=gfxterm
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE=auto
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_LINUX_RECOVERY=true
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"
# Skip 30_os-prober if you experienced very slow in probing them
# WARNING foregin OS menu entries will be lost if set true here
GRUB_DISABLE_OS_PROBER=false
GRUB_THEME=/boot/grub2/themes/openSUSE/theme.txt
GRUB_BACKGROUND=/boot/grub2/themes/openSUSE/background.png





You are looking in the wrong file. You need “/etc/default/grub_installdevice”, not “/etc/default/grub”

Ah I see that now. Thank you.

I made the change that you said, but shortly after I installed the Nvidia drivers. Everything was listed as successful so I rebooted. When I booted back up I saw a blank gray screen with my cursor. After a while, it turned white, then back to gray and eventually white again. I’m a little unsure of how I would remove the Nvidia drivers via console. I know I can zypper rr to remove a repo, but I’m not even sure how I would list the repos to know which ones to remove. Then, I still have the Nvidia drivers installed - is there a way via terminal to nuke them?

In other news, I decided to do a fresh clean installation last night. This time I did things a little differently. I let openSUSE run through on autopilot with my SSD drive. I left my RAID drives untouched just to keep my experiment small. I wanted to see EXACTLY what openSUSE would do as far as the boot loader and assigning flags if it was in full control. Here’s what I got:

http://i.imgur.com/V1v197W.png

This sort of confuses me, because as you can see, I have boot and legacy_boot. But where is bios_grub? How would that be relevant to the scenario? I spoke to a few users on IRC and they indicated I should have a 1 MiB unformatted partition at the beginning with the bios_grub flag. Then after that, a separate /boot if I wish and on to / and /home. What do you folks think of this?

Thank you for all of your insight so far!

Well, it depends on how you installed them.

If you installed them via openSUSE repo - you can list repositories using “zypper lr”, list packages installed from specific repo using “zypper pa -i -r <name-of-nVidia-repo>” (you likely get listed both architectures - i586 and x86_64) and then remove all packages that have “i” flag in the preceding output using “rpm -e pkg-name pkg-name …”

I spoke to a few users on IRC and they indicated I should have a 1 MiB unformatted partition at the beginning with the bios_grub flag.

Yes, this is recommended. But openSUSE seems to default to using files on /boot filesystem directly. This works too, even though it is frowned upon upstream.

if you use Windows Vista or Windows7 then 446 is dangerous to use, and 440 is best. That is because Vista and Windows 7 sometimes store important information between 440 and 446 that should not be overwritten. … Just saying …