I am new here and so I will apologise in advance for my ignorance of Grub2Win. I have a lot of experience of multiboot systems but this is my first attempt using a UEFI BIOS. Windows 10 was already installed and after disabling SecureBoot I was able to do an initial installation of Debian 11 32 bit which went as far as the attempt to to install grub which failed. After doing some research I discovered that Debian doesn't support mixing 32 and 64 bit operating systems so my first quesion is does Grub2Win?
I have installed Grub2Win and that seems to have gone OK and Windows 10 still boots. The Debian partition is found OK but trying to boot that from Grub2Win gets part way into the boot process after multiple runs of /scripts/local-block with the message:
Gave up waiting for root file system device
Boot args (cat /proc/cmdline)
Missing modules (cat /proc/modules; ls /dev)
ALERT! UUID=C695F8B7-3E4F-405A-AB2A-8A3AAFBD65A0 does not exit. Dropping to a shell.
and then drops into Busybox.
I am guessing the problem is due to the failed grub install but I am unsure how to proceed? Grateful for any advice.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@drummerdp, I'm seeing the exact same error messages on a 64-bit Debian 12 laptop, but only when I boot by partition UUID. When I boot by partition label, I don't have this problem.
It's a BIOS/MBR system. The Linux partition is on an extended (logical) partition.
I have another laptop running 64-bit Linux Mint, and it will boot by partition UUID, however, the boot gets delayed/stuck at one spot in the boot sequence before finally booting. Interestingly, when booting this machine by partition label, it doesn't get stuck at that spot and the boot sequence just moves right along. This one is also a BIOS/MBR system with the Linux partition on an extended (logical) partition.
On the latter machine, I actually spent some time last year trying to figure out why it was getting delayed at boot at that one spot, but I never did figure it out -- until today when I realized that booting by partition UUID was causing it.
Any idea what could be going on? I'll get you the diagnostics when I get the chance here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dave, looking at it with fresh eyes, I've finally figured out what's going wrong! It's definitely a bug. This might need to be fixed in grub2win rather than in Linux Mint (and Debian), but you will need to advise.
What's happening in the latter case (where it gets stuck for 30 seconds) is that grub2win is incorrectly detecting and specifying an all-caps UUID for the boot init logic, but some portion of the initramfs scripts in Linux Mint is case sensitive -- and my UUID, according to Linux, is all lowercase.
What's happening under the hood is that the wait-for-root program (/usr/lib/initramfs-tools/bin/wait-for-root), used by the local initramfs script (for Linux Mint it's located at /usr/share/initramfs-tools/scripts/local), is case-sensitive regarding UUIDs. This means that the full amount of time that is defined by the slumber variable (30 seconds) in the local initramfs script is applied to the wait-for-root line in the code, timing out after 30 seconds, because it's looking for an all-caps UUID and can't find it.
For testing purposes, I added some additional code to the local script on my laptop to convert that dev-id variable to lowercase, whenever it is a UUID (basing the code on the resolve_device() function in /usr/share/initramfs-tools/scripts/functions). This gets around the problem, but this isn't a true fix, because if the UUID on someone's system happened to be all caps, then you wouldn't want to convert it to lowercase.
Shouldn't grub2win just be case sensitive when detecting and specifying the UUID?
Just so there's no confusion, what becomes the variable dev_id in the init scripts must have the letters "UUID=" before the equal sign always capitalized (which they already are), but the actual UUID that follows the equal sign needs to exactly match whatever the device UUID is in the system, case sensitive.
Last edit: mmortal03 2023-07-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The diagnostics include dumps of the partition control blocks on your particular disks.
I need to see exactly how the UUID as well as other fields are set in your blocks.
How were your partitions created?
There may be issues with the partition allocation utility that was used.
Diagnostics are a must for this case.
Thanks,
Dave
Last edit: Drummer 2023-07-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can confirm that it's the same issue on the Windows/Debian machine: grub2win is detecting and specifying an all-uppercase UUID, but on Linux, the partition UUID is properly seen by gparted as all lowercase. The boot init logic simply breaks in particular places when it is given an all-caps UUID (whenever then actual UUID is all lowercase).
I also did some googling, and for ext4 I believe the standard is all lowercase for the UUID.
I just made a "diagnose.7z" on the Windows/Debian laptop, and have edited/removed some stuff from it that had my location and IP address. I believe it still has what you need, though. I'll attach it to the next post.
The partitions were created with the Debian installer, but please keep in mind that the UUID is showing up correctly on Linux -- it is all lowercase. I believe the only source of the uppercase letters is from grub2win, but you will have to confirm this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yep, that definitely fixes it on both Mint and Debian! To be sure, the grub2win GUI still shows all-caps (which might confuse some people) but the correct case is being sent to the boot init logic.
Looks like it's time to donate! Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am new here and so I will apologise in advance for my ignorance of Grub2Win. I have a lot of experience of multiboot systems but this is my first attempt using a UEFI BIOS. Windows 10 was already installed and after disabling SecureBoot I was able to do an initial installation of Debian 11 32 bit which went as far as the attempt to to install grub which failed. After doing some research I discovered that Debian doesn't support mixing 32 and 64 bit operating systems so my first quesion is does Grub2Win?
I have installed Grub2Win and that seems to have gone OK and Windows 10 still boots. The Debian partition is found OK but trying to boot that from Grub2Win gets part way into the boot process after multiple runs of /scripts/local-block with the message:
Gave up waiting for root file system device
Boot args (cat /proc/cmdline)
Missing modules (cat /proc/modules; ls /dev)
ALERT! UUID=C695F8B7-3E4F-405A-AB2A-8A3AAFBD65A0 does not exit. Dropping to a shell.
and then drops into Busybox.
I am guessing the problem is due to the failed grub install but I am unsure how to proceed? Grateful for any advice.
Hi Martin.
I guess the larger question is why 32 bit Debian instead of 64 bit Debian?
Attempting to mix bitmodes is fraught with problems. A lot of things don't work in the opposite mode, particularly at boot time.
Also, your EFI firmware probably doesn't like 32 bit boot code.
I suggest you install Debian 11 64 bit. Then run Grub2Win and add a Debian boot menu entry.
Should be pretty straightforward.
Please let me know.
Thanks,
Dave
Hi again Martin,
Please run the Grub2Win diagnostics and send them to me.
The diagnostics will give me the information I need to better help you.
Thanks,
Dave
Thank you. Email sent with diagnostics.
Martin
On 24/11/2022 16:59, Drummer wrote:
Thank you again. Diagnostics attached. If this is going to be
difficult please don't bother and I will look for another solution.
--
Martin Liddle,
Chesterfield, Derbyshire
Hi Martin,
I did not get your email.
Please run the diagnostics again and use the upload option instead of email.
More reliable.
Thanks,
Dave
Diagnostics attached
Hi again Martin,
I received your diagnostics. Thanks.
Looking at your diagnostics, I can say that your machine is definitely running 64 bit EFI firmware.
32 bit Debian is almost certainly not going to boot in this environment.
Again, I encourage that you install 64 bit Debian.
Please let me know.
Thanks again,
Dave
@drummerdp, I'm seeing the exact same error messages on a 64-bit Debian 12 laptop, but only when I boot by partition UUID. When I boot by partition label, I don't have this problem.
It's a BIOS/MBR system. The Linux partition is on an extended (logical) partition.
I have another laptop running 64-bit Linux Mint, and it will boot by partition UUID, however, the boot gets delayed/stuck at one spot in the boot sequence before finally booting. Interestingly, when booting this machine by partition label, it doesn't get stuck at that spot and the boot sequence just moves right along. This one is also a BIOS/MBR system with the Linux partition on an extended (logical) partition.
On the latter machine, I actually spent some time last year trying to figure out why it was getting delayed at boot at that one spot, but I never did figure it out -- until today when I realized that booting by partition UUID was causing it.
Any idea what could be going on? I'll get you the diagnostics when I get the chance here.
Hi Mortal,
Yes I will need your diagnostics to troubleshoot this.
Please include a screenshot of the console at the point the hang or error happens.
You can take screenshot photos with your phone.
Thanks,
Dave
Dave, looking at it with fresh eyes, I've finally figured out what's going wrong! It's definitely a bug. This might need to be fixed in grub2win rather than in Linux Mint (and Debian), but you will need to advise.
What's happening in the latter case (where it gets stuck for 30 seconds) is that grub2win is incorrectly detecting and specifying an all-caps UUID for the boot init logic, but some portion of the initramfs scripts in Linux Mint is case sensitive -- and my UUID, according to Linux, is all lowercase.
What's happening under the hood is that the wait-for-root program (/usr/lib/initramfs-tools/bin/wait-for-root), used by the local initramfs script (for Linux Mint it's located at /usr/share/initramfs-tools/scripts/local), is case-sensitive regarding UUIDs. This means that the full amount of time that is defined by the slumber variable (30 seconds) in the local initramfs script is applied to the wait-for-root line in the code, timing out after 30 seconds, because it's looking for an all-caps UUID and can't find it.
For testing purposes, I added some additional code to the local script on my laptop to convert that dev-id variable to lowercase, whenever it is a UUID (basing the code on the resolve_device() function in /usr/share/initramfs-tools/scripts/functions). This gets around the problem, but this isn't a true fix, because if the UUID on someone's system happened to be all caps, then you wouldn't want to convert it to lowercase.
Shouldn't grub2win just be case sensitive when detecting and specifying the UUID?
Just so there's no confusion, what becomes the variable dev_id in the init scripts must have the letters "UUID=" before the equal sign always capitalized (which they already are), but the actual UUID that follows the equal sign needs to exactly match whatever the device UUID is in the system, case sensitive.
Last edit: mmortal03 2023-07-11
Hi again Mortal,
I do need your diagnostics to debug this.
The diagnostics include dumps of the partition control blocks on your particular disks.
I need to see exactly how the UUID as well as other fields are set in your blocks.
How were your partitions created?
There may be issues with the partition allocation utility that was used.
Diagnostics are a must for this case.
Thanks,
Dave
Last edit: Drummer 2023-07-11
I can confirm that it's the same issue on the Windows/Debian machine: grub2win is detecting and specifying an all-uppercase UUID, but on Linux, the partition UUID is properly seen by gparted as all lowercase. The boot init logic simply breaks in particular places when it is given an all-caps UUID (whenever then actual UUID is all lowercase).
I also did some googling, and for ext4 I believe the standard is all lowercase for the UUID.
I just made a "diagnose.7z" on the Windows/Debian laptop, and have edited/removed some stuff from it that had my location and IP address. I believe it still has what you need, though. I'll attach it to the next post.
The partitions were created with the Debian installer, but please keep in mind that the UUID is showing up correctly on Linux -- it is all lowercase. I believe the only source of the uppercase letters is from grub2win, but you will have to confirm this.
Here is the diagnose.7z file.
Hey again Mortal,
I just uploaded a new refresh of Grub2Win which I believe will fix your problem.
Download the new version 2.3.7.2 build 1610 and install it.
Run it to completion and check out the generated UUID's in the linux commands.
Then try booting your Mint or Debian systems.
Please let me know if this works for you.
Thanks again,
Dave
Yep, that definitely fixes it on both Mint and Debian! To be sure, the grub2win GUI still shows all-caps (which might confuse some people) but the correct case is being sent to the boot init logic.
Looks like it's time to donate! Thanks!
No problemo.