Re: [Cooker] installation report beta2
On Sun, 24 Aug 2003, Helge Hielscher wrote: > although a bit late, here's my installation report: > -there was no minimal limit when resizing NTFS (but when using disdrake > there is), so I got unmontable_boot_volume when I started winxp This one is supposed to be fixed in current cooker. Szaka
[Cooker] Re: "fix" diskdrake behaviour regarding destructive fs resizing
On Thu, 21 Aug 2003, Thierry Vignaud wrote: > > 2) Maybe printing the reason, why non-destrcutive partitioning > > isn't possible could help in cases. Occasionally these are > > happening: > > pixel, could you display the reason why we cannot perform a non > destructive resizing too ? QTParted does this. The rule is if exit code isn't 0, then either 1) potentially multiply lines error printed right before program exit, prefixed with ERROR at column 0, for example, ERROR(30): Failed to set $Volume dirty: Read-only file system or ERROR: filesystem check failed! Windows wasn't shut down properly or inconsistent filesystem. Please run chkdsk on Windows. or 2) message is "The volume end is fragmented, this case is not yet supported ...". Well, separate, unique exit codes would be a better way ... hmmm, 103 different exit points, most can have dozens of reasons, e.g. above errno = 30 means Read-only file system. Not sure anymore ... Szaka
Re: [Cooker] Software submission for the Mandrake distribution
On Thu, 21 Aug 2003, Thierry Vignaud wrote: > ntfs resize "implementation" (read: "interfacing with ntfsresize") on > drakx side was quite a lot simpler than writing ntfsresize in the > first place. I remember, I was extremely impressed how fast it was integrated. It shows Mandrake has an excellent development infrastructure and great developers. There is only one (two) problems, we discussed already at that time. 1) If, for whatever reason, ntfs can not be resized or the potentially freed space is not enough to install Mandrake then diskdrake warns "After resizing partition X, all data on this partition will be lost". Believe me, some people don't believe this and hope it will work out. Never. Partition gets resized but not ntfs so they can't boot Win anymore. At that time we discussed, this warning must be more explanatory, like "Non-destructive partition resizing is not possible, if you continue you will lose all your data" (but in English ;) however due to the string freeze for translation this couldn't be added at that time. Hopefully now? 2) Maybe printing the reason, why non-destrcutive partitioning isn't possible could help in cases. Occasionally these are happening: - inconsistent NTFS -> user must run chkdsk (not from the gui but from the command line). - one of the many different inconsistent NTFS cases turned out to be a very rare but still valid NTFS and I added support for it (only in the development tree now) - NTFS having bad sectors -> I had quite many reports, so I added support to resize these as well, but it's still in testing phase. - there are data at the end of the partition -> turning off pagefile.sys and/or hibernation helped many people, the development version of ntfsresize can also tell what are those files. > i still think that relocating files would be nice if it wasn't so hard > to properly (read: with no risk at all) implement. Sure, incrementally, very slowly it's progressing, as time allows. I wrote a list what needs to be done here http://marc.theaimsgroup.com/?l=linux-ntfs-dev&m=105949711324625&w=2 Even non-developers could help a lot, written on the above page how. Szaka
RE: [Cooker] Software submission for the Mandrake distribution
On Thu, 21 Aug 2003, Manoj Joseph wrote: > > Wrong approach. > Why? I am not doing a ntfs file system driver for linux. AFAIR, you mentioned it helps Win -> Linux migration. If you migrate, then you want to solve issues in the new, native environment, not escaping and working around. Fix the cause, not the symptom. However your tool can be a very valuable one for Linux -> Win migrants, so asking Microsft to including it seems quite reasonable, soon ;) Moreover as others also pointed out, there are several such tools. I know, yours is in kernel space and better, etc, but it's still the "not invented here" category, no real innovation, value in my opinion (you asked for it ;) > > Lack of the NTFS information? > The fact that the NTFS file system is not documented *is* a > major factor. It's a myth, this is why I also mentioned it before. It took me about one month in my limited free time to go through the current, public NTFS docs and sources and write ntfsresize and fix/help to fix all known problems in the version 2 NTFS driver (what most distros ship). Anton Altaparmakov, the driver maintainer, says, the problem [to implement _full_ write support] is the lack of time, not lack of public knowledge. But don't believe us [linux-ntfs developers], just think it over. If you have the knowledge how to read, sure you also know who to write those on-disk data [there might be technologies where this is not true, but it's not NTFS]. However NTFS is pretty complex and write support is at least 10x harder to implement than read support due to e.g. carefully handling concurrency issues. > > The reason is nobody has the time to do it. > I don't think so. I definitely know, I don't have time. Anton says he also doesn't have time (doing his PH.D). I believe this because it happens he ignores my patches, no regular releases, announcements or real activity. Flatcap, another developer and the webmaster, also doesn't have time, ignores emails or can respond only weeks later, web site is pretty outdated, etc. Rarely people ask what they could help, they are told then they are gone without reappearing again. So at present Linux NTFS develpment is pretty in "stalled", maintaince mode, for half, one year (e.g. I wrote the ntfs resizer over 1 year ago, it just recently started to be known, thanks to Mandrake). > > ...Your effort would be MUCH MORE appreciated there, by > > millions of users. > :) I'm not joking :) See e.g. the statistics of the Linux-NTFS project (the lines at the right is down because those data are for this, not an entire month) http://sourceforge.net/project/stats/index.php?report=months&group_id=13956 Over 2,300,000 page views. Goggle stats says, every month there are 1-2% more NT based OS (NTFS) than Win9* one (FAT). FAT has volume and file size limits and several other drawbacks and soon will go away except for special purposes. Szaka
RE: [Cooker] Software submission for the Mandrake distribution
On Wed, 20 Aug 2003, Manoj Joseph wrote: > > Lots of linux users are not aware that such a driver *can* > exist. I didn't until a month before I started working on this > project. ;) Wrong approach. The root of the problem is the Linux NTFS write support isn't finished. Why? Lack of the NTFS information? No. The reason is nobody has the time to do it. Your effort would be MUCH MORE appreciated there, by millions of users. Szaka
Re: [Cooker] [Bug 2930] [drakxtools] NTFS resizing
Hi, I'm very sorry to say but I'm not sure the problem is lilo. 1) we know the hardware is unreliable 2) you reported also severe ext3 corruptions <- very unusual, and at large it happens when one has hardware problems What you experience I'm afraid is the effect that the hardware run on its limit. Sometimes things work, sometimes doesn't. It also is possible that Windows overjudge the hardware settings to be safer (we know it's able to detect it) but Linux doesn't. This can result that disk io on Win always work but when you use Linux it corrupts data. Maybe you could report these to Linux kernel developers, giving a very detailed information on your hardware. Szaka On Fri, 14 Mar 2003, gregor.pirnaver wrote: > http://qa.mandrakesoft.com/show_bug.cgi?id=2930 > > --- Additional Comments From [EMAIL PROTECTED] 2003-03-14 13:16 --- > Still on RC2... > > OK, now I booted from a CD and (only) resized windows partition & everything > works as expected. > > So I guess there are some problems with lilo installation? > > > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. > > > > --- Reminder: --- > assigned_to: [EMAIL PROTECTED] > status: UNCONFIRMED > creation_date: > description: > If I resize (during installation of 9.1 RC2 on a laptop) NTFS > partition I can no longer boot in Windows XP Profesional (first I > got a blue screen, now I get a blank screen). > > --
Re: Re: [Cooker] [Bug 3165] [kernel] New: application freeze whenreading ntfs
On Tue, 11 Mar 2003 [EMAIL PROTECTED] wrote: > It seems you are right my version is 2.4.21-0.11mdk not 2.4.21-0.13mdk. Yes, the NTFS driver in 2.4.21-0.11mdk is the buggy one. Thanks for letting us know! > Thanks for your help. I have removed the bugreport You're welcome :) Szaka
Re: [Cooker] [Bug 3165] [kernel] New: application freeze when readingntfs
Hi, Could you confirm the kernel is really 2.4.21-0.13? % uname -a Linux localhost 2.4.21-0.13mdk #1 Fri Mar 7 06:31:12 CET 2003 Before (RC2 and earlier) there was an NTFS diver bug that caused hangs (e.g. during importing Windows fonts) but in the above kernel version it must be fixed (several people confirmed that). And if you indeed have 2.4.21-0.13mdk, can you reproduce the hang? Thanks, Szaka On Tue, 11 Mar 2003, d97mabo wrote: > http://qa.mandrakesoft.com/show_bug.cgi?id=3165 > >Product: kernel > Component: kernel >Summary: application freeze when reading ntfs >Version: 2.4.21-0.13mdk > Platform: PC > OS/Version: All > Status: UNCONFIRMED > Severity: major > Priority: P2 > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > When an application (such as xmms) tries to read a file on my > WindowsXP perfessional partition it freezes completly and then it > is no longer possible to umount the partition anymore. It is still > possible to browse ntfs though as long as you don't try to access > a file.
Re: [Cooker] [Bug 2930] [drakxtools] NTFS resizing
Hi Gregor, Thanks, great information! Please see the, hopefully, solution according to the Microsoft Knowledgebase at http://support.microsoft.com/?kbid=297185 ---> Your computer uses an Ultra Direct Memory Access (UDMA) hard disk controller, and the following conditions are true: * You use a standard 40-wire connector cable to connect the UDMA drive to the controller instead of the required 80-wire, 40-pin cable. * The basic input/output system (BIOS) settings are configured to force the faster UDMA modes. <-- Note, if the filesystem would be damaged then the second parameter after the STOP error message would be 0xC032 and not 0xC14F as you wrote below. Szaka On Mon, 10 Mar 2003, gregor.pirnaver wrote: > http://qa.mandrakesoft.com/show_bug.cgi?id=2930 > > --- Additional Comments From [EMAIL PROTECTED] 2003-03-10 18:02 --- > After reinstalling Windows & restoring LILO I resized windows partition again > (with diskdrake). This is the error I get: > UNMOUNTABLE_BOOT_VOLUME > ... > STOP 0x00ED (0x827922C0, 0xC14F, 0x, 0x) > when I try to boot in Windows (I can mount windows partition in Linux). > > Partitions: > Disk /dev/hda: 40.0 GB, 40007761920 bytes > 255 heads, 63 sectors/track, 4864 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > > Naprava BootStart EndBlocks Id System > /dev/hda1 * 1 3207 257601967 HPFS/NTFS > /dev/hda2 3845 4864 81931505 Raz?irjen > /dev/hda5 3845 4432 4723078+ 83 Linux > /dev/hda6 4433 4495506016 82 Linux swap > /dev/hda7 4496 4864 2963961 83 Linux > > > Disk: > Model: ?MK4018GAP > Vendor: ?Toshiba > > > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. > > > > --- Reminder: --- > assigned_to: [EMAIL PROTECTED] > status: UNCONFIRMED > creation_date: > description: > If I resize (during installation of 9.1 RC2 on a laptop) NTFS partition I can > no longer boot in Windows XP Profesional (first I got a blue screen, now I get > a blank screen). > > --
Re: [Cooker] [Bug 2842] [libgtk+1.2] File dialog's strage behaviour
On Sun, 9 Mar 2003, pablo wrote: > http://qa.mandrakesoft.com/show_bug.cgi?id=2842 > > You must have iocharset=utf8 and no codepage= >From /usr/src/linux/Documentation/filesystems/ntfs.txt --> iocharset=name Deprecated option. Still supported but please use nls=name in the future. See description for nls=name. nls=nameCharacter set to use when returning file names. Unlike VFAT, NTFS suppresses names that contain unconvertible characters. Note that most character sets contain insufficient characters to represent all possible Unicode characters that can exist on NTFS. To be sure you are not missing any files, you are advised to use nls=utf8 which is capable of representing all Unicode characters. <--- So please use nls=utf8 and forget iocharset (bad heritage from the old NTFS driver). Szaka
Re: [Cooker] [Bug 2884] [mount] New: Cannot mount NTFS
Hi, Didn't this happen after the font importing lockup? That can hang the NTFS driver and nobody can access anything on it afterwards. Recent Cooker shouldn't have this problem. Szaka On Thu, 6 Mar 2003, wfjarrett wrote: > http://qa.mandrakesoft.com/show_bug.cgi?id=2884 > >Product: mount > Component: program >Summary: Cannot mount NTFS >Version: 2.11x-3mdk > Platform: PC > OS/Version: All > Status: UNCONFIRMED > Severity: critical > Priority: P2 > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > NTFS mounts ok, but locks any application that trys to access it (bash, > konquerer, nautilus). Cannot find any logs as to why this is happening. I am > trying to mound a Windows XP NTFS partition on /dev/hda1 > > > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. > > --
Re: [Cooker] [Bug 2883] [drakxtools] New: Locks up when importingWindows fonts
AFAIK, RC2 doesn't, only Cooker has the NTFS driver fix that causes these hangs. What did you use? I'm very surprised Mandrake didn't included it in RC2 even if they knew about the fix for 5 days ... I really hope RC2 is not the last RC as claimed ... Szaka On Thu, 6 Mar 2003, wfjarrett wrote: > http://qa.mandrakesoft.com/show_bug.cgi?id=2883 > >Product: drakxtools > Component: drakfont >Summary: Locks up when importing Windows fonts >Version: 9.1-15mdk > Platform: PC > OS/Version: All > Status: UNCONFIRMED > Severity: major > Priority: P2 > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > FontDrake locks up when trying to import windows fonts from /dev/hda1 (Windows > XP NTFS partition). Also locks up when I go into advanced options and try to > browse to the fonts manually.
Re: [Cooker] [Bug 454] [drakxtools] Fontdrake hangs.
On Sun, 2 Mar 2003, home wrote: > http://qa.mandrakesoft.com/show_bug.cgi?id=454 > > --- Additional Comments From [EMAIL PROTECTED] 2003-03-02 17:24 --- > Just tried Fontdrake on MDK 9.1 RC1 and it still hangs when trying to grab > Windows Fonts. This happens after the 1st progress bar reaches 100%. It's an NTFS driver problem. It got fixed and a new driver was released on Monday (http://linux-ntfs.sf.net/downloads.html). On Friday I tried Cooker and the fix wasn't included (I reported it). Szaka
Re: [Cooker] NTFS resizing works inRC1
On 25 Feb 2003, Adam Williamson wrote: > On Tue, 2003-02-25 at 13:56, Mike Richardson wrote: > > > > Clean XP Pro install on a 20G drive, resized to 10G. Unallocating maximum 50% is far the most general case. Windows puts metadata in the middle of the filesystem that neither the defragmenters (they shouldn't by definition) nor ntfsresize can move around, yet. However there were several reports unallocating over 80% of the disk space - probably some manufacturers made the Windows images on a smaller disk and these were just expanded later on. > > XP ran chkdsk on first boot but after that was fine. > > Yeah, the ntfs utils currently mark NTFS partitions "dirty" after doing > almost anything to them, just so that if they do do something wrong, > chkdsk / scandisk will run when you boot back to Windows and fix it > before it gets any worse. It starts with marking the volume dirty. Power outage is also possible ;) Pixel, it may make sense to present this information to the user at some point in some way not to scare them to death later on, e.g. (in non-native English): "Please note, for extra safety NTFS consistency check is scheduled to run when you boot Windows". Szaka
Re: [Cooker] [Bug 2165] [drakxtools] New: Text version of DiskDrake= BIOS boot sector virus warning
On Mon, 24 Feb 2003, mike wrote: > > On Sat, 22 Feb 2003, mike wrote: > > > >> https://qa.mandrakesoft.com/show_bug.cgi?id=2165 > >> > >> The system had a fully installed and configured Windows 2000 Pro > >> environment with the DOS and NTFS partitions listed. Anti-virus > >> software was installed and up to date. The system was running > >> fine - no issues. > >> > >> I attempted to install ML 9.1 RC1. After having the graphic > >> installers fail (even with expert mode) I attempted a text mode > >> install. The text mode install was successful. As part of that > >> install I used the text mode DiskDrake tool to build the swap and > >> linux partitions and write the new boot sector to hda. > >> > >> When I rebooted the text lilo bootloader came up, and I selected > >> linux; then BIOS ant-vires software immediately reported a boot > >> sector virus. > > > > Did you resize the NTFS partition? It must update one entry, the > > number of sectors of the new NTFS filesystem size, in the boot sector. > > If the AV software doesn't prepared/coded to take into account NTFS > > could be resized but just "blindly" does e.g. a checksumming on the boot > > sector then it can report false alarm. > > > > What AV software do you use? What virus was reported? If NTFS resizing > > is involved then I must say I've never had any such report however with > > a broken boot sector checker the situation you described is > > imaginable. > > None of the original partitions were changed or resized. The original > partition layout was set up with a Linux dual-boot in mind. After quite a > bit more testing I'm leaning towards this being a false alarm, but what > concerns me is that the only way to clear it (ever) is to do a complete > cold re-boot (power drain and all) from a floppy or CD using a utility to > overwrite the MBR with something new. > [... censored protecting the possible quilty AV software ...] > > As part of further testing, I did a complete wipe and re-install of Win > 2k. Then I used PowerQuest's Partition Magic 4.0 to move around the new > Win 2K NTFS partition and create some new Linux partitions. I even had it > change the bootable flag to a different partition. None of these actions > triggered the anti-virus warning. But every time ML 91 RC-1 had the text > DrackX / DrakDisk utility touch the MBR, an alert was triggered. Ok, if the AV software can't recognise the Linux loader (LILO, etc) then it can indeed consider it as a virus. There are many such posts (try e.g. 'lilo virus' on google). Szaka
Re: [Linux-NTFS-Dev] Re: [Cooker] [Bug 427] [drakxtools] Drakfontfreezes the whole partition
On Mon, 24 Feb 2003, Anton Altaparmakov wrote: > On Mon, 24 Feb 2003, Szakacsits Szabolcs wrote: > > > > The inode locking, needed to close iget4 race, looks totally broken. > > Hmm. That is one of my two prime suspects. [...] > /me corrects logic inversion in ntfs inode lock handling... [...] > > It works! (-: I will commit the patch to the BK ntfs-2.4 repository in a > few minutes and then make an incremental patch to ntfs 2.1.0a patch... It works for me too and the relevant code also looks totally correct now. Great job! Szaka
Re: [Cooker] [Bug 2165] [drakxtools] New: Text version of DiskDrake= BIOS boot sector virus warning
Hi Mike, On Sat, 22 Feb 2003, mike wrote: > https://qa.mandrakesoft.com/show_bug.cgi?id=2165 > > The system had a fully installed and configured Windows 2000 Pro > environment with the DOS and NTFS partitions listed. Anti-virus > software was installed and up to date. The system was running > fine - no issues. > > I attempted to install ML 9.1 RC1. After having the graphic > installers fail (even with expert mode) I attempted a text mode > install. The text mode install was successful. As part of that > install I used the text mode DiskDrake tool to build the swap and > linux partitions and write the new boot sector to hda. > > When I rebooted the text lilo bootloader came up, and I selected > linux; then BIOS ant-vires software immediately reported a boot > sector virus. Did you resize the NTFS partition? It must update one entry, the number of sectors of the new NTFS filesystem size, in the boot sector. If the AV software doesn't prepared/coded to take into account NTFS could be resized but just "blindly" does e.g. a checksumming on the boot sector then it can report false alarm. What AV software do you use? What virus was reported? If NTFS resizing is involved then I must say I've never had any such report however with a broken boot sector checker the situation you described is imaginable. Szaka
Re: [Linux-NTFS-Dev] Re: [Cooker] [Bug 427] [drakxtools] Drakfontfreezes the whole partition
On Sun, 23 Feb 2003, Anton Altaparmakov wrote: > On Sat, 22 Feb 2003, Martin Whitaker wrote: > > Using strace helped me discover why I could copy the files manually, but > > drakfont couldn't. If I execute > > > >cp /mnt/windows/c/WINDOWS/Fonts/*.ttf fonts > > > > it works every time. If I execute > > > >cp /mnt/windows/c/WINDOWS/fonts/*.ttf fonts > > > > it works sometimes and hangs sometimes. If I execute > > > >cp /mnt/windows/c/windows/fonts/*.ttf fonts > > > > it hangs every time. The point at which it hangs varies from run to run. > > This is great thanks! Yes, thanks for everybody who responded, excellent feedbacks! It's 100% posible to reproduce the hang even with standard 2.4.20+ kernels. > It points me directly at the code responsible for the hangs. The > above should hopefully allow me to reproduce the hang and fix the > problem. Most likely it is something to do with the dcache code in > fs/ntfs/namei.c::ntfs_lookup() that handles the case insensitive > file and directory names in NTFS. This is supported by the > reported trace from the kernel showing that the code hangs inside > ntfs_lookup() when the inode lock is attempted to be acquired. The inode locking, needed to close iget4 race, looks totally broken. > When I have a little spare time I will work on tracing and fixing > the problem if someone doesn't beat me to it... I'll also look at it closer as soon as possible. Szaka
Re: [Cooker] [Bug 427] [drakxtools] Drakfont freezes the wholepartition
On Sat, 22 Feb 2003, Szakacsits Szabolcs wrote: > Somebody who can reproduce the problem (I couldn't) would please > 'strace' drakfont and send the last 50-100 lines or put all output to > some downloadable place to see where the NTFS driver hangs? You can > try by starting drakfont like > > strace -f -e trace=file drakfont > > or after it's started but before importing Windows font, what makes > the driver hang, attaching to drakfont like > > strace -f -e trace=file -p BTW, it would be much better if you could do an Alt+SysRq+t (press together) from the character console and could decode the output (should go also to /var/log/dmesg or /var/log/messages) with 'ksymoops'. The Magic SysRq Key's can be enabled as echo 1 > /proc/sys/kernel/sysrq Szaka
Re: [Cooker] [Bug 427] [drakxtools] Drakfont freezes the wholepartition
Hi, Somebody who can reproduce the problem (I couldn't) would please 'strace' drakfont and send the last 50-100 lines or put all output to some downloadable place to see where the NTFS driver hangs? You can try by starting drakfont like strace -f -e trace=file drakfont or after it's started but before importing Windows font, what makes the driver hang, attaching to drakfont like strace -f -e trace=file -p A quick summary for the Linux-NTFS-Dev members (for more see the bug entries 427, 835 and 1984 at the below bug database URL): - hang is apparently CPU independent (reports on Duron and PII) - drakfont/ls can hang the driver while cp worked at the same time - reports using both Windows 2000 and XP NTFS filesystems - fgriffin (sorry, I don't have your name) suggested also a reproducible way in one of the bug entries involving Windows "shortcuts". Szaka On Fri, 21 Feb 2003, fgriffin wrote: > https://qa.mandrakesoft.com/show_bug.cgi?id=427 > > --- Additional Comments From [EMAIL PROTECTED] 2003-02-21 23:50 --- > This still fails on the Feb 21 Cooker. My processor is a PII 350, so it's not > tied to non-Intel processors. > > --- Reminder: --- > assigned_to: [EMAIL PROTECTED] > status: ASSIGNED > creation_date: > description: > I tried to get the windows fonts and drakfont got frozen, but it also made the > whole ntfs partition unaccessible, I was not able even remount it and all > programs trying to access the partition froze (for example ls). I tried it on > two system, and I got the same results. My system is: > Duron 650 on Via KT, > the disk is partitioned > > >
Re: [Cooker] [Bug 1455] [drakxtools] New: OS/2 HPFS partition shownas NTFS
On Sun, 9 Feb 2003, [Bug 1455] wrote: > https://qa.mandrakesoft.com/show_bug.cgi?id=1455 > > On one harddrive I have OS/2 installed and in DiskDrake it shows > NTFS for its partition type (which should be HPFS). I didn't check diskdrake but I guess the problem is that the NTFS detection is done based only on partition type. However this is not enough since both NTFS and HPFS uses the same partition type id, 7. An NTFS partition could be detected reading 8 bytes at offset 3 (started from 0) from the boot sector and compared with "NTFS". Szaka
