Bug 446292 - Umount doesn't happen, if Fedora is installed on SD card
Umount doesn't happen, if Fedora is installed on SD card
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
rawhide
All Linux
low Severity urgent
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-13 18:48 EDT by Robert Scheck
Modified: 2014-03-16 23:14 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-21 15:02:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
add /sys to the whitelist (505 bytes, patch)
2008-05-14 12:36 EDT, Bill Nottingham
no flags Details | Diff

  None (edit)
Description Robert Scheck 2008-05-13 18:48:16 EDT
Description of problem:
Umount isn't executed sucessfully, if Fedora was installed on an SD card (put 
into USB reader and bootet from it). So EVERY bootup a file system check with
another reboot is caused.

In the past, in F8 times, putting "eject /dev/sda1" (where /dev/sda1 is the / 
which is on the SD card inside of the USB reader of) into /sbin/halt.local was
a usable workaround. Fscking upstart broke this IMHO. Oh and umount NEVER did 
never work for me, just eject.

If putting "eject /dev/sda1" again into /sbin/halt.local as in former times 
(Fedora 8), it just outputs the following on reboot/poweroff: "eject: can not 
open directory /sys/block/eject: did not find a device /dev/sda1 in /sys/block"
Looks like /sys is no longer available now and eject depends on it.

So can we get please working support for Fedora on SD cards ASAP? ;-)

Version-Release number of selected component (if applicable):
initscripts-8.76-1

How reproducible:
Everytime on EeePC.

Actual results:
Umount doesn't happen, if Fedora is installed on SD card.

Expected results:
CLEAN umount/eject (umount NEVER worked for me, just eject).

Additional info:
Let me know, whatever you need - but I should get this working before LinuxTag
which is last week of May 2008.
Comment 1 Robert Scheck 2008-05-13 18:51:28 EDT
Oh, putting "eject /dev/sda1" before "# Try all file systems other than root, 
essential filesystems and RAM disks, one last time." in /etc/init.d/halt seems 
to work, but breaks other things - such as the "Try all file systems other than 
root, essential filesystems and RAM disks, one last time" itself, because /sys 
and foobar is no longer available at that point...
Comment 2 Bill Nottingham 2008-05-13 20:36:51 EDT
CC'ing eject maintainer, as that seems to be what has changed...
Comment 3 Zdenek Prikryl 2008-05-14 04:38:22 EDT
Hello,
could you please send an output of 

$ cat /etc/fstab
$ ls /sys/block/ | grep sd.*
$ /sys/block/sda/removable

as the attachment?

In your case, $ umount /dev/sda1 tries to umount the root filesystem on a SD
card. So, if umount fails to do that, then I think it is a correct behavior of
umount. It is strange that eject doesn't complain about that because eject calls
umount. Eject doesn't have its own umount.

Further, you are right, that if you umount /sys/ before calling eject, then
eject will not work.

If you don't want to start fsck on every boot-up then add $ touch /fastboot into
/sbin/halt.local
Comment 4 Robert Scheck 2008-05-14 05:48:09 EDT
[root@eeepc ~]# cat /etc/fstab
UUID=393b645f-b854-49cf-9278-85a5781c539f /   ext2    defaults,noatime   1 1
tmpfs                   /dev/shm              tmpfs   defaults           0 0
devpts                  /dev/pts              devpts  gid=5,mode=620     0 0
sysfs                   /sys                  sysfs   defaults           0 0
proc                    /proc                 proc    defaults           0 0
tmpfs                   /var/cache/yum        tmpfs  
defaults,size=384m,mode=1777  0 0
tmpfs                   /tmp                  tmpfs  
defaults,size=128m,mode=1777  0 0
[root@eeepc ~]#

[root@eeepc ~]# ls /sys/block/ | grep sd.*
sda
sdb
[root@eeepc ~]#

[root@eeepc ~]# cat /sys/block/sda/removable
1
[root@eeepc ~]#

The problem seems to be, that eject somehow depends on /sys, /proc or something 
else. If eject is called *after* umount of /sys, /proc etc, the eject fails with
"eject: can not open directory /sys/block/eject: did not find a device /dev/sda1
in /sys/block". If I put the eject *before*  umount of /sys, /proc etc, it is
just impossible to get /sys, /proc etc. sane umounted, because eject kills root
and thus they're magically also umounted. So how did eject change?

Well, it is ext2, so I really should trust fsck and friends and not disable it.
Comment 5 Zdenek Prikryl 2008-05-14 06:07:51 EDT
eject depends on /sys/. In /sys/ are information about devices and their
possibility of ejecting. If eject doesn't have this information, then it will
complain. This checking prevents security problems like ejecting /boot partition
on harddisks etc.

Further, if you call $ eject /dev/sda1 and you have /sys, /proc mounted, then
eject should umount all of these partition correctly (unless some error occurs
and in this case eject will report a problem). It is strange, that if you do
that, then every time fcsk is needed :-/

Could you add an output of umount also? You wrote that it never worked, so what
does it complain about?
Comment 6 Robert Scheck 2008-05-14 06:25:57 EDT
Well...in Fedora 8, eject worked when /sys was not available - thus I'm so 
loudly complaining here.

Umount gives no output, it simply does not work, when I try to umount /dev/sda1 
or when I'm trying to remount it readonly.
Comment 7 Zdenek Prikryl 2008-05-14 06:59:30 EDT
Since version 2.1.5-6 is eject dependant on /sys even in F8. 

But anyway, try to find a return code of umount. 
$ umount /dev/sda1; echo $?
Comment 8 Robert Scheck 2008-05-14 07:26:51 EDT
Returns always 0 for this umount.

Well, can we then move the execution of /sbin/halt.local before the umount of
/sys, /proc etc. because otherwise /sbin/halt.local seems useless to me.

Or even better: Bill, can we get the eject into initscripts upstream if root 
filesystem is on SD card? This would IMHO be the best solution :)
Comment 9 Bill Nottingham 2008-05-14 12:36:40 EDT
Created attachment 305380 [details]
add /sys to the whitelist

Try this.
Comment 10 Robert Scheck 2008-05-15 02:04:40 EDT
Solves the non-working of eject in /sbin/halt.local, yes :)

Can we get this whitelisting into Rawhide and into F9 as update as well?
Comment 11 Fedora Update System 2008-05-15 12:43:11 EDT
initscripts-8.76.2-1 has been submitted as an update for Fedora 9
Comment 12 Fedora Update System 2008-05-17 18:20:59 EDT
initscripts-8.76.2-1 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update initscripts'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-4037
Comment 13 Fedora Update System 2008-05-21 07:08:53 EDT
initscripts-8.76.2-1 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.