Bugzilla – Bug 408252
can't open /dev/sr0 for writing (can't burn CD / DVD)
Last modified: 2009-10-09 20:38:23 UTC
Impossible to write to dvd in device.
Created attachment 228028 [details] wrprot
The message states: setup can arrange this for you. No setup found.
Created attachment 228047 [details] dmesg output
This doesn't mean DVD is mounted readonly, this says that user has not permission to write to /dev/sr0. What is output from "ls -l /dev/sr0" on my workstation it shows "brw-r----- 1 root disk ..." so it looks like only root is able to burn DVDs.
oddball@AMD64x2-sfn1:~> ls -l /dev/sr0 brw-rw----+ 1 root disk 11, 0 jul 19 18:33 /dev/sr0 oddball@AMD64x2-sfn1:~> oddball@AMD64x2-sfn1:~> getfacl /dev/sr0 getfacl: Removing leading '/' from absolute path names # file: dev/sr0 # owner: root # group: disk user::rw- user:oddball:rw- group::r-- mask::rw- other::---
same issue here with openSUSE 11.0 and latest k3b.
problem still available in rc1. normal user have no rights to burn a cd.
<burndusk> the solution to this was to add the right policy to policykit.conf for the users i want to have burn access
i found to add disk, cd-rom to user via yast>security and users>user and group management, worked out ok, but i just realise this is for 32bit, but sorry can't find that bug report :)
Got the same problem on two machines since updating these from 11.0 to 11.1. I'm kind of sure that the problem didn't existed in 11.0! To proof that I started the 11.0 gnome live cd. There I had acces to my DVD writer as standard user linux without changing anything! The difference I realised between the 11.0 boot cd and my 11.1 systems was that /dev/sr0 on the 11.1 machines didn't hat that acl entry user:myuser:rw- Instead the group permission on the 11.1 machines was set to rw. On the 11.0 live cd it's just r. As a continuous workaround I added setfacl -m 1000:rw /dev/sr0 to /etc/init.d/boot.local 1000 is my user-id. Please fix this soon. Other people may not be so smart, as the people posting here! If you need further information, please tell me! Thanks colAflash
*** Bug 460791 has been marked as a duplicate of this bug. ***
The ACL is lost when I insert a CD and KDE4 mounts it... not sure if it happens with other desktops. Before inserting a CD: $ getfacl /dev/sr0 getfacl: Removing leading '/' from absolute path names # file: dev/sr0 # owner: root # group: disk user::rw- user:reddwarf:rw- group::rw- mask::rw- other::--- After inserting a CD: $ getfacl /dev/sr0 getfacl: Removing leading '/' from absolute path names # file: dev/sr0 # owner: root # group: disk user::rw- group::rw- mask::rw- other::--- If after the ACL is lost I manually readd myself with 'setfacl -m u:reddwarf:rw /dev/sr0' the problem isn't repeated. Now I can insert a CD without losing the ACL... until the next reboot.
same problem here.
Same problem here. The following workaround helped in my case: * make your user a member of "cdrom" group * create /etc/udev/rules.d/99-my.rules file with the following entry: KERNEL=="sr*[0-9]", GROUP="cdrom", MODE="0660" * reboot The udev rule above ensures /dev/sr0 is always owned by root:cdrom and writable/readable for cdrom group.
Exactly the same problem ! Like #12, ACL are modified when inserting a blank cdr or dvdr. I added my user in group "disk" but it shouldn't be the case...
At http://forums.opensuse.org/applications/multimedia/402631-permissios-dev-caused-failure-play-video-dvd.html#post1914309 the user "nvliet" reports the same problem with Gnome. It could still be two different problems, but seems the problem isn't related to KDE but to... HAL? PolicyKit? udev? everything is the same to me ;-) CCing lnussel since it appears in the latest PolicyKit changelogs, sorry if the problem isn't related to you.
Created attachment 262330 [details] strace output I have straced the system dbus-daemon, the hald-addon-storage helper for my DVD Burner and the hald-runner. The output is indicating, that the DVD Burner is categorized as removable block medium with a blank DVD-R medium inserted. For this category user access is not allowed in the openSuSE PolicyKit configuration. I could reproduce, that my user permission disappeared as soon as I have inserted a blank DVD-R into the burner while logged in. When the blank DVD-R was sitting in the Burner while logging in, I had user permissions on the device (/dev/sr0) after login. I have changed the file /usr/share/PolicyKit/policy/org.freedesktop.hal.device-access.policy and have allowed access to removable block devices for active_session and inactive_session. After that change my user permission did not disappear on inserting a blank DVD-R into the burner while logged in.
Created attachment 262331 [details] patch for /usr/share/PolicyKit/policy/org.freedesktop.hal.device-access.policy This patch allows user access to removable block devices.
The ACLs should have been set. reassigning to Ludwig who knows more.
I see the same here sometimes too, for the first time a user session is established. The media change event clears the properly assigned ACL. But, it seems not to happen if you log out and log in again, then the ACL is preserved properly. I guess *something* in the stack calls chmod/chown, which it shouldn't do, and resets the assigned ACL.
Same problem here.
Comment on attachment 262331 [details] patch for /usr/share/PolicyKit/policy/org.freedesktop.hal.device-access.policy This patch seemed to work for my 11.1 installation.
*** Bug 461322 has been marked as a duplicate of this bug. ***
Same problem with openSUSE 11.1 (x86-64) and GNOME, both Brasero and native burning. Problem resolved with change to PolicyKit as described by #18.
*** Bug 462704 has been marked as a duplicate of this bug. ***
Just add user to "disk" group, then re-login.
*** Bug 463000 has been marked as a duplicate of this bug. ***
*** Bug 463091 has been marked as a duplicate of this bug. ***
*** Bug 462265 has been marked as a duplicate of this bug. ***
I can confirm the behaviour described in #20. After logging out and logging in again, all ACLs are preserved/set properly.
*** Bug 462043 has been marked as a duplicate of this bug. ***
*** Bug 461614 has been marked as a duplicate of this bug. ***
Default policy for removable devices is "no access" and default policy for optical devices is "access". Could the two maybe interact?
Interesting side note: A few minutes after inserting a video DVD, the permissions sometimes fix themselves. Besides that, even with the patch from comment #18, there is a short time period where no access to the device is possible. This can be triggered by burning a DVD ISO image with k3b and selecting the "verify" option. K3b accesses /dev/sr0 to check whether a medium is inserted, but as long as no medium is inserted, the permissions are still wrong. That's probably a design bug in permission handling. DVD burning software needs access to the device even if no medium is inserted, i.e. a media ejection/change event should never reset the ACLs.
Another interesting side note, which might be related to the previous one (#34): When using grip tho create mp3 files from a CD the following behaviour is observed (as long as the user is not member of group "disk"): After initial insert of a CD grip "sees" the tracks on the CD and is able to play them. As soon as you press the "rip" button (rip configuration "grip(cdparanoia)") connection to the CD is lost completely and grip does not "see" the tracks any more.
Same problem with Gnome(Brasero and Native). Similar behavior in reading DVD Video with Xine. It writes that /dev/dvd (symlink to /dev/sr0) is unavailable. I manualy assign read-write permission to the user - it works. After reboot, the rights are reset to default.
Seems HAL erroneously removes the ACL after the media change detection: Run started ... '/usr/lib64/hal/hal-acl-tool' ... 3410: attempting to get lock on /var/run/hald/acl-list 3410: got lock on /var/run/hald/acl-list 3410: adding ACL's for /dev/sr0 3410: invoking 'setfacl -x u:2702 /dev/sr0' 3410: releasing lock on /var/run/hald/acl-list
*** Bug 463432 has been marked as a duplicate of this bug. ***
*** Bug 460952 has been marked as a duplicate of this bug. ***
*** Bug 461301 has been marked as a duplicate of this bug. ***
May I ask why we have such a desastrous bug again? Am I the only one doing bug hunting on real machines and not in crippled VMs? But even so: I did not test CD/DVD access, shame on me. This, like the crippled wifi drivers is SERIOUSLY affecting the popularity of our distro, and I am really starting to feel frustrated explaining issues like that to colleagues and friends. Bugs like this should be a ship stopper, and it was opened in july. I can not believe this.
I was doing testing on a real machine and had this problem with beta 4 & 5 but I wrote this problem off as a bad CD drive because the one I tested with was in storage for so long no one knew if it worked. It wasn't until I installed this on a machine that I knew has a working burner that I realized it was a real problem. I agree that problems like this should be a ship stopper or something so they don't get through the testing phase and cause problems like this.
I can't believe this bug has been in this release for this long. I looked at /dev/sr0 and found that it is set to group "disk" and only owner and group have read/write access. "Others" is completely blocked. My fix was just to add group "disk" to my userid. I didn't even have to reboot (just make sure you restart K3b). Further, it is a permanent fix (at least for each userid set).
Regarding comment #43, #26 and others that suggest to add user to "disk" group... I don't think it's a good idea, since it also grants access to hdd devices.
*never* add regular users to group disk.
What do you expect? Users are waiting more than five months for a fix and this is something that hinders your work. Apart from being a bit embarrasing that a bug like this could slip through. Anyway, if you do not communicate an official workaround and/or that his bug will be fixed in the short term, users come up with their own workarounds because they need to work with their hardware. It's not some fancy eye-candy that openSUSE is failing to deliver. You should really increase your communication with the community for such "popular" bugs.
Problem is caused by commit e72cb4437700b4b34ac5c6de0e30dff8bb0ed89e which adds the "removable-block" access control type to volumes. As long as a CD drive (e.g. /dev/sr0) as no medium inserted hal only has one device object in it's tree and that is /dev/sr0 with access control type "cdrom". If one inserts a medium that device obtains a child with the same device name (/dev/sr0) and with block.is_volume set. That one gets access control type "removable-block". I guess the behavior is undefined if the same device appears multiple times with different access control types. The fdi file needs to be modified to not set "removable-block" on unpartitioned disks where the drive has access control and the same name as the volume.
Thanks for clarifying that the "disk" fix is not advisable. Yet, I am asking myself how you think this should go on. This is an absolute ship stopper bug and yet it didn't even show up in the most annoying bugs during testing phase. Right now, there is not even a note on news.opensuse.org. Please, someone from Novell or the openSUSE team, step forward and put something online so that users don't walk away in their frustration. For the time being, I don't see any other solution than to add users to disk, since burning is essential here in our lab..
(In reply to comment #46 from Sven Burmeister) > What do you expect? Users are waiting more than five months for a fix Whatever the original cause for the bug report was, it was not the problem we see now. The current problem was introduced on Nov 27th.
Of course, it it still the same problem: Standard users will not be able to use their CD and DVD drives as they thould be able to. Don't defeat the problem! This doesn't gain much popularity to SuSE! The problem is just too obvious!
> *never* add regular users to group disk. What would you suggest for a quick workaround until the bug is fixed? What do you think about this: Create a file e.g. '99-udev-default.rules' in /etc/udev/rules.d with 99-udev-default.rules:KERNEL=="sr0", NAME="%k", MODE="666" That makes /dev/sr0 permissions 666 from boot. Is that advisable?
(In reply to comment #48 from Daniel Mader) > Thanks for clarifying that the "disk" fix is not advisable. Yet, I am asking > myself how you think this should go on. This is an absolute ship stopper bug > and yet it didn't even show up in the most annoying bugs during testing phase. I guess the problem was introduced too late to be properly rated. > Right now, there is not even a note on news.opensuse.org. > > Please, someone from Novell or the openSUSE team, step forward and put > something online so that users don't walk away in their frustration. People are just returning from Christmas vacation. There should be an online update soon. > For the time being, I don't see any other solution than to add users to disk, > since burning is essential here in our lab.. That would be equivalent to root permissions. Here are some possible workarounds: 1. remove the paragraph that adds the 'removable-block' thing from /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi 2. alternatively grant access to removable storage devices to individual users: # polkit-auth --user joe --grant org.freedesktop.hal.device-access.removable-block 3. or allow users in active local sessions access to removable storage devices: # echo "org.freedesktop.hal.device-access.removable-block auth_admin_keep_always:yes:yes" >> /etc/polkit-default-privs.local # set_polkit_default_privs You may want to revert that latter two changes once a fix is released.
I had this problem way back with 11.0 alpha at some stage but it never made it to bugzilla. I solved the problem of having to reset permissions for /dev/sr0 and /dev/sg0 after every boot by adding user and users to the /dev/sr0 line in fstab and I have never had a problem since. My sr0 line in fstab :- /dev/sr0 /media/dvd auto user,users,auto 0 0 Hope this sorts something out.
In answer to comments #46 and #48: this is of course a serious problem, it has been there for a long time, that's true. I am part of the community, and I don't see users running away for this problem, as I did not see anyone reminding this bug during the test phase. So I would define this situation a shared responsibility, at least :-) Now, the problem is here, let these guys work on it and release a patch without having them to answer to our complaints. It is already pretty clear to them that the problem is serious. Regards, Alberto
(In reply to comment #54 from Alberto Passalacqua) > In answer to comments #46 and #48: this is of course a serious problem, it has > been there for a long time, that's true. I am part of the community, and I > don't see users running away for this problem, as I did not see anyone > reminding this bug during the test phase. So I would define this situation a > shared responsibility, at least :-) > > Now, the problem is here, let these guys work on it and release a patch without > having them to answer to our complaints. It is already pretty clear to them > that the problem is serious. > > Regards, > Alberto > The community did do it's job, it reported the issue. It's the developers job to mark priority, assign, review and fix the bugs on a release. Pestering the developers really shouldn't be a job for the community. Re-evaluation of bugs is again the responsibility of the devels and priorities changed if needed. Nothing more then generating a list of outstanding bugs should be needed to spot issues before release. Also for many people the bug wasn't discovered simply because they could not even install the earlier Alpha's and RC's. This bug is the perfect example of why installation issues have to be addressed as soon as possible. Installer issues should be a #1 priority as if a person cannot install the product they cannot test any further.
There is a significant difference between "pestering" and "reminding". You have been around for the whole development cycle, you know the time was very limited and developers were under pressure for 11.1, so it might happen that they lose track of some problem. A lot of developers are on IRC all the time and read ML. Bringing these problems at their attention there if you think no attention is paid to the bug report is simple, and can avoid issues like these to reach the final release. We (community) are here also for that.
And who is putting that pressure on the devels on that timeline? It isn't the community, it's Novell and as such since the community cannot change the timeline it is the responsibility of the people that enforce that timeline to make sure that the QC is maintained. Mailing list should actually be abolished as it offers no steady way of tracking an issue IMHO and does not sync up with bugzilla where bugs can easily be tracked in many fashions. This is why databases were invented so you don't have to rifle though hundreds of thousands of records before finding the right one. If you offer bugzilla as a way of reporting bugs then it should be used as well for determining what bugs need to be fixed. If it isn't utilized in that fashion then the net worth of even offering bugzilla is 0. Reporting bugs in mailing lists is extremely unreliable.
I can only fully agree with comment #57 and #57: we have a track record of offering pretty much non-installable alphas and even betas, at least for the average user. This definitely defeats the purpose of a devel snapshot for widespread testing. Also, as said, I cannot understand why we have to follow such tight schedules. A distro should be released only when it's finished, not when some release plan says it's about time. And finally: I have to get some work done besides the time that I spend for the project, so I won't be able to also follow the MLs. Bugzilla must be enough, or I will have to consider it as a waste of my time.
Exactly Daniel, what I think bugs people most about this issue isn't the actual bug itself but how it demonstrated the failure of how bugs are presently being handled. People would like to see a working solution that avoid these obvious pitfalls in the future as it is at the heart of the real issue. The current development model is broken and what has to be addressed is how to fix that first so one can improve and minimize things like this happening in the future.
That is something for the mailinglist though, e.g. opensuse-project.
Hi Daniel, excluding the fact that betas were all installable during 11.1 cycle, because I tried them personally, and I don't consider myself a Linux guru, the schedule is decided on the basis of Novell needs (the openSUSE developers work also on other Novell products), upstream releases and other factors. OpenSUSE has a release cycle of six to eight months, and the next release schedule is being widely discussed on the opensuse-factory mailing list. It is quite unrealistic to ask for a distribution "released when ready": it would be an endless process, with outdated software, which is not what openSUSE users want. Bugzilla should be enough, but if you look at the number of fixed bugs before release you will understand that it is perfectly possible to miss some of the problems. The role of a community is also to check if a bug was fixed and eventually to poke the developer if it is the case. Time is not a problem, because the time spent to complain here is longer that the time required to enter IRC and ask there in the #opensuse-factory channel, where many developers can be found. Don't get me wrong, I know there is a lot of room for improvements in the testing -> fixing process. But at this point we know the bug will be fixed soon. @Deanjo: I agree the process is not perfect. I am looking forward to some realistic proposals on some mailing list where I can read what you suggest. If you have done that already, please link me to it. :-)
*** Bug 464165 has been marked as a duplicate of this bug. ***
The fix with changing of permissions for /dev/sr0 did not work for me. I had to add myself to groups audio, cdrom and disk (openSUSE 11.1, KDE4), I also have problems with playing Audio CDs (no right to play it... - fixed by adding to groups). And KDE4 does not announce the media correctly: when I insert Audio or blank CD, I can only "download pictures with digiKam"...
Please stop that kind of discussion in bugzilla. Bugzilla is about bugs and not a forum or mailing list. It helps nobody if you discuss not bug related topics in bugzilla. Thanks!
(In reply to comment #64 from Danny Kukawka) It would be nice for you to tell everyone, that you're assigned for this bug and _working_ on it. :)
1) I got this bug assigned while I'm (and I'm still) on vacation. 2) I work on this bug as soon as it's set to ASSIGNED 3) This kind of discussion don't help anyone. Please remember: we are not sitting 24/7 in front of bugzilla (especially not at the turn of the year).
Created attachment 263818 [details] Patch candidate Please check if this patch for /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi fixes the problem. You need to restart hal after patching the fdi file.
Created attachment 263903 [details] patch candidate 2 doesn't work. I can't remember a way of comparing two properties for equality from the top of my head (to compare whether the device file is the same as the parent) so we could instead check if the volume is a partition. In that case the volume and the parent have the same device file.
Considering the complaints about inability to burn CDs due to this bug I wonder whether scsi generic access for cdrom drives is still required for burning as acls for those where not affected.
I have tested the last patch and it works on opensuse 11.1 x86 edition. The iso for the 64bit edition for my my other pc was burned succesfully. thanks :-)
I think we may have a winner the second patch candidate works on my openSUSE 11.1 64 bit machine and just turned out a audio machine. The only problem I find with the second patch is that the Device Notifier in KDE 4.1.3 is not made aware of CD or DVDs no matter if they are blank or not, this kind of through me off at first because I thought that the patch wasn't working until I opened K3B.
Can someone please provide the full outpuf of lshal with and without the last patch?
Created attachment 263941 [details] lshal on machine with patch If using different machines will work I can provide the lshal without the patch here in a bit. As for the lshal with the patch here is what is on my current machine.
Created attachment 263942 [details] lshaloutput on machine without patch In case different machines will work for this I will remove the NEEDINFO, but if it won't then please remove it.
bug #462623 seems related also please can anyone confirm and mark as a duplicate.
*** Bug 462623 has been marked as a duplicate of this bug. ***
*** Bug 462966 has been marked as a duplicate of this bug. ***
This bug is not specific to k3b
*** Bug 461630 has been marked as a duplicate of this bug. ***
*** Bug 465003 has been marked as a duplicate of this bug. ***
I'm not sure how relevant this info is, but I'll add my following recent burning experience on 11.1. On an old K7 with hp dvdwriter 100i, upgraded from 11.0 to 11.1/gnome: 1. Nautilus file manager: after selecting files and right click, the normal option 'send to burner' wasn't seen on the context menu as before 2. Gnome CD/DVD-burner window: added some data, but it failed to erase existing data on DVD+RW disks 3. Brasero 0.8.4 did a logout/login first, then it was able to find the dvd+rw device and erase existing data on dvd+rw disks, and next burn new content to the disk. Though it ejected the disks after burning, an error message was repetedly encountered telling that it couldn't eject the disks. dbus error, inappropriate ioctl for the device. Had to logout to quit these messages and continue. 4. NeroLinux 3.5.2 on 11.1 x86_64 Erased existing dvd+rw disk data quite ok. I have also burned some Blu-ray BD-R 50GB disks quite ok.
Sadly, this sort of thing has become typical since Novell took over Suse. There are managerial deadlines set for releases without QA being in place to make sure the "product" is ready to ship. I recall finding a comment with respect to opensuse 10 release that read something like: "bugs will be fixed by dec 6". Someone seems to confuses themself with the Allmighty. Bugs will be fixed when they have had enough time and developer manpower given to them. Belicose management commandments don't frighten bugs away. If management decide a release has to be out in time for Santa to deliver it they need to ensure sufficient resources are made available to finish it. I first got into Suse around 9.2/9.3 , as an everyman distro it was great. I recommended it to several friends who installed and enjoyed it. I kept a suse partition running to support them. I first had doubts about Suse when openSuse 10 came out. Despite the very slick paint job, the engine had major issues. The remaster fiacso was the first sign of bad management. Then there was mounting flash devices O_SYNC leading to early death of many USB storage devices which were nowhere near as cheap and expendable at that time. I lost interest in suse and hoped it would all sort itself out later. I am now looking for a non guru distro to recommend so I installed 11.1 , I was very, very impressed with the install process. Very polished and let me make a several mods to the standard installation without any problems. Sadly, once again, the first impression was not a lasting impression. It seems that unrealistic release deadlines are still being imposed on an under resourced project. All this PolicyKit stuff is simply incomplete and insufficiently tested. All the fancy graphics are nice but this sort of issue is a show stopper. I'm just not prepared to start hacking as soon as I have installed to get basics like this to work. Unbelievable. I'll check in again around suse 12.0 or suse 13.0 in the hope that Novell manage to finish a product before releasing it. In the meantime, good luck.
If you know that opensuse is not up for you, why would you install it and not wait some months before doing so? That does not make sense to me. Anyway, this issue now has a patch that fixes it and which will be shipped. Please send your opinions about the opensuse project to the opensuse-project mailinglist and not this bug-report.
Clearly I installed it because I did not know what state is was in. I installed to evaluate, hoping that 10.x was just adjustment troubles to the new management structure. Sadly it seems german rigour and quality have given way to corporate marketing. I'll take up your suggestion of the ML. regards.
I have to say it again (as in comment #64): please stop this kind of discussion! Immediately!!! This is bugzilla and not some kind of ML or forum. This tool is about bugs and not about some kind of political discussion. This kind of comments make it hard/impossible to work on the bug!
What is wrong with the groups approach to this sort of media? Clearly disk group is not appropriate and was suggested by someone who did not realise what it represented. However, The tried and tested linux method is add the user to audio if he requires audio, video if he is to view video formats, cdrw if he is to be allowed to burn cd etc. Does this no longer work on suse?
Thanks for the output, Adam. Danny: Comment 73/74. Danny, if you are convinced that this is the fix, when do you expect to have a package ready?
Despite all the misgivings, I will use the "disk" workaround until the problem is fixed. I, too, would like to know when the fix is published so that I can remove the workaround.
*** Bug 465184 has been marked as a duplicate of this bug. ***
(In reply to comment #87) > Thanks for the output, Adam. Danny: Comment 73/74. > Danny, if you are convinced that this is the fix, when do you expect to have a > package ready? No problem, any clue if the little problem with Device Notifier in KDE4 will be fixed with the soon to be patch, or will this be addressed later?
I also ran into this - not while trying to burn, I instead tried to extract an audio cd. So I conclude that a default user has no rights(!) to read from removable media? The fix from #18 worked for me. As this is a real bad bug, may I ask what is currently preventing the release of a patch? Any KDE4 notifier would be a problem with far less importance if it would fix the greater issue.
This bug is the most massive loss of functionality in many many months of Linux distributions that I am aware. It is on the same level as our infamous USB bug of 10.0 which never received a fix, iirc. Weeks pass by without any sign of improvement. There is not even a simple *comment* here announcing when -- and even *if* -- there will be a patch. (Let alone anything on the official openSUSE websites. Not even a trace of this issue could be found there... How ignorant.) Given its annoyance factor, the time the resolution of this issue is taking is deeply embarrassing. And it makes a fool of our community model: without proper communication this is a waste of time for the many of us who actively report in the faithful believe it changes anything and potentially speeds up fixing time.
Yes, there will be a patch ASAP. Danny was not available until now and will be back Monday.
YOU can get the upcoming updated package here until it's available via YOU: http://download.opensuse.org/repositories/home://dkukawka/openSUSE_11.0/
Could you please take the time to mention which package(s) that would be? I mean, it's only 5 days from the creation of the most recent packages in that repo, and it can well take another two months until YOU finally decides it is about time to release something... Thank you in advance!
There is a typo in comment 102. The correct URL should be: http://download.opensuse.org/repositories/home://dkukawka/openSUSE_11.1/
hal is now also in the update test repo: http://download.opensuse.org/update/11.1-test/ Any positive feedback that this now fixes the cdrom buring problem?
Works OK here for me on x86_64 with hal-0.5.12-39.1.x86_64.rpm and hal-32bit-0.5.12-39.1.x86_64.rpm installed from http://download.opensuse.org/repositories/home://dkukawka/openSUSE_11.1/x86_64/ I would greatly appreciate a quick official fix delivered via YOU! Thanks in advance!
*** Bug 467928 has been marked as a duplicate of this bug. ***
Just installed rpms from update/11.1-test/ repository, did rchal restart and dvd-writing works fine now.
Works for me, too.
lets resolve as fixed then.
Update released for: hal, hal-debuginfo, hal-debuginfo-32bit, hal-debuginfo-x86, hal-debugsource, hal-devel Products: openSUSE 11.1 (debug, i586, ppc, ppc64, x86_64)
*** Bug 458091 has been marked as a duplicate of this bug. ***
*** Bug 459670 has been marked as a duplicate of this bug. ***
*** Bug 468096 has been marked as a duplicate of this bug. ***
*** Bug 468293 has been marked as a duplicate of this bug. ***
(In reply to comment #41) > May I ask why we have such a desastrous bug again? Am I the only one doing bug > hunting on real machines and not in crippled VMs? But even so: I did not test > CD/DVD access, shame on me. > > This, like the crippled wifi drivers is SERIOUSLY affecting the popularity of > our distro, and I am really starting to feel frustrated explaining issues like > that to colleagues and friends. > > Bugs like this should be a ship stopper, and it was opened in july. I can not > believe this. I agree completely with you; these things drive people back to microsoft; (take a look af beta-7; all linux distros can learn from it;) After replacing cdrtools and dvd+rw-tools with the original in openSuSE 10.2 I successfully made a daily back-up onto blu-ray discs. In 11.1 . . .well, disaster (mind you NO harware changes). By teh way: every 2 or 3 days a complete freeze of 11.1 I have to reset the pc. I never experienced that with SuSE before.
Top Linux executives and developers have been bought out by Microsoft to sabotage Linux development. That's why critical bugs are assigned to employees on holidays, and often never corrected in years, like the Ubuntu bug preventing emptying the trash under certain conditions. Most opensource software projects stall since years and many actually deteriorate their products, like KDE 4. In these days of rampant fraud on every level corruption and deception is organised top down. Mass media and Google are heavily censored so the cover will blow late.
Philippe - if you don't help test OpenSUSE before it is released, then you will inevitably find bugs after it is released that we don't have time to fix in the release [ duh ;-]. Of course the good news is that the 'swamp' stuff above means that an on-line update is winging it's way to you through the update process [ I think ]. I would strongly suggest that you contribute testing for the 11.2 cycle ahead of time - one of the best ways is to run Factory & file bugs against that - try turning up to some of the open OpenSUSE team meetings too - you'll soon find out that if there is any conspiracy - it is to make the best OpenSUSE possible :-)
This is getting out of hand here, this is still a bugtracker, it's fixed and that's it. If there is anything left to discuss the way it has been handled or to spawn conspiracies, please take it to some mailing list, blog about it or anything. So please take this to another place as this is not a bug anymore...
not a bug ? not a bug ?? Please tell me how it is that in 10.2 i could daily back-up to blu-ray and in 11.1 not ! I'm desperately seeking for a solution: - could it be due to old udf ? - could it be due to wrong cdr-tools (see the real author on that !) - could it be due to libc.so.6 ? - could it be due to .. . . ? Well, I am not an expert but I am trying to solve it, be it as mentioner of possible causes. Latest nero for linux burns Ok, latest growisofs (use-the-force-luke was the solution in 10.2)burns it Ok but 11.1 won't let me (root) mount it. One must -t the filesystem, well udf: to no avail, iso9660 to no avail. This must be a bug or I will downgrade to 10.2 (like vista-users do to XP)
@Michael Meeks: you are in part right with your point about testing. But honestly i do not think that community testing can replace at least a basic internal quality assurance. This issue as various others in openSUSE 11.1 are of such a bad level that should have been found during an simple run of internal test cases. I'm speaking of this problem, of huge memory leaks in beagle, of X instabilities and system freezes at boot or after some days of operation. For these problems you, Novell, can't simply rely on the community and think for good. The community is simply not prepared, and not big enough to do that. Moreover learning is not easy because the documentation on the wiki is missing, which makes the learning process too steep and long. What you are asking (running alphas) is not possible for many: our alpha releases are not usable for everyday use, and in most of the cases they are barely instalallable. In the current situation the most you can expect is some testing in virtual machines of the early pre-release versions and some testing of the final steps (RC) on real hardware by some users with a certain experience. From this to hoping they will find bugs as in systematic testing, there is a huge difference, and systematic testing of key elements is hardly doable at a community level, at least if not coordinated and planned in some way. I think one big change is necessary if you want to rely on the community so much, which is a complete revision of the patch policy. OpenSUSE is still tied to the obsolete idea of releasing security only fixes, which is OK if the initial release is of good level. This has not been not regularly happening since openSUSE was started, and we had often had releases that in principle could be fixed and improved significantly with a relatively small number of updates, which were not done at all, or not done timely, left to wait for approval for months, with the result that users left or were very frustrated. If this is not going to happen, we will always have releases full of problems for their whole lifecycle, and unhappy users. @Karsten Konig: the discussion started here. I know it is off-topic, that it might not be the right place, but for once nobody will suffer for a few post that eventually might bring to a solution to avoid these issues in the future. So, please, be patient. Moving it would mean losing the context, and probably also part of the participants. Regards, A.
Yes, I did mention earlier the spurious hang-ups of 11.1 No logs, no, nothing that can be taken as a cause, simply dead . . . From 31 december 2008 I have to reset (what ? reset linux ??????) the pc. Can you understand that I am considering moving back to 10.2 ? Since 6.4 (first linux experience) i had NEVER had to reset the pc, it just ran and ran for years. What's happening to SuSE ?
@chris de boer did you update your system? The update is out since 21. of january, if it doesn't fix your problem then please reopen, or consider writing another bugreport as this bug here seems to be fixed to most people now (me included) regarding the 31. december crash you might have been hit by: http://www.linuxpromagazine.com/online/news/kernel_developers_tracking_down_new_year_s_eve_leap_second_issue @Alberto Passalacqua It's just that you risk loosing your very(!) valid points to a dead end street, project discussion is on opensuse-project mailing list, I don't think most of the decission makers are subscribed to a bug report to get input from the community, for example Stephan Kulow our release manager isn't... I am also unsatisfied how this release cycle went, it is already in discussion in regards to the new release timeline, if and how the short cycle influenced testing etc. Linking to this report in a post to the -project ml included with links to most important comments will have far more influence and reach the right people to bug about this.
In reply to comment #123 from Karsten: The patch came out only some hours ago. Having updated rpm is some non- or semi-official home:repo is NOT to be considered an update... In reply to comment #121 from Alberto: 1000000% Ack. The openSUSE project in its current state is only half-hearted. During alpha and beta releases alone it is impossible to find all important bugs as we have seen in the past. But actually, I don't know of *any* distribution which succeeds here. So this is not an openSUSE problem in itself. Yet it becomes on since others have a *much* more userfriendly approach with fixing bugs in the final release, too. And that usually very quick. However, whenever the bug fixing topic is raised, it is usually squashed by some stupid pseudo-argument that users rely on stability. No. That's wrong. Very wrong. I honestly have to admit that I will wander off, too, to some other meta-distribution if this won't change. Our present and past clinging to certain released versions, no matter how buggy and unstable those were, is downright ridiculous. I can live with bugs, and I do accept bugs in final releases. I do not accept having to wait for the next final release to get official patches to issues which are either already fixed upstream or internally for the SLE series. Simply, because the next final release will have other bugs again.
(In reply to comment #124) http://download.opensuse.org/update/11.1/rpm/i586/ check the dates No use replying to the rest I guess...
I have to say it the third, and hopefully the last, time: Please stop this kind of discussion in bugzilla. This is neither a mailing list nor some kind of forum. This tool is about bugs, nothing more. Everything else makes it impossible for developers to work on bugs. STOP SPAMMING bugzilla and my mailaccount with such stuff or I may have to request a change of the permissions to the bug!
-> close
Last post here, I promise. I just answer. @Danny: We are pointing out some problems and you do not like it. Discussing this here or elsewhere won't make any difference, I'm sorry, because "the decision makers" won't even consider it, they never did in the past. And there is no reason why discussing it here for once, even if off-topic, makes your bugfixing impossible. The bug is fixed, if you are so annoyed you can unsubscribe. @Karsten: ML are obsolete, only a few users read it, and I personally stopped. Goodbye
You say this wastes developers time , how about our time ! The time I wasted installing such a fscked up distro. This bug was opened on 2008-07-11 , it was not deemed important enough to stop the release or get fixed. You waste our time and damage the distro and make a joke of the community that reports bugs. If you can't communicate that the Novell then you will get a pissed of user base and chaff in bugzilla. Get used to it. If you can't get this to management our posting on an ML somewhere is pissing in the wind and you know it. This is probably the last post I'll make anywhere here, since having been caught out twice by flakey Suse releases I'm unlikely to try again.
(In reply to comment #128) > @Danny: We are pointing out some problems and you do not like it. Discussing > this here or elsewhere won't make any difference, I'm sorry, because "the > decision makers" won't even consider it, they never did in the past. And there > is no reason why discussing it here for once, even if off-topic, makes your > bugfixing impossible. The bug is fixed, if you are so annoyed you can > unsubscribe. This kind of discussion in bugzilla helps nobody. You can use some opensuse ML for this kind of political discussion, there are many so called "decision makers" subscribed to which can and will answer you. Bugzilla is simply not the place for this kind of non-technical discussion! This kind of dicussion started long time before the bug and the package was fixed. And this isn't only annoying, it interfere with the goal of bugzilla: fixing the bug. This bug was assigned to me at a time as I was, like many other developers, still on vacation (which don't mean we don't work on bugs in our free time). That's maybe bad timing, but please keep this in mind. And since I'm the bug owner, I can't simply unsubscribe from this bug.
@Danny: Simply reassign the bug to the biggest complainer. That way you're not the bug owner anymore and you won't get these spam mails anymore. I'm removing myself from CC as well (like a dozen others did) because the endless complaining after the bug has been fixed is completely useless.
Removing my votes for this bug to no longer get spamed by non-sense political discussions. There is places like these to talk about technical problems and places to talk politics. If you have a problem with novell talk to them in the places made for it or don't use their products, but don't spam the inboxes of people that have other things to do.
I've my system up to date and I still having problems whith my /dev/sr0 unit. When I tried to use the VirtualBox program it pops up one screen with the next text Cannot open host device '/dev/sr0' for readonly access. Check the >> permissions of that device ('/bin/ls -l /dev/sr0'): Most probably >> you need to be member of the device group. Make sure that you >> logout/login after changing the group settings of the current user >> (VERR_ACCESS_DENIED). >> Unknown error creating VM (VERR_ACCESS_DENIED). And also the K3b program doesn't detect the unit. I fixed using the solutions of the comment #52
If you still see such a problem on a fully patched system (and reboot after update installation) the reasons for the problem are most likely different. I'd suggest to open a new bug report and keep this one closed. Don't forget to attach lshal output to the new report. Thanks.
My system is up to date. However already twice during updates it hung, but thats not the issue. My question is, how I could find out if the hal update got corrupted due to the system hanging, because I still have to mount dvds and cds manually. They are not automount. Additionally k3b does not burn audiocds (I didn't try other) right, even if the program claims that everything worked.
Guenther: rpm -q hal and post the result here
rpm -q hal hal-0.5.12-10.12.1 well, according to that, the update worked. Could it be that some kind of configuration file got corrupted? I remember, that automounting of dvds worked some weeks ago
since this is a different bug, please open a new bug.
Very new to this but I too still have problem, I have opened a new bug #478475. Will try and add more logging data having been through the above again. Grateful for guidance on this bug reporting process so I can get it right.