Ensuring clean unmount of Windows volumes on shutdown?

Silent Observer · posted: 2013-12-22 18:55

My laptop (see signature below for basic specs) has a number of data files, especially music, on the Windows volumes (FAT32) that I'd like to be able to use from antiX, but there isn't room in the antiX volume to move or copy them there. I've found, however, that if I mount the Windows volumes via Rox by browsing to them, they don't get cleanly unmounted at system shutdown, resulting in a need to run fsck.vfat, and sometimes then boot Win98 and run Scandisk before I can open them again. I'm not ready to completely wipe the Windows volumes (which would obviously give plenty of space), though that's probably the long term endpoint; meantime, how can I ensure those volumes get cleanly unmounted on system shutdown -- add them manually to fstab? Or something else that's easier and/or more dependable?

fatmac · posted: 2013-12-23 09:26

If you always use them, I would add them in fstab, it worked for me, (long time since I've used MS), but I do sometimes use fat32 partitions. The system should automatically unmount the drives before shutting down if you do that.

dolphin_oracle · posted: 2013-12-23 13:35

I second the fstab option. I run all my data on a separate partition so that I can access it from windows or any linux that I happen to have installed. If you list the part. in fstab, you can also have the part. automount at login, which is handy if you use the shared part. for the location of something like dropbox or your music collection.

jdmeaux1952 · posted: 2013-12-23 15:18

An alternative would be to copy them all to a usb and that way you could use the usb for either OS.

Silent Observer · posted: 2013-12-23 15:56

jdmeaux1952 wrote:An alternative would be to copy them all to a usb and that way you could use the usb for either OS.

Win98 can't read a USB storage device without a driver that I never installed because I didn't own any USB keys until long after Win98 was sunsetted -- and my experience has been that on the USB keys that I use to move data between two antiX and one MEPIS system, I need root access to read, never mind write (I'm not certain why, but I suspect it's ownership; the key I use for this is formatted ext2, and probably wouldn't do that if it were FAT32). Better to add the FAT32 volumes to fstab so they automount and auto-unmount. I'll be back to ask questions about fstab if I run into trouble... __{{emoticon}}__

dolphin_oracle · posted: 2013-12-23 16:00

In case you need it, here's how my fstab is set for my fat32 partition.

Code: Select all

UUID=AC54-0F79 /media/sda6 vfat auto,users,gid=users,dmask=002,fmask=113,relatime 0 0

jdmeaux1952 · posted: 2013-12-23 16:19

Thanks for clarifying that.

Silent Observer · posted: 2013-12-23 16:39

I found that those volumes were already in fstab, but with"noauto" instead of"auto", otherwise just like yours aside from the UUID -- changed to"auto", rebooted, and they automounted. I presume that, like the antiX volume, they'll then auto-unmount during shutdown and I'll only have to worry about unclean unmounts when I have a system lockup that requires the power switch to back out (happens if I overload the machine and get too deep in 100% cpu and queued tasks -- there comes a point where no reasonable amount of waiting will let it clear up) -- that results in a forced deep check and forced reboot even for the antiX volume, so it'll be a clue that I need to check the Win98 volumes as well.

rokytnji · posted: 2013-12-23 17:33

Isn't windows 98 fat32 which in itself is problematic when shutting down during unclean shutdowns?

My / etc/fstab with a IBM Windows recovery partition that I have never used or get near and touch. I am afeared of it. . I had to do some AntiX kung foo after I installed my 320 gig drive after this AntiX install which is older than the drive insertion.

Code: Select all

$ cat / etc/fstab
# Pluggable devices are handled by uDev, they are not in fstab
UUID=676d70d7-1c41-449b-be0f-2e04df874d86  / auto defaults,noatime 1 1
proc /proc proc defaults 0 0
devpts /dev/pts devpts mode=0622 0 0
UUID=343942EB578098A9 /media/sda1 ntfs-3g noauto,users,noexec,uid=1000,gid=users,dmask=002,fmask=113,relatime 0 0
UUID=676d70d7-1c41-449b-be0f-2e04df874d86 / media/sdb3 ext4 auto,users,exec,relatime 0 0
UUID=a70b8580-b61d-4732-8109-b6f883ab58de swap swap sw,pri=1 0 0
UUID=454f0f9b-3885-4a59-a3d8-eefe9bef04e6 / media/sdb6 ext4 auto,users,exec,relatime 0 0
UUID=ee02c86b-ffa4-4a1f-8ecf-255eef02e8c7 / media/sdb7 ext4 auto,users,exec,relatime 0 0
/dev/cdrom /media/cdrom udf,iso9660 noauto,users,exec,ro 0 0
/dev/sr0 /media/cdrom udf,iso9660 noauto,users,exec,ro 0 0
# Added by antiX
/dev/sda1        /media/sda1      ntfs-3g    noauto,noexec,uid=1000,gid=users,dmask=002,fmask=113,users  0 0

#Added by ROK 320gig 2nd Hard Drive /dev/sda2
UUID=34d53583-6192-4242-aabc-5f8fa352042b     /media/data     ext4    auto,exec,users,rw     0 0

If it helps it helps. If not. Oh well. I use blkid to set up my fstab. My orginal was not even close after I inserted the 320gig drive. My system became unbootable because of
"boot used to sit on /dev/sda but has been moved to /dev/sdb. edit fstab to reflect changes"

It was fun and games after that. I even deleted original because it was such a mess and started over by hand.

/dev/sda used to be the original IBM drive the computer came with. Then Things went to hell after the new drive insertion.

Code: Select all

# blkid
/dev/sdb1: UUID="343942EB578098A9" TYPE="ntfs" 
/dev/sdb3: UUID="676d70d7-1c41-449b-be0f-2e04df874d86" TYPE="ext4" 
/dev/sdb5: UUID="a70b8580-b61d-4732-8109-b6f883ab58de" TYPE="swap" 
/dev/sdb6: UUID="454f0f9b-3885-4a59-a3d8-eefe9bef04e6" TYPE="ext4" 
/dev/sdb7: UUID="ee02c86b-ffa4-4a1f-8ecf-255eef02e8c7" TYPE="ext4" 
/dev/sda2: LABEL="/data" UUID="34d53583-6192-4242-aabc-5f8fa352042b" TYPE="ext4"

Code: Select all

 fdisk -l

Disk /dev/sda: 320 GB, 320070320640 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System 
/dev/sda2               1       38914   312568672   83  Linux
Disk /dev/sdb: 80 GB, 80031974400 bytes
255 heads, 63 sectors/track, 9730 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System 
/dev/sdb1   *           1          95      763056    7  HPFS/NTFS
/dev/sdb3              95        1352    10096852   83  Linux
/dev/sdb2            1352        9730    67296285    5  Extended/dev/sdb6            1352        3882    20322225   83  Linux
/dev/sdb7            3883        9332    43769092   83  Linux
/dev/sdb5            9333        9730     3188902   82  Linux swap

P.S. This is the first I have ever said about it. I still have to check on my AntiX 11 new 160GIG IDE new secondary drive insertion also on the Emachine Computer.
I am not trying to hijack this thread either as I can handle my own issues usually __{{emoticon}}__

fatmac · posted: 2013-12-24 12:51

Reference drives - there is usually resettable pins on the rear that let it act as 'Primary', 'Secondary', or 'Cable Select' - if your old drive was 'primary' & your new drive is 'secondary' it could possily mess with your fstab. Check your boot drive is 'primary' & other is 'secondary'.

When mounting drives with fstab you could try using 'defaults' in place of 'noauto'.
If you find that your user can't write to the drive, you will need to alter the permissions on the drives mount point.

Hope that is of some help.

Silent Observer · posted: 2013-12-26 16:49

There's only one user account on my laptop -- I'm the only one likely to haul it anywhere, and if that changes I can add a user when needed. It's currently still sitting by the bed acting as a stereo, but it's a better stereo with a wifi connection and ability to access USB storage than it was when it depended only on what MP3 files would fit on the original 4 GB hard disk along with Win98 and all the leftovers from when it was getting regular use.

Anyway, changing"noauto" to"auto" seems to have resolved the issue; all the Win98/fat32 volumes now mount at startup and, after a system lockup the other day, they seem to be okay (though they hadn't, as far as I can recall, been accessed during that session). At the least, if I do browse them, they now appear to correctly unmount during a clean shutdown.