[opensuse-factory] snapshot 20180206 - boots to white screen
have skylake intel graphics. Have just dup and system now boots to white screen. Any help appreciated -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday, 8 February 2018 7:58 nicholas cunliffe wrote:
have skylake intel graphics. Have just dup and system now boots to white screen. Any help appreciated
Most likely bsc#1079465 (bsc#1079748), fixed Mesa package is available in Tumbleweed update repository (it's recommended to also delete ~/.cache/mesa_shader_cache and /var/lib/sddm/.cache). Hint: there is already a thread with subject "White SDDM login screen after update Mesa 18" since yesterday. Did you read it? Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Most likely bsc#1079465 (bsc#1079748), fixed Mesa package is available in Tumbleweed update repository
update repo? - i updated 1 hour ago from a fully updated system?
Hint: there is already a thread with subject "White SDDM login screen after update Mesa 18" since yesterday. Did you read it?
a new snapshot released 1 hour ago knowing it would break peoples systems?! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday, 8 February 2018 8:34 nicholas cunliffe wrote:
Most likely bsc#1079465 (bsc#1079748), fixed Mesa package is available in Tumbleweed update repository
update repo? - i updated 1 hour ago from a fully updated system?
Hint: there is already a thread with subject "White SDDM login screen after update Mesa 18" since yesterday. Did you read it?
a new snapshot released 1 hour ago knowing it would break peoples systems?!
Sorry, no idea what you are talking about. Updated packages (version 18.0.0-187.1) have been available since yesterday in Tumbleweed update repository. I updated to them yesterday and they fixed my issue (which had different symptoms - screensaver unable to unlock the session). Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Citeren Michal Kubecek <mkubecek@suse.cz>:
On Thursday, 8 February 2018 7:58 nicholas cunliffe wrote:
have skylake intel graphics. Have just dup and system now boots to white screen. Any help appreciated
Most likely bsc#1079465 (bsc#1079748), fixed Mesa package is available in Tumbleweed update repository (it's recommended to also delete ~/.cache/mesa_shader_cache and /var/lib/sddm/.cache).
That was supposedly fixed in snapshot 20180206: ==== Mesa ==== Subpackages: Mesa-dri-devel Mesa-libEGL-devel Mesa-libEGL1 Mesa-libGL-devel Mesa-libGL1 Mesa-libglapi0 libgbm1 libwayland-egl1 - u_mesa-st-shader_cache-restore-num_tgsi_tokens-when-loading.patch * Fix crash when loading shader. (bnc#1079465) ==== Mesa-drivers ==== Subpackages: Mesa-dri Mesa-gallium Mesa-libva libvdpau_r300 libvdpau_r600 libvdpau_radeonsi libvulkan_radeon libxatracker2 - u_mesa-st-shader_cache-restore-num_tgsi_tokens-when-loading.patch * Fix crash when loading shader. (bnc#1079465) It specifically mentions bsc#1079465, so I did expect not to be hit by this. Surprise, it boots to a white screen. :-(
Hint: there is already a thread with subject "White SDDM login screen after update Mesa 18" since yesterday. Did you read it?
In fact, I did. But after reading the above in the release announcement was under the impression that the problem was already fixed.
Michal Kubeček
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
i do NOT have ~/.cache/mesa_shader_cache i have now deleted .cache/qtshadercache/ and /var/lib/sddm/.cache. this allowed login screen but afterwards i get a black screen. one can see the toolbar shadow repeatedly appearing as if kwin or plasmashell etc is trying to restart. (note i could get this before by blindly typing in the password during the white screen) i did not pay attention to yesterdays thread since i had already updated and had no problems -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Il giorno Thu, 08 Feb 2018 08:51:43 +0100 Arjen de Korte <suse+factory@de-korte.org> ha scritto:
That was supposedly fixed in snapshot 20180206:
If you booted even once with the broken Mesa version, you will have to delete your caches anyway after the update as the bad data will be already on disk.
i deleted entire .cache, all good now, thanks for help -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Citeren Luca Beltrame <lbeltrame@kde.org>:
Il giorno Thu, 08 Feb 2018 08:51:43 +0100 Arjen de Korte <suse+factory@de-korte.org> ha scritto:
That was supposedly fixed in snapshot 20180206:
If you booted even once with the broken Mesa version, you will have to delete your caches anyway after the update as the bad data will be already on disk.
I don't understand. Before I ran 'zypper dup' this morning, all was well. Afterwards, it booted to a white screen. At what time did I have a broken Mesa version? Or was Mesa already broken in the previous snapshot and I just didn't notice yet? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Il giorno Thu, 08 Feb 2018 10:20:54 +0100 Arjen de Korte <suse+factory@de-korte.org> ha scritto:
well. Afterwards, it booted to a white screen. At what time did I have a broken Mesa version? Or was Mesa already broken in the previous snapshot and I just didn't notice yet?
Mesa wrote broken caches, but you don't notice when they are written, but when they are read back (program restarts etc.). That's why even after the update you have to remove the cache: the crashy data has been already written to disk.
im not sure the explanation is complete... i was able to roll back perfectly, which would have also read ~/.cache? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On čtvrtek 8. února 2018 12:04:17 CET nicholas cunliffe wrote:
im not sure the explanation is complete... i was able to roll back perfectly, which would have also read ~/.cache?
If you rolled back to 17.3.3, it probably did not use any of the records in the cache since some other part of their signatures did not match. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2018-02-08T10:40:35, Luca Beltrame <lbeltrame@kde.org> wrote:
Mesa wrote broken caches, but you don't notice when they are written, but when they are read back (program restarts etc.). That's why even after the update you have to remove the cache: the crashy data has been already written to disk.
And someone decided that manual intervention instead of fixing the programs to detect this and clean it up automatically was the way to go? Sigh. We're trying to drive users away, right? -- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On pátek 9. února 2018 12:59:31 CET Lars Marowsky-Bree wrote:
On 2018-02-08T10:40:35, Luca Beltrame <lbeltrame@kde.org> wrote:
Mesa wrote broken caches, but you don't notice when they are written, but when they are read back (program restarts etc.). That's why even after the update you have to remove the cache: the crashy data has been already written to disk.
And someone decided that manual intervention instead of fixing the programs to detect this and clean it up automatically was the way to go? Sigh. We're trying to drive users away, right?
Actually the old cached shaders should have been rejected by the updated Mesa. The fact that they were not is probably another bug in Mesa and is currently being investigated. Deleting the cache manually is a way to get it fixed right now. Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 9 Feb 2018 12:59:31 +0100, Lars Marowsky-Bree <lmb@suse.com> wrote:
On 2018-02-08T10:40:35, Luca Beltrame <lbeltrame@kde.org> wrote:
Mesa wrote broken caches, but you don't notice when they are written, but when they are read back (program restarts etc.). That's why even after the update you have to remove the cache: the crashy data has been already written to disk.
And someone decided that manual intervention instead of fixing the programs to detect this and clean it up automatically was the way to go? Sigh. We're trying to drive users away, right?
TumbleWeed is bleeding edge. I hope you are aware that problems may arise. If you want automatic fixes, stick to Leap. That said, this problem was more intrusive that the other problems in the last 6 months as it prevents users to work at all. You need strong nerves to not start cursing. Noone ever tells novices to use TW (at least I hope so) For me there are multiple reasons to use TW • Early detection of possible problems • Learning (in *ALL* areas of living on the edge): I think I learned more about Linux deep-stuff here on the ML and on IRC than when I was a comfortable openSUSE user (7.0 .. Leap-43.3) • Newest (versions of) tools • Newest kernel and devel-env to test bleading-edge perl5 development against • FUN! I think I'm just masochistic enough to enjoy the occasional throwback. That said, I might not always like what I see changed, but at least I know in advance it is changing and I know what to do when things turn nasty in production (or test) environments. I'm not a fan of systemd either, but I learn to live with it. This is not a battle I choose to fight in. As long as my (Plasma) desktop shows all I need and my keys start the things I want, I am a pretty happy developer. And yes, manual intervation every once in a while is part of that happiness. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.27 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
On 09.02.2018 13:17, H.Merijn Brand wrote:
On Fri, 9 Feb 2018 12:59:31 +0100, Lars Marowsky-Bree <lmb@suse.com> wrote:
On 2018-02-08T10:40:35, Luca Beltrame <lbeltrame@kde.org> wrote:
Mesa wrote broken caches, but you don't notice when they are written, but when they are read back (program restarts etc.). That's why even after the update you have to remove the cache: the crashy data has been already written to disk.
And someone decided that manual intervention instead of fixing the programs to detect this and clean it up automatically was the way to go? Sigh. We're trying to drive users away, right?
TumbleWeed is bleeding edge. I hope you are aware that problems may arise. If you want automatic fixes, stick to Leap.
Your points are valid for sure. But at the same time Tumbleweed promised to deliver only stable Software. This usualy means released stuff, not Beta, not RC. Waiting for the official release *may* have prevented the Mesa18 Fallout. I love Tumbleweed for being bleeding edge while keeping a balance. In the last weeks I had the feeling some packagers are getting a bit overly confident to release early because openQA tells them *it works*. libreoffice RC => worked plasma 5.12 Beta => worked Mesa 18 RC => failed Next time we might not be so lucky to get 2 out of 3 right. my2cents, tomme -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2018-02-09T13:17:21, "H.Merijn Brand" <h.m.brand@xs4all.nl> wrote:
TumbleWeed is bleeding edge. I hope you are aware that problems may arise. If you want automatic fixes, stick to Leap.
I think this is unfair to the promise of Tumbleweed. I could understand how minor issues get past openQA, but a whitescreen after boot for a large portion of the user base deserves a second look as to how that slipped. (Yes, I know, it's FLOSS, so the result might end up implying that I need to do something myself and contribute, but so far I don't yet understand enough as to where ;-) Is that because openQA runs virtualized and not with actual hardware?
That said, this problem was more intrusive that the other problems in the last 6 months as it prevents users to work at all. You need strong nerves to not start cursing.
Well, I was able to eventually fix it locally (noticing how sddm broke, failing to figure out why, and switching to kdm). But I'd still like to understand the failure and process better.
• FUN! I think I'm just masochistic enough to enjoy the occasional throwback.
There's certainly that. But TW should also not be a dumping ground for unstable or untested code, and it shouldn't mean developers push without a local test. And maybe it means TW's release process should eventually evolve to include a canary release stage, instead of instant "everyone, everywhere"? Regards, Lars -- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2018-02-12 at 11:53 +0100, Lars Marowsky-Bree wrote:
On 2018-02-09T13:17:21, "H.Merijn Brand" <h.m.brand@xs4all.nl> wrote:
TumbleWeed is bleeding edge. I hope you are aware that problems may arise. If you want automatic fixes, stick to Leap.
I think this is unfair to the promise of Tumbleweed.
I could understand how minor issues get past openQA, but a whitescreen after boot for a large portion of the user base deserves a second look as to how that slipped.
There are multiple things playing together and so far, openQA indeed does not catch this kind of problem. One of the biggest issue why openQA does not catch it is that most tests are based on 'fresh installs' and 'upgrades from released openSUSE versions': the fresh install gets obviously a clean cache state, not causing the problem. The upgrade scenario comes from Mesa 17.0 and apparently does not trigger the caches to go beserk. Reasons are not totally clear just yet, as there is a reboot towards the end of the test, where we do add more program tests afterwards. But one thing we DO miss in openQA are non-autologin enabled installs. So we pass sddm only once on the very specific test for 'logout, get to sddm and try to log back in' -> we reach sddm only once.
(Yes, I know, it's FLOSS, so the result might end up implying that I need to do something myself and contribute, but so far I don't yet understand enough as to where ;-)
That's part of the problem of the issue: it is not fully understood: from what I gathered so far it seems to be an invalid play of Mesa invalidating the cache, and Qt not liking it, resulting in render errors.
Is that because openQA runs virtualized and not with actual hardware?
This can well be part of the equation - making it even harder to detect it with openQA
That said, this problem was more intrusive that the other problems in the last 6 months as it prevents users to work at all. You need strong nerves to not start cursing.
Well, I was able to eventually fix it locally (noticing how sddm broke, failing to figure out why, and switching to kdm). But I'd still like to understand the failure and process better.
so do I - and hopefully come up with an openQA test. so far, the best thing we found is 'it does not matter if Mesa changes version, a simple rebuild of it will be enough to trigger the error again, as the cache is validated/invalidated based on build_ids. And a rebuild is nothing I can guarantee not to happen (possibly changed deps)
• FUN! I think I'm just masochistic enough to enjoy the occasional throwback.
There's certainly that.
But TW should also not be a dumping ground for unstable or untested code, and it shouldn't mean developers push without a local test.
Rest assured, it's not seen as a dumping ground at all.
And maybe it means TW's release process should eventually evolve to include a canary release stage, instead of instant "everyone, everywhere"?
In short: you want to have 'Factory' back? I'm open to hear proposals; I know of at leats one user that regularly tests in parallel to openQA, before things 'hit the shelves' - and he did report issues in the past (which we used to block snapshots). Cheers Dominique
On Montag, 12. Februar 2018 12:04:32 CET Dominique Leuenberger / DimStar wrote:
I know of at leats one user that regularly tests in parallel to openQA, before things 'hit the shelves' - and he did report issues in the past (which we used to block snapshots).
Yes, and that very user was (for whatever reason) not bitten by this issue the time it appeared for most of the users, but one snapshot later. This time the clearing of the cache helped as for all others. However, after the updated Mesa was removed from the update channel, I was hit again by this issue (or another one), but then clearing the cache did not help and I made a fresh install (in order to test the fresh storage-stack). Cheers, Robby.
Cheers Dominique
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Robby Engelmann <robby.engelmann@igfs-ev.de> [02-12-18 09:25]:
On Montag, 12. Februar 2018 12:04:32 CET Dominique Leuenberger / DimStar wrote:
I know of at leats one user that regularly tests in parallel to openQA, before things 'hit the shelves' - and he did report issues in the past (which we used to block snapshots).
Yes, and that very user was (for whatever reason) not bitten by this issue the time it appeared for most of the users, but one snapshot later. This time the clearing of the cache helped as for all others.
However, after the updated Mesa was removed from the update channel, I was hit again by this issue (or another one), but then clearing the cache did not help and I made a fresh install (in order to test the fresh storage-stack).
not that it makes any diff now, but I also got "hit" again when Mesa reverted, but removing the cache items again solved it and the solution has persisted since. rm -rf ~/.cache/qtshadercache /var/lib/sddm/.cache and I have amd/intel/nvidia graphics cards on various affected boxes. the nvidias all using NV....run drivers, and all on Tw. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2018-02-12 at 09:50 -0500, Patrick Shanahan wrote:
* Robby Engelmann <robby.engelmann@igfs-ev.de> [02-12-18 09:25]:
On Montag, 12. Februar 2018 12:04:32 CET Dominique Leuenberger / DimStar wrote:
I know of at leats one user that regularly tests in parallel to openQA, before things 'hit the shelves' - and he did report issues in the past (which we used to block snapshots).
Yes, and that very user was (for whatever reason) not bitten by this issue the time it appeared for most of the users, but one snapshot later. This time the clearing of the cache helped as for all others.
However, after the updated Mesa was removed from the update channel, I was hit again by this issue (or another one), but then clearing the cache did not help and I made a fresh install (in order to test the fresh storage-stack).
not that it makes any diff now, but I also got "hit" again when Mesa reverted, but removing the cache items again solved it and the solution has persisted since.
There were no Mesa reverts. What did happen is a 'release number decrease' as the same code built in :Update is '1 ahead of non-Update' (which is good, as this helps us ensure Update is 'higher'); once the update is merged though into the mainline tree, the :Update is emptied, and the 'count' reset to what is in mainline. It was 100% identical sources (but still different build id, which is what makes Mesa discard the cache and Qt falling on the nose for not recompiline the Gl shaders) Cheers Dominique
* Dominique Leuenberger / DimStar <dimstar@opensuse.org> [02-12-18 22:13]:
On Mon, 2018-02-12 at 09:50 -0500, Patrick Shanahan wrote: [...]
not that it makes any diff now, but I also got "hit" again when Mesa reverted, but removing the cache items again solved it and the solution has persisted since.
There were no Mesa reverts. What did happen is a 'release number decrease' as the same code built in :Update is '1 ahead of non-Update' (which is good, as this helps us ensure Update is 'higher'); once the update is merged though into the mainline tree, the :Update is emptied, and the 'count' reset to what is in mainline. It was 100% identical sources (but still different build id, which is what makes Mesa discard the cache and Qt falling on the nose for not recompiline the Gl shaders)
tks, I understand that. just happened in such a way to make it look different. tks for you many efforts. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I just did zypper dup from 20171228 to 20180209. When the process is complete the desktop is unresponsive -- nothing can be launched and the only option is using the big red switch. The result is a black screen with cursor arrow @ reboot. I have tried every hint in this and all the other threads regarding this subject and none of them does any good. I have noticed that rpm has issues; particularly issues with several libopus* libraries. And the whole process starts with a selection of what to do with a gstreamer library. I don't know if any of this is relevant to the plasma issues or not. So whatever is wrong is not fixed. Since I presume there are very few users who will be updating from the referenced version I'm not sure it's worth much effort to find and fix what is wrong. So, like Robby, I plan to download the latest image and try an install. It is at this point I really, really wish the old capability to "import mount points" was present and worked in the partitioner!
However, after the updated Mesa was removed from the update channel, I was hit again by this issue (or another one), but then clearing the cache did not help and I made a fresh install (in order to test the fresh storage-stack).
Cheers, Robby.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I have tried every hint in this and all the other threads regarding this subject and none of them does any good. if your saying deleting the caches doesnt work - *dont reboot* - delete from tty1 return to tty7 and login. if persists ctrl-alt-backspace*2 and try again. I had same issue with delete-reboot-black screen -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
For me plasmashell keeps crashing even after removing "~/.cache" and "/var/lib/sddm/.cache". On a different user account ,on the same machine, that I haven't used since the issues with Mesa everything works fine, so I thought about removing my "~/.config" and "~/.local" folders but that didn't help either. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Chuck Davis <cjgunzel@gmail.com> [02-12-18 22:48]:
I just did zypper dup from 20171228 to 20180209. When the process is complete the desktop is unresponsive -- nothing can be launched and the only option is using the big red switch. The result is a black screen with cursor arrow @ reboot.
I have tried every hint in this and all the other threads regarding this subject and none of them does any good.
maybe and maybe not, but "every hint" is not very helpful to anyone who cannot see your system and screen.
I have noticed that rpm has issues; particularly issues with several libopus* libraries. And the whole process starts with a selection of what to do with a gstreamer library. I don't know if any of this is relevant to the plasma issues or not.
those are multimedia files, afaik have nothing to do with your display.
So whatever is wrong is not fixed. Since I presume there are very few users who will be updating from the referenced version I'm not sure it's worth much effort to find and fix what is wrong. So, like Robby, I plan to download the latest image and try an install. It is at this point I really, really wish the old capability to "import mount points" was present and worked in the partitioner!
and we have no idea what you did or what is wrong from your description. do you have control of the tty's? what is your system, video card/driver, did you have any errors? do you have odd repos? you noted that rpm has issues, but ??? it really sounds like you have a local issue, and some frustration. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Il giorno Mon, 12 Feb 2018 12:26:08 +0100 Robby Engelmann <robby.engelmann@igfs-ev.de> ha scritto:
However, after the updated Mesa was removed from the update channel, I was hit again by this issue (or another one), but then clearing the
There are actually two issues. One was fixed in Mesa, the other is a Qt bug which hits specifically the i965 driver: - Downstream report at https://bugzilla.opensuse.org/show_bug.cgi?id=1080578 - Upstream report at https://bugreports.qt.io/browse/QTBUG-66348
participants (13)
-
Arjen de Korte -
Chuck Davis -
Dominique Leuenberger / DimStar -
H.Merijn Brand -
Lars Marowsky-Bree -
Luca Beltrame -
Michal Kubecek -
Michal Srb -
nicholas cunliffe -
Patrick Shanahan -
Robby Engelmann -
Thomas Langkamp -
Τάσος Καραγκούνης