Tiny Core Linux
General TC => General TC Talk => Topic started by: GNUser on February 07, 2024, 07:52:29 AM
-
I followed Juanito's wonderful instructions on how to create a device that will boot with either BIOS or (U)EFI here: https://forum.tinycorelinux.net/index.php/topic,19364.0.html
I have an old laptop with legacy BIOS, with frugal TCL installation on SSD. Thanks to Juanito's directions, my SSD can now boot in any laptop--I can continue to boot it in my old laptop, or I can transfer the SSD to a newer laptop that only supports UEFI. Tested and working! :)
I followed the same instructions to try to create a bootable USB stick with TCL on it (for rescue operations) but, surprisingly, I cannot get the stick to boot. My old laptop is able to find grub in the EFI partition, menu entries in grub.cfg are shown, but kernel cannot be found because grub claims the root filesystem is unknown.
Please see the attached screenshot. As you can see, grub is able to recognize an ext4 filesystem (hd1,gpt1) on my SSD just fine, but it cannot recognize an ext4 filesystem (at hd0,gpt1) on the USB drive. The filesystem is definitely ext4:
$ blkid /dev/sdb1
/dev/sdb1: UUID="7283ed99-3225-4add-be42-3d3031e5eb7b" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="fdf388fb-54af-4d3c-97c5-bc17455a527f"
I already tried insmod linux at the grub prompt and it didn't help. I also deleted all partitions from the USB stick and did everything again from the beginning, with same results.
Any idea why grub is unable to access the ext4 partition on /dev/sdb1 (which it sees as hd0,gpt1)?
-
The partitioning scheme of the USB drive is shown in the attached screenshot.
/mnt/sdb3/EFI/BOOT/grub/grub.cfg is also attached (I tried to include it here but got a server error).
-
Hi GNUser!
May old laptop be confused by GPT?
-
Hi jazzbiker! I don't think that's it. Same exact strategy is currently being used on this laptop's SSD, and I can boot the SSD just fine.
EDIT: I'll try to boot this USB stick on the fancy new UEFI-only laptop, to confirm that the problem is with the USB stick.
-
I think you missing the gpt drivers, try to load them into grub.cfg
insmod part_gpt
insmod part_msdos
-
I can confirm that the problem is with the USB stick, not my "old" daily driver laptop.
When I try to boot the USB stick on a fancy UEFI-only laptop, I see the same problem: I can't boot the stick and grub command line tells me this:
grub> ls (hd0,gpt1)
Partition hd0,gpt1: No known filesystem detected - Partition start at 1024KiB - Total size 26214400KiB
-
I think you missing the gpt drivers, try to load them into grub.cfg
insmod part_gpt
insmod part_msdos
Hi patrikg. That doesn't help on either (BIOS or UEFI) laptop, unfortunately.
Just to narrow down the problem, I wiped the USB drive again and created new GPT partition table, single ext4 partition, and a single helloworld.txt file in the partition. Same problem--grub cannot list the files in the partition because it claims the filesystem is "unknown".
Could it be that this USB drive does not correctly support GPT partition table?
-
Strange, your are talking about grub that not founds the thing.
I can see that you tries to get into the command line in grub.
Why not just type lsmod to see what mods being loaded.
Do you have ext4 or ext2 there ??
For I don't know reason, in my arch gpt in grub i also have fat and bli module loaded.
insmod bliinsmod fat
-
Hi GNUser!
Why not to try MBR?
-
Hi GNUser
Did you read this about removing the stick:
https://forum.tinycorelinux.net/index.php/topic,19364.msg143441.html#msg143441
-
Hi Rich. I tried that after your tip and no luck.
As a last, desperate measure, I tried the gdisk and mkfs steps in Devuan. Lo and behold, the problem goes away.
My suspicion is that the mkfs.ext4 step in TCL is silently failing to write some metadata to the usb stick. Without this metadata, grub cannot figure out the partition's filesystem and UUID.
I'd like to help pinpoint the problem. My preference is always to do everything in TCL.
-
Hi GNUser!
You may experiment with my grub4tc.sh, I never had problems with it. Still You will see a number of 'sleep 10' instructions in certain places.
-
I can confirm that this latest iteration of the USB stick (where I did gdisk and mkfs steps in Devuan) is booting just fine on my old BIOS laptop as well as on the new UEFI-only laptop.
I do have spare USB drives, of course, that I can use to troubleshoot this further.
-
Do you see the usb drive in grub ?
Or even grub need some driver to get to the usb drive ?
nativedisk ?
https://wiki.debian.org/BootUsbWithGrubRescue#Booting_a_flash_drive_with_an_image_file_written_to_it
-
Do you see the usb drive in grub ?
Yes. When I run ls at the grub command prompt, I can see the laptop's internal SSD and its ext4 parition (hd0 and hd0,gpt1 respectively) as well as the USB drive and its ext4 partition (hd1 and hd1,gpt1 respectively).
grub can show me the contents of my internal SSD with ls (hd0,gpt1)/ but cannot show me the contents of the USB drive when I try ls (hd1,gpt1)/ because it errors out with "No known filesystem". Note that both (hd0,gpt1) and (hd1,gpt1) are ext4 partitions.
I am able to browse the USB just fine when I'm fully booted into TCL on my SSD (and various tools such as gparted and blkid can tell that the USB's first partition is ext4). grub seems to be the only program confused about the USB partition's filetype.
-
Hi GNUser
... My suspicion is that the mkfs.ext4 step in TCL is silently failing to write some metadata to the usb stick. ...
Maybe try running:
e2fsck -f /dev/sdXXafter mkfs.ext4 step?
-
Are you using some old grub version ?
Or is this only then you boot from the usb ?
And what i would test, just format the partition with a lover ver of ext, like ext2.
That not have any journal.
-
Maybe try running:
e2fsck -f /dev/sdXXafter mkfs.ext4 step?
No luck. I also tried a different usb stick to exclude something wrong with the stick itself.
Can anyone reproduce this? To try, simply grab a usb stick you don't care about, then:
0. tce-load -wil gdisk e2fsprogs
1. use gdisk to delete all the partitions and create a single "Linux filesystem" (hex 8300) partition
2. use mkfs.ext4 to format the partition
3. reboot and, at grub menu, press "c" for a command prompt
4. try listing the partition's contents with ls (hdX,gptX)/
5. press Esc to leave the grub prompt and return to the grub menu
When I do 1-2 above in TCL15 x86_64, I consistently get an error at step 4.
When I do 1-2 above in Devuan, I don't get an error at step 4 using same machine, same grub, same usb stick.
-
On TCL15 x86_64 I tried using fdisk then mkfs.ext4 (instead of gdisk then mkfs.ext4). It made no difference.
I think that confirms the problem is with the mkfs.ext4 step on TCL. I'll keep investigating.
-
I tried two experiments:
Experiment 1: gdisk step in Devuan, mkfs.ext4 step in TCL15
Result: "error: unknown filesystem" in grub
Experiment 2: gdisk step in TCL, mkfs.ext4 step in Devuan
Result: no error in grub
Everything points to mkfs.ext4 creating the filesystem in a way that causes problems for grub.
-
Don't give up :)
I think you haven't read my thread.
https://forum.tinycorelinux.net/index.php/topic,26756.msg172495.html#msg172495
What grub ver ?
And why not try ext2 that have not any journal.
-
Hi, patrikg. Grub is version 2.06. I don't want to downgrade from ext4 to ext2 because journaling makes the filesystem more resistant to error.
Juanito, grub is unable to read ext4 partitions created with e2fsprogs version 1.47.0 in TCL15 x86_64. If I boot into TCL14 x86_64 and use e2fsprogs 1.46.5, the problem goes away.
-
The fix is in this (https://git.savannah.gnu.org/cgit/grub.git/commit/?id=7fd5feff97c4b1f446f8fcf6d37aca0c64e7c763) commit to grub from July 2021, which unfortunately happened just after the release of grub 2.06 in June 2021.
The problem did turn out to be related to metadata, with the grub and e2fsprogs projects being briefly out of sync regarding how partition metadata is handled. Theodore Ts'o explains the issue here (https://groups.google.com/g/linux.debian.bugs.dist/c/HiBoBMllrlU/m/RNQ6jmEuAQAJ).
The latest grub release, version 2.12, includes the fix.
-
Juanito, grub is unable to read ext4 partitions created with e2fsprogs version 1.47.0 in TCL15 x86_64. If I boot into TCL14 x86_64 and use e2fsprogs 1.46.5, the problem goes away.
I’m traveling at the moment, I should be able to update grub in two weeks time.
-
Hi GNUser
From Theodore Ts'o explanation:
There are two ways we can fix this. One is we can disable the
checksum seed feature in the Debian release of mke2fs.conf. Or we can
land this above-mentioned commit into the grub2 package. Since the
hard freeze is almost upon us, I'm happy to handle this either way.
You should be able to work around this if you want by creating mke2fs.conf.
Running grep for etc on mkfs.ext4 returns:
/usr/local/etc/mke2fs.conf
-
HI GNUser,
It's so great that you don't give up, and now found the problem.
Now I can understand why my Arch being updating grub a lot.
So just one question more if you have time to answer of course ?
Is this only related to grub when using it to usb drive ?
I haven't seen any evidences with this to any other drives I have worked with.
Maybe this because me not using UEFI a lot, yes because i don't have so many computers that uses that.
Thanks again, I like the Linux community a lot that we can help each other like we do.
-
FWIW, I've used juanito's instructions (referenced in the OP) to install Core on several different USB sticks using ext4 without any problems. With a new stick, I usually zero the first gigabyte or so with dd before starting, just so I have a clean slate.
-
i am going to quote @GNUser and also add the complete URL links below the quote(so screenshots will include the complete webpage address).
The fix is in this (https://git.savannah.gnu.org/cgit/grub.git/commit/?id=7fd5feff97c4b1f446f8fcf6d37aca0c64e7c763) commit to grub from July 2021, which unfortunately happened just after the release of grub 2.06 in June 2021.
The problem did turn out to be related to metadata, with the grub and e2fsprogs projects being briefly out of sync regarding how partition metadata is handled. Theodore Ts'o explains the issue here (https://groups.google.com/g/linux.debian.bugs.dist/c/HiBoBMllrlU/m/RNQ6jmEuAQAJ).
The latest grub release, version 2.12, includes the fix.
(from circa 2021)
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=7fd5feff97c4b1f446f8fcf6d37aca0c64e7c763
(from circa 2023)
https://groups.google.com/g/linux.debian.bugs.dist/c/HiBoBMllrlU/m/RNQ6jmEuAQAJ
(and following a link from Andreas Henriksson in the above group back to circa 2018)
https://github.com/go-debos/debos/issues/78
this years-long potential-for-breakage saga is a learning-lesson, teaching-moment, and given the severity(as evidenced by this very thread) might even be a candidate for some type of "sticky-posting" perhaps...sigh...
-
Hi smart guys!
I'm too stupid to understand the drama, could You be so kind to say one word for the dumb ones: are MBRs affected?
-
Hello friends. The bottomline is that an ext4 filesystem created with e2fsprogs version 1.47.0 with the new default options will not be recognized by grub version 2.06. I don't know whether other filesystems are also affected.
The issue has to do with filesystem metadata, so hardware (HDD, SDD, USB) and partition table (MBR, GPT) make no difference.
Among TCL versions, the problem only affects TCL15 x86_64 because it is the only TCL version whose repo has this new e2fsprogs version (1.47.0) that doesn't play nice with grub 2.06.
If you are not on TCL15 x86_64, you have nothing to worry about.
If you are on TCL15 x86_64, use grub 2.06, and need to create a new ext4 partition that will contain files that grub needs to find (e.g., vmlinuz64, corepure64.gz), you have several options:
- use an older version of e2fsprogs (e.g., 1.46.5 in TCL14 x86_64) to create the ext4 filesystem
- use repo's e2fsprogs 1.47.0 but disable checksum seed feature (see Rich's post above)
- wait until Juanito updates grub2-multi.tcz to version 2.12, reinstall grub, then use e2fsprogs 1.47.0 with default options
I hope that's clear. Rich, thread may be marked as solved.
Happy hacking!
----------
P.S. In my original post, I mentioned that my SDD worked when I converted it from BIOS-only to BIOS+UEFI. The reason is that my SDD's ext4 partition was created a long time ago with an old version of e2fsprogs. When I tried to create the bootable USB drive, I had to create a new ext4 partition on it and was doing this in TCL15 x86_64 with e2fsprogs 1.47.0. This is how I discovered the problem.
-
Hi GNUser
... Rich, thread may be marked as solved. ...
Request approved. ;D
-
I’m traveling at the moment, I should be able to update grub in two weeks time.
Hi Juanito. I updated grub2-multi.tcz for my personal use, using your build of version 2.06 as a template. Tested and working.
Would you like me to submit the updated extension for the TCL15 x86_64 repository?
-
Sure, that would be great :)
-
grub2-multi version 2.12 submitted for TCL15 x86_64 :)