Normally I install grub2win on the netbook's hard drive and copy the install to the USB drive. This time I tried something different. I did the install on the USB drive and it worked!! Nice job Dave.
When I then executed the grub2win.exe on the USB drive it ran and noted that the EFI files needed to be updated. So far so good. But when I chose the upgrade option it found 2 drives and I think the 2 EFI folders, 1 per drive, but then only allowed upgrading the EFI folder on the netbook's hard drive. Any way to get it to finish the upgrade on the USB drive?
Ed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I understand your issue. The problem is that Grub2Win calls Microsoft's Diskpart utility to find the EFI partitions and assign drive letters. Diskpart doesn't support EFI partitions or even multiple partitions on USB drives. This is not a bug in Diskpart, it is by design. When you attempt to create multiple partitions or format an EFI partition on a USB, Diskpart gives you "The operation is not supported on removable media". I guess Microsoft doesn't want to go there.
I created a two partition EFI and NTFS setup on a USB using Gparted on Ubuntu. This worked just fine in Ubuntu, but in the Windows environment, Diskpart chokes and refuses to identify the EFI partition. EFI partition 1 on USB disk 5 should show as type "System". As you can see, it is misidentified as "Primary".
Microsoft DiskPart version 10.0.14393.0
Copyright (C) 1999-2013 Microsoft Corporation.
On computer: MAIN
Diskpart has it's limitations, but the only real alternative is to write my own partition utility. This is far beyond the scope of the Grub2Win project.
Hope this helps,
Dave
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I understand where you're coming from, and why, and while Microsoft has chosen to put it's EFI folder on a hidden FAT32 partition, the EFI folder works just fine on non-hidden, single partition, FAT32, bootable USB drives.
So, you don't have to write a partition utility, but if you could add code to test for EFI folders on FAT32 USB drives and then add the option to write updates to said EFI folders on visible FAT32 USB partitions, using the drive letter assigned to the USB drive, it would be helpful. :-)
Ed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Question is: how do you assign a drive letter to a partition without using Diskpart? The drive letter is needed to copy the EFI files. Diskpart refuses to assign a letter to a USB EFI partition, even on single partition USB drives.
Grub2Win is written in AutoIt, a language that does not have low level disk management facilities.
I believe that this would require fairly complex coding in C or Assembler.
Any ideas?
Dave
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I use the drive letter that Windows has already assigned. G: currently. setup.bat knew where it was when it ran and had no trouble creating a new grub2 folder on the USB drive. If you run a command without specifying a drive the command operates on the drive it is running on. Do an
echo "Here" > Here-I-Am.txt
and see where it is written to. No drive letters specified.
Does AutoIt use DOS commands or Linux commands? Since you refer to diskpart I would guess DOS.
Ed
Last edit: Ed P 2016-12-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
AutoIt requires the full drive letter and path to copy files. Also, the EFI files must be copied to the EFI partition, not the partition where the grub2 folder is located. The program must reliably locate the EFI partitions and verify the proper partition type string "C12A7328-F81F-11D2-BA4B-00A0C93EC93B" before assigning a drive letter to the EFI partition and copying the EFI files.
I haven't found any reliable way to accomplish this other than calling Diskpart.
Since Grub2Win.exe is strictly a Windows program, it doesn't have access to Linux utilites or services.
With thousands of users in many countries, Grub2Win cannot assume that a particular non-Windows utility or program exists on the machine. It can only call programs that exist in every Windows installation.
This why Diskpart and BCDEdit are called to do the heavy lifting for partition querys and the manipulation of the BCD and EFI firmware parameters. These two utilites have been an integral part of every Windows system from Vista onward.
Thanks again for your continued ideas and feedback. Your suggestion a while back, that I create a setup program to do the install was right on the money.
Dave
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dave, the EFI folder does not need to be on a hidden partition.
This drive boots on EFI machines.
Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.
C:\Users\Ed>dir g:
Volume in drive G is PORTEUS
Volume Serial Number is 17C8-CC62
Directory of G:\
01/30/2015 11:11 PM 1,141 USB_INSTALLATION.txt
01/26/2016 01:12 AM <DIR> boot
01/30/2015 11:11 PM <DIR> porteus
12/09/2016 02:58 PM <DIR> EFI
05/05/2016 01:42 AM <DIR> Optional
06/29/2016 07:52 PM <DIR> changes
09/26/2016 12:44 AM <DIR> modsavedat
11/19/2016 07:40 PM <DIR> Guest
11/03/2016 10:38 AM <DIR> Modules
07/23/2016 03:04 PM <DIR> My_Webpages
01/26/2016 01:32 AM <DIR> Temp
01/26/2016 01:46 AM <DIR> ISOs
01/26/2016 01:46 AM <DIR> porteus3.1
01/26/2016 01:48 AM <DIR> porteus3.x
01/26/2016 01:46 AM 270,387 grldr
12/08/2016 02:15 AM 1,336 menu.lst
12/08/2016 01:14 AM 60,544 hpnotebook.txt
11/19/2016 07:40 PM <DIR> porteus3.2
12/09/2016 02:58 PM <DIR> grub2win
01/26/2016 01:46 AM <DIR> grub2.old
12/08/2016 05:02 PM <DIR> grub2
4 File(s) 333,408 bytes
17 Dir(s) 945,668,096 bytes free
C:\Users\Ed>dir g:\efi
Volume in drive G is PORTEUS
Volume Serial Number is 17C8-CC62
Directory of g:\efi
01/26/2016 01:11 AM <DIR> .
01/26/2016 01:11 AM <DIR> ..
01/26/2016 01:11 AM <DIR> BOOT
12/09/2016 12:00 AM <DIR> grub2win
01/26/2016 01:46 AM <DIR> grub2winold
0 File(s) 0 bytes
5 Dir(s) 945,668,096 bytes free
C:\Users\Ed>dir g:\efi\boot
Volume in drive G is PORTEUS
Volume Serial Number is 17C8-CC62
Directory of g:\efi\boot
01/26/2016 01:11 AM <DIR> .
01/26/2016 01:11 AM <DIR> ..
01/26/2016 01:11 AM 12,816 background.png
01/26/2016 01:11 AM 201,416 bootx64.efi
01/26/2016 01:11 AM <DIR> drivers_x64
01/26/2016 01:11 AM <DIR> icons
12/10/2016 01:11 AM 22,903 refind.conf
01/26/2016 01:11 AM 22,329 refind.orig
4 File(s) 259,464 bytes
4 Dir(s) 945,668,096 bytes free
C:\Users\Ed>
If Grub2Win simply checks the assigned drive letter drives for an /EFI folder it can offer it as an option to be updated. No diskpart needed to do this option. In fact the setup.bat script can probably do it.
Currently I have to backup an EFI machine's hard drive,. install Grub2Win on it, boot to a Linux system on the USB drive, copy the EFI/grub2win folder on the machine's hard drive to the USB drive, then restore the machine's hard drive from the backup.
Ed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think you missed a step. The partition type character string Must be verified as "C12A7328-F81F-11D2-BA4B-00A0C93EC93B" to be considered a valid EFI partition. This is required by the standards established for EFI firmware.
Assuming that a partition is EFI standard simply because it happens to contain a directory named \efi is not sufficient.
Remember many people use this program. I have already encountered several with \efi directories on non EFI partitions. Copying files in this case would not be an expected or welcome action.
I'll make a suggestion for your very specific situation, assuming you use the G drive.
A simple .bat script to be run immediately after the Grub2win setup. It would:
1. Delete your existing G:\efi\grub2win directory
2. Create a new G:\efi\grub2win directory
3. Copy the contents of \grub2\g2bootmgr\ to G:\efi\grub2win\
Does this work for you, or am I missing something here?
Dave
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually I was thinking along the same lines before I went to bed.
C:\Users\Ed>dir g:\grub2win\install\*.cmd
Volume in drive G is PORTEUS
Volume Serial Number is 17C8-CC62
Directory of g:\grub2win\install
12/10/2016 02:22 AM 237 usbefi.cmd
1 File(s) 237 bytes
0 Dir(s) 945,664,000 bytes free
usbefi.cmd
@echo off
if not exist %~d0\EFI\ (
echo %~d0\EFI not present
pause > nul
goto EOF
)
dir %~d0\EFI
echo.
dir %~dp0g2bootmgr\
echo.
set ANS=
set /p ANS= Enter N to skip updating the EFI files, Q to Exit:
if /I "%ANS%" equ "Q" exit
if /I "%ANS%" equ "N" goto EOF
copy %~d0\EFI\grub2win\* %~d0\EFI\grub2win_bkup\
copy %~dp0\g2bootmgr\grub2win.boot64.efi %~d0\EFI\grub2win\
copy %~dp0\g2bootmgr\*.txt %~d0\EFI\grub2win\
copy %~dp0\g2bootmgr\*.cfg %~d0\EFI\grub2win\
:EOF
Still a work in progress.
I understand your concerns about following a standard when creating a new EFI folder. But in the cases you've mentioned, and mine, you're not creating a new EFI folder, or partition, your simply providing the option of updating an EFI folder that someone/something else has created with grub2win code.
BTW I believe my USB EFI folder was created by rEFInd and it works on EFI systems.
Ed
Last edit: Ed P 2016-12-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your script looks good and I think it's to best way to go for now. Yours is the only request I have received for USB EFI update. If I get more requests as time goes on, I'll re-evaluate.
One suggestion, I would change your copy statement
Thanks for looking at my script. This is what I've settled on at this point:
@echo off
if not exist %~d0\EFI\ (
echo %~d0\EFI not present
pause > nul
goto EOF
)
dir %~d0\EFI\grub2win\
echo.
dir %~dp0g2bootmgr\
echo.
set ANS=
set /p ANS= Enter N to skip updating the EFI files, Q to Exit:
echo.
if /I "%ANS%" equ "Q" exit
if /I "%ANS%" equ "N" goto EOF
echo.
if exist %~d0\EFI\grub2win_bkup\*.* (
set /p ANS=Press Enter to delete existing %~d0\EFI\grub2win_bkup\ folder:
echo.
if "%ANS%" == "" rmdir %~d0\EFI\grub2win_bkup\ /s /q
)
if not exist %~d0\EFI\grub2win_bkup\*.* md %~d0\EFI\grub2win_bkup\
xcopy %~d0\EFI\grub2win\* %~d0\EFI\grub2win_bkup\ /s /y
if errorlevel == 0 echo Backup complete.
echo. & echo.
xcopy %~dp0g2bootmgr\grub2win.boot64.efi %~d0\EFI\grub2win\ /s /y
xcopy %~dp0g2bootmgr\*.txt %~d0\EFI\grub2win\ /s /y
xcopy %~dp0g2bootmgr\*.cfg %~d0\EFI\grub2win\ /s /y
if errorlevel == 0 echo Update complete.
echo. & echo.
dir %~d0\EFI\grub2win\
:EOF
echo.
I don't copy all the .efi files since I only use grub2 on 64-bit machines.
Ed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I found an error in the grub.cfg file you sent me. It's in line 309 of the file which is in the user section. I commented it out and grub started up fine.
line 309 # set lsloop=$[ls (loop)] <===== Bad code here
As you know, Grub2Win doesn't normally alter the code in the user section. Perhaps it was corrupted in a Windows crash?
Anyway, I've attached a working grub.cfg file for you.
Interesting to note that you're line 309 is my line 298. Which ties back to my comment about new versions using old .cfg files. Your .cfg lines 18-34 are considerably different than my .cfg lines 18-31. Obviously you used a more current version of Grub2Win than mine and in that change new variables have been added and possibly old ones renamed or deleted which can impact custom user code. And I'm not saying that was the cause of my problem.
BTW What/how did you find the line in error?
Thank you again Dave.
Ed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've deleted the auto Menu Entry 1 and Menu Entry 2 entries. I'm not sure how they got created, and yes I know they were in the cfg file I uploaded, but they seemed to be named after two manual entries I have. And I didn't like the icon associated with the Menu Entry 1 menu. Too nominate.
Ed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dave,
Normally I install grub2win on the netbook's hard drive and copy the install to the USB drive. This time I tried something different. I did the install on the USB drive and it worked!! Nice job Dave.
When I then executed the grub2win.exe on the USB drive it ran and noted that the EFI files needed to be updated. So far so good. But when I chose the upgrade option it found 2 drives and I think the 2 EFI folders, 1 per drive, but then only allowed upgrading the EFI folder on the netbook's hard drive. Any way to get it to finish the upgrade on the USB drive?
Ed
Hi Ed,
I think I understand your issue. The problem is that Grub2Win calls Microsoft's Diskpart utility to find the EFI partitions and assign drive letters. Diskpart doesn't support EFI partitions or even multiple partitions on USB drives. This is not a bug in Diskpart, it is by design. When you attempt to create multiple partitions or format an EFI partition on a USB, Diskpart gives you "The operation is not supported on removable media". I guess Microsoft doesn't want to go there.
I created a two partition EFI and NTFS setup on a USB using Gparted on Ubuntu. This worked just fine in Ubuntu, but in the Windows environment, Diskpart chokes and refuses to identify the EFI partition. EFI partition 1 on USB disk 5 should show as type "System". As you can see, it is misidentified as "Primary".
Microsoft DiskPart version 10.0.14393.0
Copyright (C) 1999-2013 Microsoft Corporation.
On computer: MAIN
Disk 5 is now the selected disk.
Partition ### Type Size Offset
Partition 1 Primary 400 MB 1024 KB
Partition 0 Primary 7233 MB 401 MB
Leaving DiskPart...
Diskpart has it's limitations, but the only real alternative is to write my own partition utility. This is far beyond the scope of the Grub2Win project.
Hope this helps,
Dave
Hi Dave,
I understand where you're coming from, and why, and while Microsoft has chosen to put it's EFI folder on a hidden FAT32 partition, the EFI folder works just fine on non-hidden, single partition, FAT32, bootable USB drives.
So, you don't have to write a partition utility, but if you could add code to test for EFI folders on FAT32 USB drives and then add the option to write updates to said EFI folders on visible FAT32 USB partitions, using the drive letter assigned to the USB drive, it would be helpful. :-)
Ed
Hi Again Ed,
Question is: how do you assign a drive letter to a partition without using Diskpart? The drive letter is needed to copy the EFI files. Diskpart refuses to assign a letter to a USB EFI partition, even on single partition USB drives.
Grub2Win is written in AutoIt, a language that does not have low level disk management facilities.
I believe that this would require fairly complex coding in C or Assembler.
Any ideas?
Dave
Dave,
I use the drive letter that Windows has already assigned. G: currently. setup.bat knew where it was when it ran and had no trouble creating a new grub2 folder on the USB drive. If you run a command without specifying a drive the command operates on the drive it is running on. Do an
echo "Here" > Here-I-Am.txt
and see where it is written to. No drive letters specified.
Does AutoIt use DOS commands or Linux commands? Since you refer to diskpart I would guess DOS.
Ed
Last edit: Ed P 2016-12-09
Hey Ed,
AutoIt requires the full drive letter and path to copy files. Also, the EFI files must be copied to the EFI partition, not the partition where the grub2 folder is located. The program must reliably locate the EFI partitions and verify the proper partition type string "C12A7328-F81F-11D2-BA4B-00A0C93EC93B" before assigning a drive letter to the EFI partition and copying the EFI files.
I haven't found any reliable way to accomplish this other than calling Diskpart.
Since Grub2Win.exe is strictly a Windows program, it doesn't have access to Linux utilites or services.
With thousands of users in many countries, Grub2Win cannot assume that a particular non-Windows utility or program exists on the machine. It can only call programs that exist in every Windows installation.
This why Diskpart and BCDEdit are called to do the heavy lifting for partition querys and the manipulation of the BCD and EFI firmware parameters. These two utilites have been an integral part of every Windows system from Vista onward.
Thanks again for your continued ideas and feedback. Your suggestion a while back, that I create a setup program to do the install was right on the money.
Dave
Dave, the EFI folder does not need to be on a hidden partition.
This drive boots on EFI machines.
If Grub2Win simply checks the assigned drive letter drives for an /EFI folder it can offer it as an option to be updated. No diskpart needed to do this option. In fact the setup.bat script can probably do it.
Currently I have to backup an EFI machine's hard drive,. install Grub2Win on it, boot to a Linux system on the USB drive, copy the EFI/grub2win folder on the machine's hard drive to the USB drive, then restore the machine's hard drive from the backup.
Ed
Hi Again Ed,
I think you missed a step. The partition type character string Must be verified as "C12A7328-F81F-11D2-BA4B-00A0C93EC93B" to be considered a valid EFI partition. This is required by the standards established for EFI firmware.
See https://en.wikipedia.org/wiki/GUID_Partition_Table
Assuming that a partition is EFI standard simply because it happens to contain a directory named \efi is not sufficient.
Remember many people use this program. I have already encountered several with \efi directories on non EFI partitions. Copying files in this case would not be an expected or welcome action.
I'll make a suggestion for your very specific situation, assuming you use the G drive.
A simple .bat script to be run immediately after the Grub2win setup. It would:
Does this work for you, or am I missing something here?
Dave
Hi Dave,
Actually I was thinking along the same lines before I went to bed.
usbefi.cmd
Still a work in progress.
I understand your concerns about following a standard when creating a new EFI folder. But in the cases you've mentioned, and mine, you're not creating a new EFI folder, or partition, your simply providing the option of updating an EFI folder that someone/something else has created with grub2win code.
BTW I believe my USB EFI folder was created by rEFInd and it works on EFI systems.
Ed
Last edit: Ed P 2016-12-10
Hi Ed,
Your script looks good and I think it's to best way to go for now. Yours is the only request I have received for USB EFI update. If I get more requests as time goes on, I'll re-evaluate.
One suggestion, I would change your copy statement
and make it
to make sure that all the boot components stay in synch.
Thanks again,
Dave
Last edit: Drummer 2016-12-12
Hi Dave,
Thanks for looking at my script. This is what I've settled on at this point:
I don't copy all the .efi files since I only use grub2 on 64-bit machines.
Ed
Hey Ed,
Yes, your script looks real good now.
On your other issue:
I found an error in the grub.cfg file you sent me. It's in line 309 of the file which is in the user section. I commented it out and grub started up fine.
As you know, Grub2Win doesn't normally alter the code in the user section. Perhaps it was corrupted in a Windows crash?
Anyway, I've attached a working grub.cfg file for you.
Dave
Thank you Dave.
Interesting to note that you're line 309 is my line 298. Which ties back to my comment about new versions using old .cfg files. Your .cfg lines 18-34 are considerably different than my .cfg lines 18-31. Obviously you used a more current version of Grub2Win than mine and in that change new variables have been added and possibly old ones renamed or deleted which can impact custom user code. And I'm not saying that was the cause of my problem.
BTW What/how did you find the line in error?
Thank you again Dave.
Ed
Hi Ed,
I found the bad code by eyeball. I've been looking at Grub .cfg files so long it's just automatic.
Yikes! I need to get a life!
Dave
Wow!! You always impress Dave.
Ref: the fixed .cfg file
I've deleted the auto Menu Entry 1 and Menu Entry 2 entries. I'm not sure how they got created, and yes I know they were in the cfg file I uploaded, but they seemed to be named after two manual entries I have. And I didn't like the icon associated with the Menu Entry 1 menu. Too nominate.
Ed