|Summary:||Umount doesn't happen, if Fedora is installed on SD card|
|Product:||[Fedora] Fedora||Reporter:||Robert Scheck <redhat-bugzilla>|
|Component:||initscripts||Assignee:||Bill Nottingham <notting>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-05-21 19:02:32 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Robert Scheck 2008-05-13 22:48:16 UTC
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 22:51:28 UTC
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-14 00:36:51 UTC
CC'ing eject maintainer, as that seems to be what has changed...
Comment 3 Zdenek Prikryl 2008-05-14 08:38:22 UTC
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 09:48:09 UTC
[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 10:07:51 UTC
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 10:25:57 UTC
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 10:59:30 UTC
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 11:26:51 UTC
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 16:36:40 UTC
Created attachment 305380 [details] add /sys to the whitelist Try this.
Comment 10 Robert Scheck 2008-05-15 06:04:40 UTC
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 16:43:11 UTC
initscripts-8.76.2-1 has been submitted as an update for Fedora 9
Comment 12 Fedora Update System 2008-05-17 22:20:59 UTC
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 11:08:53 UTC
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.