Well, it’s simple, I made the usb stick as per instruction (using the imagewriter), but I can’t seem to boot the live 13.1: the boot menu is visible and I can choose language, set graphic or kernel options, but as soon I hit enter and the background image starts “pulsating”… nothing happens. Now, this is not the forst linux live env I play with, and this is a show stopper.
My PC is BIOS based, so no EFI issues to think of, and anyway it wouldn’t even show the menu if it was the case.
I tried with another stick, it was the same.
Can someone help me? Thanks.
Somewhere you talk about “linux Live env”. Can you expln which DVD image you put on that stick? The installation, or the Live KDE, or the Live Gnome, or …?
I used openSUSE “Live Gnome”, 13.1, 64bit.
I also tried with the openSUSE “Factory GNOME Live”, Build0117, 64bit.
Both exibit the same issue.
Any linux mint distro will work out of the box on my system, same for fedora or ubuntu, or debian (varius version, both 32bit or 64bit).
What exactly do you mean with “pulsating”?
Do you get to text mode when pressing ‘ESC’ there, or does it freeze completely?
IIUYC, this sounds like a graphics driver issue. What graphics chip do you have?
Have you tried to select “No KMS” at the boot menu? (press ‘F3’ for that)
For “pulsating” I mean that the image is changin its luminosity (that eyecandy works, tch).
If I hit ESC it goes to a text prompt with a bunch of lines, that doesn’t continue, just a blinking cursor on the last line.
I don’t think it’s the chipset fault, it’s a nvidia gtx660, and works perfectly both with the proprietary or the open driver (well, on other distros).
I tried various combinations on both the graphic and kernel options. I will try again just the one you said, and report back.
And what messages would be in the last lines?
I don’t think it’s the chipset fault, it’s a nvidia gtx660, and works perfectly both with the proprietary or the open driver (well, on other distros).
Well, how good/well nouveau works might be very specific to the exact driver and kernel version.
Using “NoKMS” prevents the use of nouveau and should use fbdev instead. So at least it would rule out a graphics driver issue.
OK, I tried selecting “No KMS” at the boot menu, and got something different: a green progressbar.
This actually updates and after a good while (6 minutes or so) it completes itself, the boot process continues and the DE loads.
So I suspect it’s just slow on that phase, doesn’t matter what stick or usb port I use (well, I had the suspect it was an HW issue, but it was not).
I then tried to boot with defaults, and wait too… and it boots in that case too, but it takes a whole 6 minutes in that case too.
In both cases the DE feel slugghish, slow, and the boot time is awful (ok, it’s “live”, but it’s just too slow).
I remember trying openSUSE 12, it was slow, but not ilke that.
Too bad, will try again in the future to see if things will get better, but as of now it’s a show stopper.
Well, especially with GNOME3, the graphics driver can make a big difference. (I just noticed that at the weekend, when I tried a 13.1 GNOME installation in VirtualBox for the first time)
GNOME insists on using OpenGL, if the driver doesn’t support it well enough (or Mesa’s software rendering is used), everything gets sluggish.
Try a KDE LiveCD (that always worked fine for me even in VirtualBox 
).
You could also try to install it and then add the proprietary nvidia driver. I think it would be running well then either.
As to why the boot took so long, that’s hard to say without further information.
Will KDE to check if it was that, could be interesting.
The previous openSUSE I tried was indeed a KDE “variant”, but I can’t remember its performances.
Virtualbox uh? since usb stick are cheap I prefer testing on real HW…
But for testing an installation I prefer to be able to work on something else while it is installing, and switching back and forth between the testing system and the real system.
Also I don’t like to repartition my hard disk all the time, and I like to be able to use my hard disk space for other things than to reserve it for a testing partition that I don’t use most of the time.
I meant test the live OS, that is the first step for me.
If that isn’t successful, no need to setup on HDD, it would be a loss of time.
On 2014-03-24 15:16, wolfi323 wrote:
> As to why the boot took so long, that’s hard to say without further
> information.
Just a guess: check if the BIOS has a floppy enabled, when there is no
floppy drive present.
(read 12.3 release notes)
If the BIOS mistakenly has a floppy configured the kernel or the install
system probes it, and as it does not exist, it fails. It apparently
takes an awful time to bail out and get into its thick head not to try
the floppy again. It probably even tries several times…
This problem has been plaguing recent installs.
It even happens on virtualized hardware! If you tell vmware player to
remove the floppy it initially adds, the virtual BIOS still has the
floppy listed.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
I just tried to explain why I prefer to use VirtualBox to test Live/Installation ISOs most of the time. (even when trying out a Live medium, it has the advantage that I can run it in the background and don’t have to reboot my system)
If you want to try how well it would run on your real hardware, you should run it on your real hardware of course.
But one problem with Live media remains: you cannot really see how well it would work with a proprietary driver. You would have to do a real installation for that.
Floppy eh? I will check that, I think I set it to disabled, but I reset the BIOS setting after an upgrade, so I may have forgot about it in the hurry.
About live media: yes, trying on real HW would be ideal, but usually live media gave me a good approximation, so I don’t install all of the distro.
Thanks for now.
But you ARE trying the Live media on your real hardware.
I have found on several occasions that running the live disk can be quite sluggish on some machines, yet when I actually install from the installation DVD (not the live disk) on these same machines, they are quite snappy.
You get the look and feel from the live disk, but you do not get the same performance as you would from an install, and the amount of difference seems to fluctuate from machine to machine.
On 2014-03-27 09:26, Fraser Bell wrote:
> I have found on several occasions that running the live disk can be
> quite sluggish on some machines, yet when I actually install from the
> installation DVD (not the live disk) on these same machines, they are
> quite snappy.
Two days ago I was trying to install 13.1 on vmware player 6, using the
full DVD, and failed several times, with several combinations. I tried
scssi disks, sata disks (virtual, of course), this or another option…
all failed at the partitioning stage. Sometimes YaST crashed and dumped
me into text mode of the installer. Others it hung and went by very
slowly (and no, not the phantom floppy issue in bios).
I blamed player 6, because previously I was using version 5. I then
tried the xfce rescue image, thinking of using it to create the
partitions. Kernel crash. Then I noticed a brief message in the kernel
crash log entries visible on the screen about a failed memory
allocation. I inmeditely increased memory from 500 Mb to 750, and the
installation went without a hink.
Linux handles very badly low memory situations.
I used 500 MB because I happen to have a laptop running 13.1 with just
that amount of ram, no problems at all. Lots of free memory. But I had
forgotten that I used puppy to first create a swap partition on it:
openSUSE install uses too much ram.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
That is very true, and couple that with running a live disk instead of off a HD installation, you can get really sluggish results.
Something else you may want to check is if the stick mounted as USB 2.0 (or 3, if you have it). Defective/oxidized connectors sometimes get the stick to mount as USB1.x, which is 8x slower than USB 2.0 IINM.
I had this problem both with the USB port in an old desktop, one of three USB ports in a netbook, and a couple of stick, one of which turned out to be a falsification. Also, one of the problems took a combination of port and stick, i.e., with other (newer) sticks the port would work normally, or with the stick in another port.
You can easily see how the stick mounted by running dmesg soon after inserting it - highspeed is USB2.0, fullspeed is 1.x.
On 2014-03-29 05:46, brunomcl wrote:
>
> Something else you may want to check is if the stick mounted as USB 2.0
> (or 3, if you have it). Defective/oxidized connectors sometimes get the
> stick to mount as USB1.x, which is 8x slower than USB 2.0 IINM.
Ugh 
> I had this problem both with the USB port in an old desktop, one of
> three USB ports in a netbook, and a couple of stick, one of which turned
> out to be a falsification. Also, one of the problems took a combination
> of port and stick, i.e., with other (newer) sticks the port would work
> normally, or with the stick in another port.
What a nightmare…
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)