[Fedora-livecd-list] shutting down f19-livecd corrups raid1

Joshua C. joshuacov at gmail.com
Fri Aug 9 07:37:15 UTC 2013


2013/8/9 Joshua C. <joshuacov at gmail.com>:
> 2013/8/9 Frederick Grose <fgrose at gmail.com>:
>> On Thu, Aug 8, 2013 at 6:15 PM, Joshua C. <joshuacov at gmail.com> wrote:
>>>
>>> My raid1 gets corrupted _everytime_ I shut down a
>>> f19-kde-livecd-image. I used kernel.f19 and mdadm.f19 in a f17-livecd
>>> and everything works fine. So these two are not the problem.
>>>
>>> What should I look at? maybe dracut???
>>>
>>> PS: Testing and experimenting isn't a good idea here because it takes
>>> almost 3 hours for the raid to rebuild...
>>>
>>> --
>>> --joshua
>>
>>
>> With Fedora-Live-Desktop-x86_64-19-1 installed to a vfat formatted Live USB
>> device, I find this report in /var/log/messages on each reboot:
>>
>> Aug  8 17:24:09 localhost kernel: [    8.255350] FAT-fs (sdc1): Volume was
>> not properly unmounted. Some data may be corrupt. Please run fsck.
>> Aug  8 17:24:09 localhost kernel: [   11.052845] bio: create slab <bio-1> at
>> 1
>> Aug  8 17:24:09 localhost kernel: [   11.179108] EXT4-fs (dm-0): mounted
>> filesystem with ordered data mode. Opts: (null)
>>
>> Once unmounted, fsck reports that the dirty bit is set:
>>
>> [root at localhost ~]# fsck.vfat -rv /dev/sdc1
>> fsck.fat 3.0.22 (2013-07-19)
>> fsck.fat 3.0.22 (2013-07-19)
>> Checking we can access the last sector of the filesystem
>> 0x41: Dirty bit is set. Fs was not properly unmounted and some data may be
>> corrupt.
>> 1) Remove dirty bit
>> 2) No action
>> ? 1
>> Boot sector contents:
>> System ID "SYSLINUX"
>> Media byte 0xf8 (hard disk)
>>        512 bytes per logical sector
>>       4096 bytes per cluster
>>         32 reserved sectors
>> First FAT starts at byte 16384 (sector 32)
>>          2 FATs, 32 bit entries
>>    7798784 bytes per FAT (= 15232 sectors)
>> Root directory start at cluster 2 (arbitrary size)
>> Data area starts at byte 15613952 (sector 30496)
>>    1948715 data clusters (7981936640 bytes)
>> 62 sectors/track, 247 heads
>>          0 hidden sectors
>>   15620218 sectors total
>> Checking for unused clusters.
>> Checking free cluster summary.
>> Perform changes ? (y/n) y
>> /dev/sdc1: 18 files, 644955/1948715 clusters
>>
>> I wonder if this may be due to a Bash shell not getting properly shut down
>> during shutdown, as reported here,
>> http://lists.freedesktop.org/archives/systemd-devel/2013-July/012307.html
>>
>>       --Fred
>>
>>
>> --
>> livecd mailing list
>> livecd at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/livecd
>
> I was suspecting that systemd could be involved. Do you know if there
> is a patch about this?
>
> Since I'm using a livecd image without persistent overlay, there is no
> way to find any logs from the shutting down process. But this is very
> frustrating....
>
>
> --
> --joshua

I'll backport commits 82659fd7571bda0f3dce9755b89a23c411d53dda "core:
optionally send SIGHUP in addition to the configured kill signal" and
a6c0353b9268d5b780fb7ff05a10cb5031446e5d "core: open up SendSIGHUP
property for transient units" to systemd-204 and turn this on in my
test built. I hope this can fix the problem.

As I already said, it annoying to rebuild the raid after every reboot!!!

Has this behavior been reported in a real installation (no livecds)?


-- 
--joshua


More information about the livecd mailing list