You are not logged in.
The new Arch installation media will not boot on old (BIOS only) computer. It is not recognized when the machine boots.
Latest working version: https://archive.archlinux.org/iso/2022.06.01/ .
Unofficially for some time: https://pkgbuild.com/~tpowa/archboot/is … 4/2022.10/ .
Did I miss something?
Last edited by N.T. (2022-11-03 11:13:41)
Offline
Does the machine satisfy the requires for booting the live image? (Though I doubt this is the problem if June's image works.)
Did you check the integrity of the download? How did you create the live media?
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Did you check the integrity of the download? How did you create the live media?
I haven't had a problem with it in the last five years.
Immediately noticeable difference between archlinux-2022.06.01-x86_64.iso and archlinux-2022.10.01-x86_64.iso - there is no 'loader' folder in the latest image.
Last edited by N.T. (2022-11-01 07:30:29)
Offline
cfr wrote:Did you check the integrity of the download? How did you create the live media?
I haven't had a problem with it in the last five years.
Haven't had a problem with what? I thought we were talking about ISOs from July onwards?
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
cfr, okay... I always check the integrity of the ISOs download. And I have no problem with creating live media.
archboot-archlinux-2022.10.30-06.14-latest-x86_64.iso boots perfectly in BIOS mode.
Offline
The fresh archlinux-2022.11.01-x86_64.iso is also not recognized when the computer boots. There is also no "loader" folder.
Offline
I'm not sure what you're saying...
Jun 2022 = last working version
Oct 2022 = does not work
Oct 2022 = works perfectly
Nov 2022 = also does not work
???
I downloaded and flashed the .iso last night and tested it this morning on a 2012, BIOS-only computer. Worked like a charm.
uname -a
Linux archiso 5.19.12-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 28 Sep 2022 13:21:25 +0000 x64_64 GNU/Linux
What do you see when you boot with the USB installed?
If your computer is not set to automatically boot from a USB drive, you might need to override the BIOS settings (on my Dell desktop, I need to press F2 during POST to manually over-ride the boot order and select USB rather than my hard-drive).
Last edited by dakota (2022-11-01 23:22:33)
"Before Enlightenment chop wood, carry water. After Enlightenment chop wood, carry water." -- Zen proverb
Offline
IIRC, the ISO did change from systemd-boot/syslinux to grub/grub. That's the reason there's no 'loader' dir, that's only for systemd-boot, which not only isn't used, it's UEFI only, so you wouldn't be using it anyway.
How are you writing the ISO? You seem to have skipped that question from post #2.
Last edited by Scimmia (2022-11-01 23:46:52)
Offline
???
Do you understand the difference between https://pkgbuild.com/~tpowa/archboot/web/archboot.html and https://wiki.archlinux.org/title/Archiso , between archboot-archlinux-2022.10.30-06.14-latest-x86_64.iso and archlinux-2022.11.01-x86_64.iso?
Thank you for the testing.
How are you writing the ISO?
$ cdrecord -v archlinux-2022.11.01-x86_64.iso
Offline
IIRC, the ISO did change from systemd-boot/syslinux to grub/grub.
Only the UEFI boot loader was changed (from systemd-boot to GRUB), the BIOS boot loader still remains syslinux. This change shouldn't affect BIOS booting.
Comparing (command taken from xorrisofs(1) man page)
$ xorriso -indev archlinux-2022.07.01-x86_64.iso -report_el_torito plain -report_system_area plain -print "" -print "======= Proposal for xorrisofs options:" -report_el_torito as_mkisofs
$ xorriso -indev archlinux-2022.06.01-x86_64.iso -report_el_torito plain -report_system_area plain -print "" -print "======= Proposal for xorrisofs options:" -report_el_torito as_mkisofs
shows that Ldsiz/-boot-load-size for the UEFI El Torito entry changed from 0 to 26624.
I tried creating an ISO with -boot-load-size 0 after -eltorito-alt-boot, but for some reason the option didn't have any effect
Offline
N.T., please test https://gitlab.archlinux.org/nl6720/arc … x86_64.iso (the only change is that it uses systemd-boot for UEFI and thus has a larger EFI system partition).
Test2: https://gitlab.archlinux.org/nl6720/arc … x86_64.iso . In this one the EFI system partition size is simply bumped to 32 MiB.
Last edited by nl6720 (2022-11-02 10:20:57)
Offline
N.T., please test https://gitlab.archlinux.org/nl6720/arc … x86_64.iso (the only change is that it uses systemd-boot for UEFI and thus has a larger EFI system partition).
Yes! It's working!
Test2: https://gitlab.archlinux.org/nl6720/arc … x86_64.iso . In this one the EFI system partition size is simply bumped to 32 MiB.
Coming soon...
Offline
nl6720 , unfortunately Test2 doesn't work.
Offline
Hi,
nl6720 asked me to comment with my xorriso upstream hat on.
Latest working version: https://archive.archlinux.org/iso/2022.06.01/ .
Unofficially for some time: https://pkgbuild.com/~tpowa/archboot/is … 4/2022.10/ .
the BIOS boot loader still remains syslinux.
I see GRUB as legacy BIOS bootloader in
https://pkgbuild.com/~tpowa/archboot/is … x86_64.iso
$ xorriso -indev archboot-archlinux-2022.10.30-06.14-latest-x86_64.iso -report_el_torito plain -report_system_area plain
...
El Torito boot img : 1 BIOS y none 0x0000 0x00 4 11196
...
El Torito img path : 1 /boot/grub/i386-pc/eltorito.img
In
https://archive.archlinux.org/iso/2022. … x86_64.iso
i see ISOLINUX:
$ xorriso -indev xorriso -indev archlinux-2022.06.01-x86_64.iso -report_el_torito plain -report_system_area plain
...
El Torito boot img : 1 BIOS y none 0x0000 0x00 4 119
...
El Torito img path : 1 /syslinux/isolinux.bin
So this could indeed be a problem between GRUB and the machine's firmware.
But i too am puzzled by N.T.'s statement
And I have no problem with creating live media.
archboot-archlinux-2022.10.30-06.14-latest-x86_64.iso boots perfectly in BIOS mode.
That's exactly the same file name as with the ISO where i see the GRUB
eltorito.img. Does it come from another download place ?
Or is the name a typo ?
Please give an URL for downloading this working ISO.
N.T., please test
https://gitlab.archlinux.org/nl6720/arc … x86_64.iso
(the only change is that it uses systemd-boot for UEFI and thus has a larger EFI system partition).
Yes! It's working!
This one has ISOLINUX.
This one too has ISOLINUX.
Both are not the same, despite their identical file name.
unfortunately Test2 doesn't work.
Now that's surprising.
Are you sure that the machine's firmware is legacy BIOS and not EFI ?
---------------------------------------------------------------------------
Maybe significant, if we actually deal with EFI and not BIOS:
archlinux-2022.07.01-x86_64.iso
Where to get this one ?
shows that Ldsiz/-boot-load-size for the UEFI El Torito entry changed from 0 to 26624.
The size field of the El Torito boot catalog has only 16 bit and counts
blocks of 512 bytes. So if the boot image is larger than 32 MiB - 512, then
its size cannot be expressed.
The UEFI specs prescribe that the values 0 and 1 shall cause EFI to take
the size from image start up to storage medium end as size. That's larger
than the real image size in most cases. But the UEFI image contains a FAT
filesystem which can tell its real size.
So 0 versus a value of 26624 is plausible, if one image is larger than
the limit and the other is less than half of the limit.
-----------------------------------------------------------------------
In case that the machine really works with legacy BIOS:
Several distros have changed from ISOLINUX (which is quite dead upstream)
to GRUB (which is very vivid upstream) in the last years.
There have been reports (not many) that some old machines don't boot any
more. Regrettably those complaints never got corroborated by enough facts
to take the problem to grub-devel.
What exactly do you see with the non-working ISOs ?
Does BIOS behave as if there was no bootable medium ?
Or does it go e.g. to a black screen with a single blinking underscore ?
Have a nice day
Thomas
Offline
nl6720 wrote:N.T., please test https://gitlab.archlinux.org/nl6720/arc … x86_64.iso (the only change is that it uses systemd-boot for UEFI and thus has a larger EFI system partition).
Yes! It's working!
Good. So this issue was introduced by the UEFI boot loader change.
nl6720 , unfortunately Test2 doesn't work.
That's not good. This invalidates my guess, that the your firmware is allergic to the Ldsiz/-boot-load-size value.
But i too am puzzled by N.T.'s statement
N.T. wrote:And I have no problem with creating live media.
archboot-archlinux-2022.10.30-06.14-latest-x86_64.iso boots perfectly in BIOS mode.That's exactly the same file name as with the ISO where i see the GRUB
eltorito.img. Does it come from another download place ?
Or is the name a typo ?Please give an URL for downloading this working ISO.
archboot is a project of the Arch Linux developer tpowa. The ISOs are created in a different way and not by using mkarchiso. Yo can find them at https://pkgbuild.com/~tpowa/archboot/iso/x86_64/ .
Are you sure that the machine's firmware is legacy BIOS and not EFI ?
I'm starting to get this vibe too.
N.T., please post an image of the boot loader screen of a working Arch ISO.
nl6720 wrote:archlinux-2022.07.01-x86_64.iso
Where to get this one ?
The Arch Linux Archive has them all: https://archive.archlinux.org/iso/
Scimmia wrote:How are you writing the ISO?
$ cdrecord -v archlinux-2022.11.01-x86_64.iso
You're burning the ISO to an optical disc (CD, DVD), right?
Last edited by nl6720 (2022-11-02 12:51:43)
Offline
dakota wrote:???
Do you understand the difference between https://pkgbuild.com/~tpowa/archboot/web/archboot.html and https://wiki.archlinux.org/title/Archiso , between archboot-archlinux-2022.10.30-06.14-latest-x86_64.iso and archlinux-2022.11.01-x86_64.iso?
Thank you for the testing.
Nope. Sorry. Haven't a clue. Sorry I derailed the conversation.
"Before Enlightenment chop wood, carry water. After Enlightenment chop wood, carry water." -- Zen proverb
Offline
Hi!
That's exactly the same file name as with the ISO where i see the GRUB
eltorito.img. Does it come from another download place ? Or is the name a typo ?
Please give an URL for downloading this working ISO.
There are no typos. https://pkgbuild.com/~tpowa/archboot/is … x86_64.iso
What exactly do you see with the non-working ISOs ?
Does BIOS behave as if there was no bootable medium ?
Or does it go e.g. to a black screen with a single blinking underscore ?
The BIOS behaves as if there is no bootable media.
A black screen with a single blinking underscore does not appear.
The boot loader (GRUB) of the already installed system (Debian) appears.
Are you sure that the machine's firmware is legacy BIOS and not EFI ?
I'm 100% sure. This is a 2011 machine.
Offline
scdbackup wrote:What exactly do you see with the non-working ISOs ?
Does BIOS behave as if there was no bootable medium ?
Or does it go e.g. to a black screen with a single blinking underscore ?The BIOS behaves as if there is no bootable media.
A black screen with a single blinking underscore does not appear.
The boot loader (GRUB) of the already installed system (Debian) appears.
And in the boot menu?
scdbackup wrote:Are you sure that the machine's firmware is legacy BIOS and not EFI ?
I'm 100% sure. This is a 2011 machine.
That doesn't mean anything.
Offline
And in the boot menu?
And in the boot menu... Debian!
That doesn't mean anything.
Thank you.
Offline
Offline
Hi,
the screenshot indeed looks like the entries in ISO 9660 file
/syslinux/archiso_sys-linux.cfg
and not like the GRUB menu entries in the EFI System Partition file
/EFI/BOOT/grub.cfg
which have "(x86_64, UEFI)".
The boot loader (GRUB) of the already installed system (Debian) appears.
So this BIOS does not detect the boot catalog or the BIOS image entry in
the boot catalog.
This is hard to explain, because both archlinux-2022.11.02-x86_64.iso
show nearly the same catalog listing. Working (first test):
El Torito catalog : 118 1
El Torito cat path : /syslinux/boot.cat
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 BIOS y none 0x0000 0x00 4 119
...
El Torito img path : 1 /syslinux/isolinux.bin
El Torito img opts : 1 boot-info-table isohybrid-suitable
Not working (Test 2):
El Torito catalog : 110 1
El Torito cat path : /syslinux/boot.cat
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 BIOS y none 0x0000 0x00 4 111
...
El Torito img path : 1 /syslinux/isolinux.bin
El Torito img opts : 1 boot-info-table isohybrid-suitable
The only difference is in the location of catalog and boot image. The not
working ones are located 8 * 2048 bytes earlier than the working ones.
That's very unsuspicious, because the exact address traditionally differs
from ISO to ISO, depending on how many files are stored in the ISO and how
long their names are.
Even if the BIOS image in the not working ISO would be bad somehow, the
BIOS should try to start it.
Experiment: Let's see whether the partition tables have any impact.
Copy the _not_ working ISO image "Test 2" and remove the partition tables
(MBR and GPT):
# Must be 98a0152dfc76e85ab499fb9037fe9173 or else the second dd would be wrong
md5sum archlinux-2022.11.02-x86_64.iso
cp archlinux-2022.11.02-x86_64.iso test.iso
# Overwrite MBR partition table and main GPT
dd if=/dev/zero bs=2048 count=16 conv=notrunc of=test.iso
# Overwrite backup GPT header block (seek position differs from ISO to ISO)
dd if=/dev/zero bs=512 seek=1639063 count=1 conv=notrunc of=test.iso
The size of test.iso should afterwards still be the same as of the original
ISO.
Put test.iso on an optical medium and try whether it gets recognized
as bootable (unlike the original ISO).
------------------------------------------------------------------------
A xorriso side note:
I tried creating an ISO with -boot-load-size 0 after -eltorito-alt-boot, but for some reason the option didn't have any effect
I looked into this. It's not a bug, it's a feature.
Function Xorriso_attach_boot_image in
https://dev.lovelyhq.com/libburnia/libi … rite_run.c
inquires quite unconditionally the size of the EFI boot image.
The only exception is made if the boot image was defined by a interval
of a file, like in
-append_partition 2 0xef --interval:local_fs:1558528d-1740799d::'archlinux-2022.11.02-x86_64.iso'
...
-e '--interval:appended_partition_2_start_389632s_size_182272d:all::'
In this case the size is given by the range 1558528d-1740799d.
I should think about making this case safe against unqualified size
settings, too. Any other size than the interval size can only be wrong.
Have a nice day
Thomas
Last edited by scdbackup (2022-11-02 15:15:41)
Offline
Hi!
Experiment: Let's see whether the partition tables have any impact.
$ md5sum archlinux-2022.11.02-x86_64.iso
98a0152dfc76e85ab499fb9037fe9173 archlinux-2022.11.02-x86_64.iso
$ cp archlinux-2022.11.02-x86_64.iso test.iso
$ dd if=/dev/zero bs=2048 count=16 conv=notrunc of=test.iso
16+0 records in
16+0 records out
32768 bytes (33 kB, 32 KiB) copied, 0.00031536 s, 104 MB/s
$ dd if=/dev/zero bs=512 seek=1639063 count=1 conv=notrunc of=test.iso
1+0 records in
1+0 records out
512 bytes copied, 0.00051348 s, 997 kB/s
The size of test.iso has not changed. But the optical medium is not recognized as bootable.
Last edited by N.T. (2022-11-03 11:18:11)
Offline
Hi,
just guessing around:
What do you get from an inspection of the burnt medium ?
xorriso -indev /dev/sr0 -report_el_torito plain -report_system_area plain
The output might be about 50 lines.
Have a nice day
Thomas
Offline
$ xorriso -indev /dev/sr0 -report_el_torito plain -report_system_area plain
xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project.
xorriso : NOTE : Loading ISO image tree from LBA 0
xorriso : UPDATE : 107 nodes read in 1 seconds
libisofs: NOTE : Found hidden El-Torito image for EFI.
libisofs: NOTE : EFI image start and size: 392704 * 2048 , 0 * 512
xorriso : NOTE : Detected El-Torito boot information which currently is set to be discarded
Drive current: -indev '/dev/sr0'
Media current: DVD+RW
Media status : is written , is appendable
Boot record : El Torito
Media summary: 1 session, 409766 data blocks, 800m data, 3682m free
Volume id : 'ARCH_202211'
El Torito catalog : 110 1
El Torito cat path : /syslinux/boot.cat
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 BIOS y none 0x0000 0x00 4 111
El Torito boot img : 2 UEFI y none 0x0000 0x00 0 392704
El Torito img path : 1 /syslinux/isolinux.bin
El Torito img opts : 1 boot-info-table isohybrid-suitable
El Torito img blks : 2 17062
xorriso : NOTE : No System Area was loaded
Offline