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):
Everytime on EeePC.
Umount doesn't happen, if Fedora is installed on SD card.
CLEAN umount/eject (umount NEVER worked for me, just eject).
Let me know, whatever you need - but I should get this working before LinuxTag
which is last week of May 2008.
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...
CC'ing eject maintainer, as that seems to be what has changed...
could you please send an output of
$ cat /etc/fstab
$ ls /sys/block/ | grep sd.*
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
[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 ~]# ls /sys/block/ | grep sd.*
[root@eeepc ~]# cat /sys/block/sda/removable
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.
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?
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.
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 $?
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 :)
Created attachment 305380 [details]
add /sys to the whitelist
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?
initscripts-8.76.2-1 has been submitted as an update for Fedora 9
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
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.