Description of problem: Launch transfugdrake with a Windows 8.1 installation. Get a message that no Windows is detected. Version-Release number of selected component (if applicable): transfugdrake-1.9.6-1.mga4 Reproducible: Steps to Reproduce:
Created attachment 6825 [details] Patch to add windows 8.1 detection This patch allows to detect that a Windows 8.1 exists. It is not tested with other version.
Summary: transfugdrake is stall on Win XP => transfugdrake needs to be adapted to recent Windows versions
The "add windows 8.1 detection" is misleading patch description as you are checking for a 64bit windows, not windows 8.1 only ... :)
CC: (none) => tmb
OK, Thomas, I have only 64bits version, but perhaps do you know the path for the 32bits version ? Thus I could adapt the patch also for 32 bits. For Windows 7, it seems that the older path is still valid. I don't if the other steps will be well proceeded, at least, I saw that the user and the folders like "My pictures" are well detected. Papoteur
Comment on attachment 6825 [details] Patch to add windows 8.1 detection This patch is wrong as it actually breaks checking for 32 bit windows.... Can you try this instead: find { $_ } map { get_windows_system_path($_, "system32/config/software"), get_windows_system_path($_, "syswow64/config"); } map { $_->{mntpoint} } @win_devices;
CC: (none) => thierry.vignaud Attachment 6825 is obsolete: 0 => 1
Created attachment 6874 [details] Add windows 64bits detection According to tv and tmb remarks
Comment on attachment 6874 [details] Add windows 64bits detection That's the same buggy patch; it'll break detecting 32bit windows as well... Just try what I told you and report if it worked
Attachment 6874 is obsolete: 0 => 1
(In reply to Thierry Vignaud from comment #6) > Comment on attachment 6874 [details] > Add windows 64bits detection > > That's the same buggy patch; it'll break detecting 32bit windows as well... > Just try what I told you and report if it worked That sounds angry, were you? If so: Papoteur would never ever deliberately attach the same patch, Thierry, nor would he ever deliberately misunderstand you.
CC: (none) => marja11
Created attachment 6879 [details] Add windows 64bits detection I hope this time it is the good one. I don't understand why it was not the good file. Sorry for that.
(In reply to papoteur from comment #8) > Created attachment 6879 [details] > Add windows 64bits detection > > I hope this time it is the good one. I don't understand why it was not the > good file. > Sorry for that. No problem, we all err at times. It stays confusing, though. Thierry asked you to try whether find { $_ } map { get_windows_system_path($_, "system32/config/software"), get_windows_system_path($_, "syswow64/config"); } map { $_->{mntpoint} } @win_devices; works. However, you don't reply to that question, but replaced a ";" with a "," in your patch (as he did), but you did not use "{ $_ } map" as he proposed (maybe there are more differences, but this is what I see now) Cheers, marja
Thanks marja for pointing out what I forgotten. Thus, with a ";": Error: Could not find the path /mnt/windows/Windows/SysWOW64/config/WINDOWS/system32/config/software Error: Could not find the path /mnt/windows/Windows/SysWOW64/config/WINNT/system32/config/software Fatal: Could not find the SOFTWARE registry hive at /mnt/windows/Windows/SysWOW64/config/WINNT/system32/config/software. Use of uninitialized value in split at /usr/lib/libDrakX/transfugdrake.pm line 46. Thus, the file names are not well formed. I hope this help. With a "," the problem is similar. Papoteur
Comment on attachment 6879 [details] Add windows 64bits detection To forget
Attachment 6879 is obsolete: 0 => 1
Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer maintained, which means that it will not receive any further security or bug fix updates. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version. Bug Reporter: Thank you for reporting this issue and we are sorry that we weren't able to fix it before Mageia 4's end of life. If you are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. If it's valid in several versions, select the highest and add MGAxTOO in whiteboard for each other valid release. Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. If you would like to help fixing bugs in the future, don't hesitate to join the packager team via our mentoring program [1] or join the teams that fit you most [2]. [1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager [2] http://www.mageia.org/contribute/
As announced over a month ago, Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer maintained, which means that it will not receive any further security or bug fix updates. This issue may have been fixed in a later Mageia release, so, if you still see it and didn't already do so: please upgrade to Mageia 5 (or, if you read this much later than this is written: make sure you run a currently maintained Mageia version) If you are able to reproduce it against a maintained version of Mageia, you are encouraged to 1. reopen this bug report, by changing the "Status" from "RESOLVED - OLD" to "REOPENED" 2. click on "Version" and change it against that version of Mageia. If you know it's valid in several versions, select the highest and add MGAxTOO in whiteboard for each other valid release. Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO. 3. give as much relevant information as possible. If you're not an experienced bug reporter and have some time: please read this page: https://wiki.mageia.org/en/How_to_report_a_bug_properly If you see a similar issue, but are _not_sure_ it is the same, with the same cause, then please file a new bug report and mention this one in it (please include the bug number, too). If you would like to help fixing bugs in the future, don't hesitate to join the packager team via our mentoring program [1] or join the teams that fit you most [2]. [1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager [2] http://www.mageia.org/contribute/
Status: NEW => RESOLVEDResolution: (none) => OLD
Still valid, because no valid patch has been applied.
Resolution: OLD => (none)Status: RESOLVED => REOPENEDVersion: 4 => Cauldron
Whiteboard: (none) => MGA5TOO
Created attachment 7896 [details] My proposed patch
CC: (none) => shlomif
What's wrong in papoteur's patch?
Keywords: (none) => PATCH
What I have tested in the past was not OK, but I don't remember why. With the actual test, I caught another problem. The program looks first for FAT or NTFS partition. It uses for that a subroutine fat_or_ntfs in fs/type.pm [1] which looks for vfat, ntfs or ntfs-3g type in fstab or mtab. However, on my system Mageia 5, the ntfs partitions are not permanently mounted, but only when the user ask for them, and thus mounted as fuseblk, which is not recognized :/ But for what I know, fuseblk is not specific to fat or ntfs. Could be a good way to add fuseblk in partition type to detect? [1] http://gitweb.mageia.org/software/drakx/tree/perl-install/fs/type.pm#n301
A bettet way would be to parse blkid, and look for TYPE="ntfs" or TYPE="vfat"
Thanks Thomas. @rindolf the lines in sub get_windows_disk() (transfugdrake) my $all_hds = fsedit::get_hds(); fs::get_raw_hds('', $all_hds); fs::get_info_from_fstab($all_hds); my $fstab = [ fs::get::fstab($all_hds) ]; fs::merge_info_from_mtab($fstab); are to be changed, thus. I presume that fs::type::type_subpart_from_magic could be used instead. Could you have a look ? Papoteur
Assignee: bugsquad => mageiatools
First you should apply you first patch if it works OK!!! Secondly, I think transfugdrake had better use isnormal_Fat_or_NTFS() instead of isFat_or_NTFS() in order to ignore ESP, recovery partitions and the like Then, for the fuse issue, you can try: fs_type_from_magic my @win_devices = grep { fs::type::isFat_or_NTFS($_) && fs::type::isMounted($_) || $_->{fs_type} eq 'fuseblk' && member(fs_type_from_magic($_), qw(vfat ntfs)) } @$fstab; instead of: my @win_devices = grep { fs::type::isnormal_Fat_or_NTFS($_) && fs::type::isMounted($_) } @$fstab; at http://gitweb.mageia.org/software/transfugdrake/tree/transfugdrake.pm#n37 (but s/isFAT_or_NTFS/isnormal_Fat_or_NTFS/ should be done first as a seperate commit in order to explain we blacklsist special ESP/recovery/... parts) BTW does diskdrake shows properly those mounted once fuse partitions as windows partitions?