On 8/4/24 03:37, Thomas Schmitt wrote:
Hi,
Gene Heskett wrote:
Wrote it to /dev/sdl, won't mount on sdl or sdl1. gparted says sdl2 is the
dos partition??
The partition table of debian-12.6.0-arm64-DVD-1.iso is in MBR, which
many tools call "DOS".
$ /sbin/fdisk -l debian-12.6.0-arm64-DVD-1.iso
...
Disklabel type: dos
...
Device Boot Start End Sectors Size Id Type
debian-12.6.0-arm64-DVD-1.iso1 0 7783551 7783552 3.7G 83 Linux
debian-12.6.0-arm64-DVD-1.iso2 7783552 7798783 15232 7.4M ef EFI
(FAT-12/16/32)
Partition 1 is the ISO 9660 filesystem.
Partition 2 is the EFI System Partition, a FAT filesystem.
Both and also the base device should be mountable after copying.
Try in a running Linux system
dir=/mnt/iso
sudo mount debian-12.6.0-arm64-DVD-1.iso "$dir"
ls -l "$dir"
This should show
total 653
dr-xr-xr-x 1 root root 2048 Jun 29 12:24 EFI
-r--r--r-- 1 root root 9084 Jun 29 13:39 README.html
...
dr-xr-xr-x 1 root root 4096 Jun 29 12:24 pics
dr-xr-xr-x 1 root root 2048 Jun 29 12:24 pool
The start of partition 1 and the start of the base device are the same.
So it makes no difference if you mount either of them.
Now for the EFI partition (7783552 * 512 = 3985178624):
sudo umount "$dir"
sudo mount -o offset=3985178624 debian-12.6.0-arm64-DVD-1.iso "$dir"
find "$dir"
should show:
/mnt/iso
/mnt/iso/efi
/mnt/iso/efi/boot
/mnt/iso/efi/boot/bootaa64.efi
/mnt/iso/efi/boot/grubaa64.efi
/mnt/iso/efi/debian
/mnt/iso/efi/debian/grub.cfg
Both mounts together will not work properly, because the kernel people
decided that one device needs only to be mounted once. Any further mount
just repeats the first one. Use losetup(8) to create separate /dev/loopN
if you really need these two mounts at the same time.
If Linux does not show these files by mounting /dev/sdl1 and /dev/sdl2
after copying the ISO to the SD card /dev/sdl, then copying went wrong or
the kernel did not notice the change of partition tables.
With a pluggable device it is best to unplug and replug.
A fixely installed drive may show the new table after:
sudo hdparm -z /dev/sdl
(I wish we had a similar ioctl for size assessment of /dev/srX after
burning.)
gene@coyote:~/Downloads/armbian$ sudo dd if=./debian-12.6.0-arm64-DVD-1.iso
bs=4096 of=/dev/sdl1
dd: error writing '/dev/sdl1': No space left on device
its a 128GB card.
That's the wrong output device. You need to write ISOs with partitions
to the base device, not to an existing partition.
(I assume that sdl1 is smaller than the ISO.)
The iso is a 4Gb dvd .iso
the total size of /dev/sdl is 128 GB, not that ess dee ell, not ess dee
one so there's many times the size of the .isp on /dev/sdl.
The 128GB card is back in the card adapter. And I am, about to rewrite
the iso tp /dev/sdl, getting this response:
gene@coyote:~/Downloads/armbian$ sudo dd
if=./debian-12.6.0-arm64-DVD-1.iso bs=4096 of=/dev/sdl
974923+0 records in
974923+0 records out
3993284608 bytes (4.0 GB, 3.7 GiB) copied, 77.9216 s, 51.2 MB/s
the card is not at this point mounted, so removed from the reader and
inserted into the bpim5. and powered up in should boot, right? but first
a look with fdisk -l /dev/sdl:
gene@coyote:~/Downloads/armbian$ sudo fdisk -l /dev/sdl
Disk /dev/sdl: 119.08 GiB, 127865454592 bytes, 249737216 sectors
Disk model: Storage Device
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/sdl1 0 7783551 7783552 3.7G 83 Linux
/dev/sdl2 7783552 7798783 15232 7.4M ef EFI (FAT-12/16/32)
Now, that looks like something that might boot an intel system, but most
of the arm64 pi like systems use the bootp protocol, a different critter
entirely. Anyway, remove card from reader, take to bpi-m5, plug it and
power it up, No activity except for my network attempting to ID an unk
port that showed up because the cat6 is plugged in so the eth0 port is
being banged on by arp.. I need an .img file, could be bigger than a DVD
that conforms to the the bootp protocol & this isn't it.
Now power it down, pull the card and put it back in the reader, and
write the armbian server .img file to it. Takes around 4 minutes,returning:
gene@coyote:~/Downloads/armbian$ sudo dd
if=./Armbian_24.5.1_Bananapim5_noble_current_6.6.31.img bs=4096 of=/dev/sdl
[sudo] password for gene:
520192+0 records in
520192+0 records out
2130706432 bytes (2.1 GB, 2.0 GiB) copied, 141.57 s, 15.1 MB/s
And fdisk -l /dev/sdkl shows:
Disk /dev/sdl: 119.08 GiB, 127865454592 bytes, 249737216 sectors
Disk model: Storage Device
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xcc6d88bc
Device Boot Start End Sectors Size Id Type
/dev/sdl1 8192 4161535 4153344 2G 83 Linux
which to me looks like what I've seen before. plugged into the bpi-m5
and powered up, 40 seconds later its fired up the monitor and is asking
me to set a root pw.
So the $64,000 question is: where do I get a genuine debian-arm64 .img
that will boot a pi clone using the arm bootp protocol. DVD-1.iso isn't it.
Thanks.
If the base device was partitioned by GPT, then you should also zeroize
the last block of the device. Else a partition editor could come to the
idea of restoring the GPT from the backup at the end of the device.
This would destroy the partition table of the ISO image.
Zeroizing the backup GPT header block would be done by xorriso-dd-target,
if you use that script for copying.
If the SD card is removable, then i propose
https://wiki.debian.org/XorrisoDdTarget#Identify_the_device_by_plugging_and_copy_if_it_looks_safe_enough
If plugging out-and-in is not an option or if xorriso-dd-target shys
away from overwriting the existing neither-ISO-nor-FAT filesystems, then
https://wiki.debian.org/XorrisoDdTarget#How_to_overwrite_a_drive_against_the_will_of_xorriso-dd-target
It will then show you the commands which it would run if it was more
daring.
(You could of course play with the other proposals in
https://manpages.debian.org/unstable/xorriso-dd-target/xorriso-dd-target.1.en.html
)
George at Clug wrote:
If the aim is to make a bootable USB then I like to use:
# cp debian-12.6.0-arm64-DVD-1.iso /dev/sdl
Dammit, people, I am NOT making a bootable /usb device/, the pi clones
that I've played with including all the foundations output, and there
are at least 50 of these pi clone out there for a decade that can't boot
from usb. Period. End of discussion.
I'm trying to make a bootable micro-sd card from genuine debian arm64
src's..
That should be ok.
But I guess a micro-sd behaves differently to a USB ?
In this case there is a whole planet wide ecosystem based on arm's by a
dozen or more far eastern makers but I cannot find a genuine debian
image for. I'm either looking in the wrong place, or debian has zero
support for them. I can get full blown desktop linux installs that can
do anything the wintel stuff can do, from all the major distro's except
debian but ubuntu seems best. Its a ubuntu noble version thats asking
me to set a root pw right now.
Not in the booted Linux. Maybe the firmware of the computer has its own
ideas. One could ask GRUB via its command shell how it perceives the
device persentation by the firmware. I roughly guess guess from "sdl":
ls (hd12)
In general:
ls
See
https://www.gnu.org/software/grub/manual/grub/html_node/ls.html
(Experts might have better proposals for this.)
Gene Heskett wrote:
-rw-r--r-- 1 gene gene 3993284608 Aug 3 19:39 debian-12.6.0-arm64-
DVD-1.iso <-----trying to write this file to a new DVD+RW disk.
XFburn claims it can't burn yet, so I had apt install k3b and its deps.
I run k3b as me, you can see I own the iso so k3b should be able to write
it, but k3b cannot see a single file in the above
If the DVD burner is /dev/sr0, try:
xorriso -as cdrecord -v dev=/dev/sr0 -eject debian-12.6.0-arm64-DVD-1.iso
Linux will not show partitions on the burnt DVD.
But above mount commands should still yield above results:
sudo mount /dev/sr0 "$dir"
sudo umount "$dir"
sudo mount -o offset=3985178624 /dev/sr0 "$dir"
Again, umount or separate /dev/loopN devices are needed if you do not
want to see both mount points bearing the same.
So I need some sort of a magic spell.
I doubt that there is such a spell beyond properly copying the image to
the base device.
Gene Heskett wrote:
But I guess a micro-sd behaves differently to a USB ?
to...@tuxteam.de wrote:
Not in this context. All your userspace sees is a block
device. The kernel takes care of the rest.
But what is before the kernel gets started ?
First comes the firmware, then GRUB, and then Linux.
So there is still enough room for differences between USB stick and SD
card. It would be odd, of course.
Maybe the firmware thinks too much about ISO 9660 and El Torito.
Or maybe the firmware does not feel properly addressed by the MBR
partition table or by the EFI start program bootaa64.efi .
(If it was "armhf", then the EFI program would need to have the name
"bootarm.efi". The "armel" ISOs have no recognizable boot equipment.)
Have a nice day :)
Thomas
.
Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
