[SOLVED] Fix Windows MBR (unrecognized partition) from Manjaro

I would like to, but it is only recognized as unknowed partition type, and undetected in the file explorer, that's why I was thinking necessary fix the MBR to be able to access to it

Screenshot_20200604_010929

Yes, try the fix first.

@Marte @Wollie Well, it worked perfectly, I just had to "active" the windows partition via the diskpart tool. Thank you very much for this.

Now I'm going to try to include it to the grub by the method @Wollie told above.

1 Like

That's great! I'm glad you got it sorted out.

1 Like

A little bit more and I was formatting the partition :sweat_smile:

@Wollie said it all. I just wanted to add that if your next attempt at repair will not have the desired effect and you are going to reinstall Windows perhaps you could consider to start the whole thing from scratch. If your machine support UEFI, just create GPT disk and reinstall both Windows and Manjaro in UEFI. Backup all your personal data from both systems before. A bit of a hassle you might think, but in the long run, more manageable dualboot.

By the way there is no obviously other way to do this this by reinstalling everything I guess?

Is the dualboot working now? If so, I would leave it at that.

Nope, for now it still booting only on Windows, but I'll tell you after trying about reinstalling grub

1 Like

Did, I don't know if this is relationned with this but after selecting the OS in the grub menu, it looks booting very slow for both of them

I don't know really what might cause the slow boot. Perhaps it's time for a fresh install after all? Maybe @Wollie or some other forum member have some idea about it.

1 Like

Well my Manjaro installation have like 2 days old so I guess it's not that, but if you are reffering to a global new install, yes it could be.

The only problem for this is that I have not so recent external drives and the possibility to loose everything due to a messed up back up scares me, especially since the actual crisis, which is a problem to go to buy a new drive.

Anyway, I'm going to look a little bit about grub/boot optimisation, if it can solve something.

1 Like

First of all - you are using a HDD and not a SDD, this is most likely the biggest friction pad.

A fresh install sometimes can be slow as the file system is initializing and file indexing service of baloo if being used also takes some time. It could be that fsck is running in the background and also the selected kernel could influence the booting time. I would wait some more days before trying to improve that. Maybe share the result of entering in a terminal

systemd-analyze blame

with us, to see if there are other reasons.

1 Like

At least Manjaro looks faster (not Windows), but here is the result of the command:

$ systemd-analyze blame
10.302s systemd-journal-flush.service                      
10.297s lvm2-monitor.service                               
 5.377s dev-sda4.device                                    
 4.371s polkit.service                                     
 2.882s avahi-daemon.service                               
 2.880s bluetooth.service                                  
 2.869s NetworkManager.service                             
 2.765s systemd-logind.service                             
 2.469s systemd-modules-load.service                       
 1.958s systemd-udevd.service                              
 1.067s tlp.service                                        
 1.002s upower.service                                     
  954ms ModemManager.service                               
  817ms systemd-tmpfiles-setup-dev.service                 
  526ms systemd-random-seed.service                        
  482ms udisks2.service                                    
  460ms systemd-journald.service                           
  390ms systemd-backlight@backlight:intel_backlight.service
  270ms modprobe@drm.service                               
  270ms systemd-tmpfiles-setup.service                     
  252ms wpa_supplicant.service                             
  249ms systemd-rfkill.service                             
  219ms systemd-udev-trigger.service                       
  216ms systemd-sysctl.service                             
  181ms systemd-binfmt.service                             
  150ms rtkit-daemon.service                               
  133ms dev-hugepages.mount                                
  131ms dev-mqueue.mount                                   
  128ms sys-kernel-debug.mount                             
  126ms sys-kernel-tracing.mount                           
  110ms tmp.mount                                          
  107ms kmod-static-nodes.service                          
   83ms systemd-user-sessions.service                      
   61ms user@1000.service                                  
   48ms systemd-update-utmp.service                        
   32ms user-runtime-dir@1000.service                      
   25ms systemd-remount-fs.service                         
    3ms sys-fs-fuse-connections.mount                      
    2ms sys-kernel-config.mount                            
    2ms proc-sys-fs-binfmt_misc.mount

If you don't use lvm (for encryption) you could mask lvm2-monitor.service by entering:

systemctl stop lvm2-monitor.service
systemctl disable lvm2-monitor.service
systemctl mask lvm2-monitor.service

There are some general tips to improve system performance:

https://wiki.archlinux.org/index.php/Improving_performance

1 Like

I tried this, it looks a little bit faster, anyway I'm keeping this page about improving performance on archlinux, could be useful.

Well I suppose it's time to close this thread, @Marte and @Wollie I would probably have lost a great part of my datas without you, so thank you very much guys.

Have a nice day then, keep it up!

2 Likes

Forum kindly sponsored by