It’s early to even think of openSUSE13.3. But…I thought so why not test Tumbleweed (factory/Tumbleweed)? I did in a VirtualBox VM (running on a 13.1 server, VirtualBox ver 4.3.20 r96996) . I set it up with 1 kernel, 2GB Ram, 128MB GPU Ram… Bridged NIC (eth1)etc.
I did it for 2 reasons,
Check if Libreoffice 4.41 has fixed the problem/bug I had in Libreoffice 4.35(openSUSE13.2) about make reporting in Libreoffice Base.
-Will upcoming digikam 5.x pick up the functionality of(remote) mysql support again?
I have been doing monthly test installs of Tumbleweed. I normally use the 64-bit DVD image for this (but from a USB flash drive). Thus far, the installs have been going pretty well.
I’m not sure why you had that opening screen. Maybe it has to do with your VM setup. My test installs have been on real hardware.
Hello!
Yes I agree. I did my best to set up the VM based of the experince I have with VM. . I didn’t suffer on running the setup at cli/yast at “light mode”.
I manage. I did get the GUI after reboot. My concerns was about, Libreoffice (haven’t test yet) and digikam.
My post was not to complain about Tumbleweed. Just to share some of my experience.
This is actually an easy fix. It did only start recently (the 2-5 snapshot worked fine). If at the grub menu you pick the VESA option at the bottom and set it to an actual value, the GUI will work correctly. It’s something with the autodetect on VBox that stopped working.
Actually, I went back and checked, and the 2015-2-5 image no longer works either, so it is more likely an issue with the changes in VBox (big surprise there). Either way, just hit F3 at the boot menu and pick an actual resolution and it will work as expected.
I am trying from Factory until the current isos of tumbleweed and i all work well.
Lately the tested on Vbox and also are worked . Only comment that there is a fault that occurs in the majority of the isos, in the summary proposal , occur three faults, that keeps me select the software , but I accept and i get on with the installation and it works well.
Not only VBox.
I can reproduce the problem on real hardware too, by starting the install with “nomodeset”.
There might be a general problem with the fbdev driver (which is normally used when modesetting is disabled, and as the installation CD does not include the vboxvideo driver, it is used when you install inside VirtualBox too) at the moment. It seems to not be able to determine the resolution or something.
PS: I can still reproduce this with the latest snapshot’s NET install ISO.
If it works now with the full DVD, it may be that the vboxvideo driver is included there and works now again. It didn’t work for a week or so, because the version in the openSUSE packages was incompatible with the new xorg-x11-server.
Ah, so this supposedly means that it worked until recently? Makes sense, AFAIK this issue did only appear recently, about two weeks ago I think. (but again, it’s unrelated to any changes in VirtualBox, and not even restricted to VirtualBox)
I read it as “it works well with the current Factory ISOs” and so he is using those instead of Tumbleweed…
And a side-note:
It shouldn’t make a difference to the installed system if the text mode installer is used instead of the graphical one. And on most hardware the problem should not occur anyway I think.
So I don’t see this as a grave problem. Although it would definitely nice to have it working again…
Regarding the errors in the last screenshots: I haven’t seen that, but then I haven’t really tried a fresh install recently (I just booted the NET install CD a few times).
But you probably should do as the message tells you and file a bug report. Especially if it still happens with the next snapshots…
I retried the 0205 NET iso and it had the same problem, so it’s been going on longer (although, to be fair, I thought that one had worked in VB before the newest update).
But I’m more surprised openQA hasn’t been catching this. I though they tested the images in a VM of some sort, which would default to the same video drivers.
Might be.
I didn’t notice it until a few days ago, but I didn’t try to install Tumbleweed in the last months.
I did notice that the vboxvideo driver doeesn’t work any more with the latest xorg-x11-server and submitted a fixed package on Feb. 26th.
Then I heard about the installer problem, and thought it might be related to the “broken” vboxvideo driver (the new package only got part of Tumbleweed with the 20150309 snapshot). Unfortunately this is a different problem though, and not at all related to VirtualBox as mentioned.
But I’m more surprised openQA hasn’t been catching this. I though they tested the images in a VM of some sort, which would default to the same video drivers.
Well, they don’t use VirtualBox for testing, but rather KVM I think.
AFAIK the VMs run with the cirrus video driver. There have been problems with that as well not too long ago, but they have been fixed.
I tested today with the same setup (VirtualBox VM (running on a 13.1 server, VirtualBox ver 4.3.20 r96996) . I set it up with 1 kernel, 2GB Ram, 128MB GPU Ram… Bridged NIC (eth1)etc.) And openSUSE-Tumbleweed-KDE-Live-x86_64-Snapshot20150312-Media.iso
Working fine to boot up with GUI and, - I was smiling when I was was seeing the check-box for “Enable Snapshots” in root partitioning using BtrFS :). There is still hope!
No I didn’t go trow the whole installation, saving some fun for the weekend.
If it is correct in the past, long before exiting the 13.2 .
The error is maintained in the isos that are pulled; but I still have to try the latest ( 3 in total ) .
The tests have been done in hardware and in virtual mode ( and the error is the same ) .
I have not been past the problem that you have. All the systems installed in uefi, gpt and by default BTRFS, for both the root ’ / ’ as for the ’ /home’ .
If I apologize for my poor English (sorry) .
Tested the version: openSUSE-tumbleweed-DVD-x86_64-Snapshot20150312-Media.iso .
Same error . Perhaps that is why i use BTRFS in ’ /home’ and ’ / ', the end result is correct.
Tumbleweed, VirtualBox 4.34 .24_OSE r9876 : harddisk: 64 to 74 Gb - ram: 12Gb, Efi , graphics 128Gb, 2 cpu cores and ICH9 chipset (run in /dev/sdb is a ssd KINGSTON_SH103S3 ) .
FYI, the reason for the installer starting in text mode only in VirtualBox (but also on real hardware when you specify “nomodeset”) has been identified and fixed now. http://bugzilla.opensuse.org/show_bug.cgi?id=932319
Actually, it was a bug in Xorg that prevented the “vesa” driver (which is used as fallback when KMS is not supported, like in VirtualBox) from working at all. When you selected a particular resolution at the boot menu (or added the “vga=xxx” option), then fbdev is used instead, which worked all the time.
