2013/8/9 Joshua C. <[email protected]>: > 2013/8/9 Frederick Grose <[email protected]>: >> On Thu, Aug 8, 2013 at 6:15 PM, Joshua C. <[email protected]> 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@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 >> [email protected] >> 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 -- livecd mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/livecd
