Bug 478329

Summary: hald immediately mounts volumes again when I `eject` a disk
Product: [Fedora] Fedora Reporter: udo <udovdh>
Component: halAssignee: Richard Hughes <richard>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 11CC: richard, rvokal, sonarguy
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-06-28 11:02:27 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description udo 2008-12-28 09:05:42 UTC
Description of problem:
eject needs to be more aware of hal:
hald immediately mounts volumes again when I `eject` a whole disk (partitioned sata disk in my case).

[ hald also ejects the whole disk (!) when I eject a mounted partition. in this case hald doesn't immediately mount the partitions again. ]

Version-Release number of selected component (if applicable):
0.5.12    

How reproducible:
Attach (sata) disk to system via e.g. sharkoon quickport.
Power on quickport
Partitions on disk are automagically mounted under /media and browser windows open
I close browser windows.
I type `eject sdj` in my terminal.
Disk is ejected but hald starts all over by mounting etc.

Steps to Reproduce:
1. have (external) disk mounted
2. type `eject sdj` (sdj in my case)
3. see hald mount stuff again
  
Actual results:
hald remount disks

Expected results:
hald being aware of eject or rather: 
eject hal-awareness so that ejected stuff is not immediately mounted again.
[ also: ability to eject a mounted partition and not the whole disk (!) ]

Additional info:

Comment 1 udo 2008-12-28 12:01:44 UTC
One can do, with a number of partitions mounted form removable disk:

eject _var

and the all of the removable disks partitions are unmounted.

Then we do the eject of the whole disk:

eject sdj

and we see the disk be 'ejected' and immidately hald remounts all partitions.

so: eject _var does only unmount all partitions. 
so: eject sdj doesn't eject sdj (ejected is: not visible anymore to OS) but just kick it so it is seen by hal.

This is not correct behaviour nor usable in a desktop environment.
We want to be sure the *whole disk* is gracefully ejected before removing it physically. How can we do this with this setup?

Comment 2 Zdenek Prikryl 2009-01-07 08:07:24 UTC
Hello,
it seems, that a remounting of ejected devices could be connected with this bug #453095. Furthermore, IMO ejecting of only one partition doesn't make sense, because eject is used for ejecting devices (such as cdroms, zips, ...), not partitions. So I'm reassigning this to hal, the maintainer could add his comments.

Comment 3 udo 2009-06-18 13:56:35 UTC
Any progress? Comments?

Comment 4 Scott Glaser 2009-09-09 12:30:41 UTC
Have you tried with the latest hal package in Fedora 10, Fedora 11 or tried Rawhide? In either case, can you let us know whether the issue is still happening, and give the current version of the HAL packages you're using?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 5 udo 2009-09-09 13:24:41 UTC
hal-cups-utils-0.6.19-2.fc11.x86_64
hal-devel-0.5.12-29.20090226git.fc11.x86_64
hal-libs-0.5.12-29.20090226git.fc11.x86_64
hal-info-20090414-1.fc11.noarch
hal-0.5.12-29.20090226git.fc11.x86_64

Comment 6 udo 2009-09-12 08:44:58 UTC
Hmm. Workings have indeed changed.
# eject sdf
ls /dev/mapper/
control                                                             myvg-usrlv
crypto                                                              myvg-varlv
devkit-disks-luks-uuid-11691199-a271-4d3d-b4c9-86db34e57e05-uid500  myvg-wwwlv
myvg-datalv                                                         swapa
myvg-homelv                                                         swapb
myvg-optlv                                                          swapc
myvg-rootlv                                                         swapd
myvg-srclv


So eject did not eject although it pretended all was OK:

# eject -v sdf
eject: device name is `sdf'
eject: expanded name is `/dev/sdf'
eject: `/dev/sdf' is not mounted
eject: `/dev/sdf' is not a mount point
eject: checking if device "/dev/sdf" has a removable or hotpluggable flag
eject: `/dev/sdf' is a multipartition device
eject: trying to eject `/dev/sdf' using CD-ROM eject command
eject: CD-ROM eject command failed
eject: trying to eject `/dev/sdf' using SCSI commands
eject: SCSI eject succeeded
# cryptsetup luksClose /dev/mapper/devkit-disks-luks-uuid-11691199-a271-4d3d-b4c9-86db34e57e05-uid500 
# eject -v sdf
eject: device name is `sdf'
eject: expanded name is `/dev/sdf'
eject: `/dev/sdf' is not mounted
eject: `/dev/sdf' is not a mount point
eject: checking if device "/dev/sdf" has a removable or hotpluggable flag
eject: `/dev/sdf' is a multipartition device
eject: trying to eject `/dev/sdf' using CD-ROM eject command
eject: CD-ROM eject command failed
eject: trying to eject `/dev/sdf' using SCSI commands
eject: SCSI eject succeeded
# eject -v sdf
eject: device name is `sdf'
eject: expanded name is `/dev/sdf'
eject: `/dev/sdf' is not mounted
eject: `/dev/sdf' is not a mount point
eject: checking if device "/dev/sdf" has a removable or hotpluggable flag
eject: `/dev/sdf' is a multipartition device
eject: trying to eject `/dev/sdf' using CD-ROM eject command
eject: CD-ROM eject command failed
eject: trying to eject `/dev/sdf' using SCSI commands
eject: SCSI eject succeeded
# eject -v sdf
eject: device name is `sdf'
eject: expanded name is `/dev/sdf'
eject: `/dev/sdf' is not mounted
eject: `/dev/sdf' is not a mount point
eject: checking if device "/dev/sdf" has a removable or hotpluggable flag
eject: `/dev/sdf' is a multipartition device
eject: trying to eject `/dev/sdf' using CD-ROM eject command
eject: CD-ROM eject command failed
eject: trying to eject `/dev/sdf' using SCSI commands
eject: SCSI eject succeeded


dmesg excerpt:
EXT4-fs: mballoc: 1768 generated and it took 10910880
EXT4-fs: mballoc: 272840 preallocated, 43647 discarded
sd 8:0:0:0: [sdf] Assuming drive cache: write through
 sdf: sdf1
sd 8:0:0:0: [sdf] Assuming drive cache: write through
 sdf: sdf1
sd 8:0:0:0: [sdf] Assuming drive cache: write through
 sdf: sdf1
(eof)

Comment 7 Bug Zapper 2009-11-18 09:08:28 UTC
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 8 Bug Zapper 2010-04-27 12:39:07 UTC
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 9 udo 2010-05-15 12:29:06 UTC
What was done to fix the issue?

Comment 10 Bug Zapper 2010-06-28 11:02:27 UTC
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 11 Red Hat Bugzilla 2023-09-14 01:14:57 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days