I have found it sometimes helps to mount the "Microsoft Reserved" or "Microsoft System" partition before running grub-mkconfig. The os-prober package can be really dimwitted sometimes when it comes to doing scans on its own like that. On Tue, Jul 25, 2017 at 2:07 PM, Junayeed Ahnaf via arch-general < arch-general@archlinux.org> wrote:

Oh yes, I have that too. Forgot to add that, issued sudo os-prober before sudo update-grub but no luck .

On 07/26/2017 01:06 AM, Bjoern Franke wrote:

...

Am 25.07.2017 um 21:03 schrieb Junayeed Ahnaf via arch-general:

...

Hello ,

I installed arch on my laptop which has 2 hard drives , one is ssd (linux is installed there, also grub), one is HDD(with windows). So, at boot time , I can select either hard disk or ssd and can get either windows or arch. Is there a way for grub to see both Linux and Windows? I tried sudo update-grub and sudo grub-mkconfig -o /boot/grub/grub.cfg but they don't recognize windows. My windows is not uefi if that's any issue.

My linux is on /dev/sdb2 and windows on /dev/sda2 if that's any concern. Did you install os-prober?

regards Bjoern

On 07/25/2017 02:23 PM, Moses Miller via arch-general wrote:

I actually have this exact setup, and I use systemd-boot which works very well. It detects Windows automatically just fine.

<related issue> How are you handling the UTC/localtime issue between Linux/windows? Registry hack in win? Or, are you running Linux with hwclock set to localtime? If you are allowing systemd-boot, or grub, or syslinux to choose the OS, what is setting the hwclock appropriately between differing OS boots? -- David C. Rankin, J.D.,P.E.

On Wed, 26 Jul 2017 02:39:27 -0500, David C. Rankin wrote:

If you are allowing systemd-boot, or grub, or syslinux to choose the OS, what is setting the hwclock appropriately between differing OS boots?

Hi, the bootloader has got nothing to do with the way Windows or Linux does handle the hardware clock. You have to chose for each operating system's install, Windows, Linux A, Linux B, Linux n, BSD etc. how to handle the time. IOW you need to set it for each install. It's your decision what you chose. For good reasons it's recommended to chose UTC. [rocketmouse@archlinux ~]$ timedatectl | tail -6 Warning: The system is configured to read the RTC time in the local time zone. This mode can not be fully supported. It will create various problems with time zone changes and daylight saving time adjustments. The RTC time is never updated, it relies on external facilities to maintain it. If at all possible, use RTC in UTC by calling 'timedatectl set-local-rtc 0'. I'm using Linux only, no Windows, BSD etc., my settings are "freakish". Note, I don't recommend to use the same settings as I'm using. To avoid issues the time should be corrected gradually, if the clock is set back, an old file quasi could be newer than a new file, which could cause issues. IOW using local time always could cause trouble, at least when switching from/to daylight saving time. Please, read the Wiki https://wiki.archlinux.org/index.php/time . Regards, Ralf

On 07/26/2017 03:17 AM, Ralf Mardorf wrote:

Hi,

the bootloader has got nothing to do with the way Windows or Linux does handle the hardware clock. You have to chose for each operating system's install, Windows, Linux A, Linux B, Linux n, BSD etc. how to handle the time. IOW you need to set it for each install. It's your decision what you chose.

Yes, Ralf, thanks, That was the purpose. I know which boot loader you use has nothing to do with the hwclock setting, but the OS, once booted -- will. I know of two ways that people can handle the difference between windows wanting localtime and Linux wanting UTC, 1) a windows registry hack telling win the hwclock is in UTC, or 2) configuring Linux to use localtime (no longer recommended). (well, in fact, neither are recommended, but I was curious if there was some other way, other than a hack in the boot process adding or subtracting the difference between UTC and localtime and calling hwclock with either -s or -w to do it) I have a 2-drive laptop that came with w10 and I added a 1T platter for Linux to and I have simply been choosing the drive to boot via the boot drive option in the bios after manually adding/subtracting time from the time in the bios. Somewhat a pain, but given I only boot w10 every week or so to let it update, not a big deal. Thanks for the responses, seems things here are comfortably the same. -- David C. Rankin, J.D.,P.E.

Hi, when I used grub, I edited grub.cfg manually. Especially in your case this auto-configuration is absurd, since at least default Arch Linux kernels don't change their "names" after updating, neither will change the Windows chainloader entry. IOW the Linux as well as the Windows entries will never change, so the automation to write the config is completely useless. IIRC your chainloader entry should looks like this: menuentry "Windows"{ set root=(hd1,2) drivemap -s hd0 hd1 chainloader +1 } However, I also recommend to migrate to syslinux. OTOH I'm using syslinux without a Windows install, so I can't recommend it by first-hand for Windows users. Regards, Ralf -- "Pull a Homer -- to succeed despite idiocy." - The Simpsons

On Wed, 26 Jul 2017 16:20:51 +0900, Dragon ryu via arch-general wrote:

Also, making custom entry into 99-custom.cfg is good option either

For what purpose? I would completely disable this auto-crap. The grub.cfg entries for the Arch kernel(s) and for the Windows chainloader will never change, so why wasting time and energy to update grub.cfg automatically after e.g. a kernel update? It makes no sense.