root FS not cleanly unmounted on SSD

Bug #260807 reported by roots
10
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

hi there,

a got a brand new solid state drive now running as dual boot system drive with winxp and ubuntu hardy, the latter on ext2. the ext2 partition hosts both / and a small /home. /swap is located on my hdd but never in use due to enough ram.

now there's some big annoyance here, as ubuntu cleanly unmounts my ssd-hosted file system in only like one out of ten cases.
this means, that on almost every system startup, it checks my / fs, finds errors and corrects them and after the necessary reboot, finally starts up. the drive itself seems to be fine, win is running without problems and filechecks and in general i don't see any data corruption whatsoever.

however, this should NOT be standard operating procedure, so i'm asking for suggestions and solutions here! anyone?!

thanks in advance!
.roots

some relevant system specs:

ssd: mtron pro 7535 32gb
hdd: samsung spinpoint hd322hj
controller: intel ich9 on gigabyte x38-ds5
ubuntu hardy, 2.6.24-21 kernel.

Revision history for this message
roots (roots) wrote :

if you're asking for why i am using ext2: amongst one of the recommendations for SSDs i found that using a non-journaling fs would be more convenient, because it reduces the write access to the drive, which - due to the writing-weakness inherent in flash technology - should have an impact on both performance and lifespan.

Revision history for this message
roots (roots) wrote :

after a bit more of testing, i found that this occurs only on shutdown (gnome shutdown button, shutdown -h now, halt), not if i let ubuntu reboot and power off the system manually before grub starts.

Revision history for this message
Benjamin Drung (bdrung) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately we can't fix it without more information.

Please include the following additional information, if you have not already done so (pay attention to lspci's additional options), as required by the Ubuntu Kernel Team:
1. Please include the output of the command "uname -a" in your next response. It should be one, long line of text which includes the exact kernel version you're running, as well as the CPU architecture.
2. Please run the command "dmesg > dmesg.log" after a fresh boot and attach the resulting file "dmesg.log" to this bug report.
3. Please run the command "sudo lspci -vvnn > lspci-vvnn.log" and attach the resulting file "lspci-vvnn.log" to this bug report.

For your reference, the full description of procedures for kernel-related bug reports is available at https://wiki.ubuntu.com/KernelTeamBugPolicies Thanks in advance!

(I want this ssd too. *sigh*)

Revision history for this message
roots (roots) wrote :

hi,

thanks for your quick reply. here's the info you requested:

sudo uname -a
Linux machineone 2.6.24-21-generic #1 SMP Tue Aug 12 13:37:22 UTC 2008 i686 GNU/Linux

dmesg and lspci outputs are attached.

if there's any more info i may provide, please let me know.

p.s. well i'm sure you would want this ssd - how about reducing ubuntu boot (grub-->gdm) from 26 to 18s and login-->ready desktop (compiz et al.) from 21 to 6s ?! (compared to seagate barracuda 7200.10)

Revision history for this message
roots (roots) wrote :
Revision history for this message
Benjamin Drung (bdrung) wrote :

It would be useful to have a log file from the crash. Can you reproduce the crash on shutdown, then start your computer again and attach the file /var/log/kern.log. If I am right, this file contains all the logs from the last 24 hours and after the crash the log is hopefully written to disk.

Revision history for this message
roots (roots) wrote :

well there's bad news - i had already tried to find something in the logfiles but to no avail - they do resume just after the kernel-induced reboot after the initial fsck. furthermore, i now recognized that after such crashy shutdown, fsck does not only find errors but also had "died with error code 3" each time. i must have read over that before.
another thing that already indicated that something is fishy with shutdown is, that after fsck and the reboot, my saved-upon-logoff ubuntu session including evolution, firefox etc. is always in a post-crash condition.

nevertheless i'll attach my kern.log, fyi, i initiated shutdown at 7:20, all entries at 7:22 are already from the reboot after (unsuccessful) fsck.

Revision history for this message
roots (roots) wrote :

ok, i got a bit further into it. first of all, i found that kernel logging was delayed per "-" switch in /etc/syslog.conf. i removed that and now kern.log shows some strange news on shutdown:

>Aug 25 09:10:50 machineone kernel: [ 2013.680949] sd 5:0:0:0: [sdb] Synchronizing SCSI cache
>Aug 25 09:10:50 machineone kernel: [ 2013.699966] sd 5:0:0:0: [sdb] Stopping disk
>Aug 25 09:10:50 machineone kernel: [ 2013.700134] sd 4:0:1:0: [sda] Synchronizing SCSI cache
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@Aug >25 09:12:47 machineone kernel: Inspecting /boot/System.map-2.6.24-21-generic

the STRANGE thing about this is, that SDB (!) is the FLASH DRIVE hosting /, while sda is a standard sata2 hdd!? next thing i tried was to simply unplug the hdd (pc off), restart my pc, try the shutdown thing again and having a look at the logfiles. but - nothing! i did a shutdown at 9:27 and the not-cleanly-unmounted issue still persists, but now kern.log simply shows nothing!

>Aug 25 09:22:49 machineone kernel: [ 74.106803] ALSA /build/buildd/linux-ubuntu-modules-2.6.24-2.6.24/debian/build/build-generic/sound/alsa-driver/usb/usbaudio.c:1345: 4:2:1: usb_set_interface failed
>Aug 25 09:28:44 machineone kernel: Inspecting /boot/System.map-2.6.24-21-generic

syslog only reads

>Aug 25 09:27:00 machineone init: tty4 main process (5187) killed by TERM signal
>Aug 25 09:27:00 machineone init: tty5 main process (5188) killed by TERM signal
>Aug 25 09:27:00 machineone init: tty2 main process (5196) killed by TERM signal
>Aug 25 09:27:00 machineone init: tty3 main process (5197) killed by TERM signal
>Aug 25 09:27:00 machineone init: tty6 main process (5202) killed by TERM signal
>Aug 25 09:27:00 machineone init: tty1 main process (5985) killed by TERM signal
>Aug 25 09:28:44 machineone syslogd 1.5.0#1ubuntu1: restart.

and that's it!
as already mentioned, i moved my /swap to sda5, that is, my hdd.

>Aug 25 08:38:01 machineone kernel: [ 46.052364] Adding 1951856k swap on /dev/sda5. Priority:-1 extents:1 across:1951856k

it seems to me that unplugging this hdd somehow causes the log-lack. but what i really don't understand is, why - according to kern.log - my root fs btw. drive is stopped before the hdd? is the kernel usually moved to /swap on shutdown?!
one more thing i recognized using a digicam to film the shutdown process of my screen is the message

>*Will now halt
>halt: unable to iterate IDE devices. No such file or directory.

which seems to occur always on an attempted shutdown, regardless of the hdd bein connected or not.

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Revision history for this message
roots (roots) wrote :

i would go with the 2.6.27 kernel only for the first. i just downloaded

linux-headers-2.6.27-1-generic_2.6.27-1.2_i386.deb
linux-image-2.6.27-1-generic_2.6.27-1.2_i386.deb
linux-restricted-modules-2.6.27-1-generic_2.6.27-1.1_i386.deb

from http://packages.ubuntu.com but i can't seem to find any ubuntu-modules package? am i getting something wrong here?

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hi roots,

The linux-ubuntu-modules package was actually merged with the linux kernel source package beginning with the Intrepid Ibex development cycle so it no longer exists for Intrepid. Thanks.

Revision history for this message
Neil Munro (neilmunro-deactivatedaccount) wrote :

The Intrepid Ibex 8.10 Beta release was most recently announced - http://www.ubuntu.com/testing/intrepid/beta . It contains the 2.6.27 Ubuntu kernel. It would be great if you could test and verify if this is still an issue. The status is being set to Incomplete until we receive further feedback. Thanks.

Changed in linux:
status: New → Incomplete
Revision history for this message
roots (roots) wrote :

hi,

sorry for the big 'lag' but i did not have the chance to give intrepid a go until now. it seems - however - that the aforementioned bug is no longer present in the current ubuntu release. at least it did not show up until now, that is, after ~10 regular shutdowns.

Revision history for this message
Benjamin Drung (bdrung) wrote :

I am setting the status to Fix Released. If the bug appears again please reopen this bug report.

Changed in linux:
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.