| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 21 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 31:45:45 |
| Calls: | 139 |
| Files: | 91 |
| Messages: | 42,724 |
[ISO] debian-12.6.0-arm64-DVD-1.iso
If so I'll see how this boots from a micro-sd.
Cheers, Gene Heskett, CET.
On 8/3/24 19:39, gene heskett wrote:
[ISO] debian-12.6.0-arm64-DVD-1.iso
Wrote it to /dev/sdl, won't mount on sdl or sdl1. gparted says sdl2 is
the dos partition??
Now writing it to /dev/sdl1. card adapter traffic led blinks for either write.
but...:
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.
What am I doing wrong?
Thanks.
If so I'll see how this boots from a micro-sd.
Cheers, Gene Heskett, CET.
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
On 8/3/24 19:39, gene heskett wrote:
[ISO] debian-12.6.0-arm64-DVD-1.isoWrote it to /dev/sdl, won't mount on sdl or sdl1. gparted says sdl2 is the dos partition??
On Sunday, 04-08-2024 at 10:04 gene heskett wrote:
On 8/3/24 19:39, gene heskett wrote:
[ISO] debian-12.6.0-arm64-DVD-1.isoWrote it to /dev/sdl, won't mount on sdl or sdl1. gparted says sdl2 is
the dos partition??
Now writing it to /dev/sdl1. card adapter traffic led blinks for either
write.
but...:
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
I do not know what the aim of the above dd statement is, as I have yet to learn how to make use of dd.
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
But I guess a micro-sd behaves differently to a USB ?
George.
its a 128GB card.
What am I doing wrong?
Thanks.
If so I'll see how this boots from a micro-sd.
On 8/3/24 20:04, gene heskett wrote:
On 8/3/24 19:39, gene heskett wrote:
[ISO] debian-12.6.0-arm64-DVD-1.isoWrote it to /dev/sdl, won't mount on sdl or sdl1. gparted says sdl2 is
the
dos partition??
If it's meant to be written to a thumb drive to result in a bootable drive, you need to do something like
dd if=debian.iso of=/dev/sdl
(modify filenames and add flags as appropriate)
That may result in there being mountable filesystems, but it doesn't
have to
be that way. This will also wipe out any data on the _entire_ drive, so be sure that's what you want.
--
Q: Why do black holes never learn?
A: Because they're too dense. -- ZurkisPhreek on Fark
I do not know what the aim of the above dd statement is, as I have yet to learn how to make use of dd.
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
But I guess a micro-sd behaves differently to a USB ?
On 8/3/24 19:39, gene heskett wrote:
[ISO] debian-12.6.0-arm64-DVD-1.iso
Wrote it to /dev/sdl, won't mount on sdl or sdl1. gparted says sdl2 is the dos partition??
Now writing it to /dev/sdl1. card adapter traffic led blinks for either write.
but...:
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.
On 8/3/24 19:39, gene heskett wrote:
[ISO] debian-12.6.0-arm64-DVD-1.iso
Wrote it to /dev/sdl, won't mount on sdl or sdl1. gparted says sdl2 is
the dos partition??
Now writing it to /dev/sdl1.
On Sat 03 Aug 2024 at 20:04:08 (-0400), gene heskett wrote:
On 8/3/24 19:39, gene heskett wrote:
[ISO] debian-12.6.0-arm64-DVD-1.isoWrote it to /dev/sdl, won't mount on sdl or sdl1. gparted says sdl2 is
the dos partition??
With amd64-netinst ISOs, all three of /dev/sdX{,1,2} should be
mountable. sdX and sdX1 will appear identical as they both start at
sector 0. sdX2 is FAT because it's the EFI partition.
Obviously arm64-DVD ISOs might differ somewhat, but my question is
whether, having written the ISO to sdl, did you try and boot from it,
or did you mystify yourself by trying to mount the partitions and
then abandon the process in favour of:
Now writing it to /dev/sdl1.
which is an odd thing to do.
Cheers,
David.
Wrote it to /dev/sdl, won't mount on sdl or sdl1. gparted says sdl2 is the dos partition??
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.
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
But I guess a micro-sd behaves differently to a USB ?
-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
So I need some sort of a magic spell.
But I guess a micro-sd behaves differently to a USB ?
Not in this context. All your userspace sees is a block
device. The kernel takes care of the rest.
On 8/4/24 01:17, David Wright wrote:
On Sat 03 Aug 2024 at 20:04:08 (-0400), gene heskett wrote:
On 8/3/24 19:39, gene heskett wrote:
[ISO]ááá debian-12.6.0-arm64-DVD-1.iso
Yes, no response, written to /dev/sdl or to .dev/sdl1. The armbian .img's
for noble and bookworm written to /dev/sdl, booted to a cli in 30 or 40 seconds.
or did you mystify yourself by trying to mount the partitions and
then abandon the process in favour of:
Now writing it to /dev/sdl1.
that didn't work either. The 2 armbian .img files worked fine, the
debian.iso failed 100%. This thing should work for amanda, it has
recognized all 4 of the 4t SP SSD's. And in past linux installs from stretch to buster, rpi-os just worked I had built earlier versions of amanda with little problems as long as I skipped the docs. Thats always a problem for intel stuff, dependency hell, for both amanda and linuxcnc. I believe
that's my problem as the linuxcnc buildbot is doing them ok recently.
which is an odd thing to do.
Well, I'm tired of trying to make debian-arm work so you guys aren't
hassling me for bringing armbian questions here, while armbian Just Works
for everything once the network is configured. Getting the network
configured on armbian is a pita though. Never have made it work on debian-arm since wheezy.
Cheers,
David.
Thanks David, take care & stay well.
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
[ISO] debian-12.6.0-arm64-DVD-1.iso
Well, I'm tired of trying to make debian-arm work so you guys aren't
hassling me for bringing armbian questions here,
... > can this iso be put on a micro-sd
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 mountAggred, that would be handier than the turnbuttton on the outhouse door
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.)
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
That should be ok.
But I guess a micro-sd behaves differently to a USB ?
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 ?
tomas@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
.
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.)
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
That should be ok.
But I guess a micro-sd behaves differently to a USB ?
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 ?
tomas@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
.
On 04/08/2024 05:23, gene heskett wrote:
Nice, but no pi clone has ever booted from a usb stick, ever, not even
real pi's can do that.
You are one of today's lucky 10,000:
https://thepihut.com/blogs/raspberry-pi-tutorials/how-to-boot-your-raspberry-pi-from-a-usb-mass-storage-device
On 04/08/2024 05:23, gene heskett wrote:
Nice, but no pi clone has ever booted from a usb stick, ever, not even
real pi's can do that.
You are one of today's lucky 10,000:
https://thepihut.com/blogs/raspberry-pi-tutorials/how-to-boot-your-raspberry-pi-from-a-usb-mass-storage-device
Hi,
Gene Heskett wrote
[ISO] debian-12.6.0-arm64-DVD-1.iso
and later:
Well, I'm tired of trying to make debian-arm work so you guys aren't
hassling me for bringing armbian questions here,
I make a new attempt of an answer to your initial question
... > can this iso be put on a micro-sd
Yes. But it is possibly not intended for Raspberry Pi with 64 bit CPU.
---------------------------------------------------------------------- Reasoning:
It seems that Debian on Raspberry Pi has its own means of installation
https://raspi.debian.net/tested-images/
This is probaly more specialized than the arm64 ISO.
It has at least 4 different "Bookworm" images depending on the raspi
version.
I downloaded and inspected
https://raspi.debian.net/tested/20231109_raspi_4_bookworm.img.xz
fdisk yields:
Disklabel type: dos
...
Device Boot Start End Sectors Size Id Type
20231109_raspi_4_bookworm.img1 8192 1048575 1040384 508M c W95 FAT32 (
20231109_raspi_4_bookworm.img2 1048576 5119999 4071424 2G 83 Linux
Mounting partition 1 shows among a few other files, a bunch of executable programs:
-rwxr-xr-x 1 root root 2973536 Nov 9 2023 /mnt/fat/start.elf
-rwxr-xr-x 1 root root 2249280 Nov 9 2023 /mnt/fat/start4.elf
-rwxr-xr-x 1 root root 803964 Nov 9 2023 /mnt/fat/start4cd.elf
-rwxr-xr-x 1 root root 3744808 Nov 9 2023 /mnt/fat/start4db.elf
-rwxr-xr-x 1 root root 2996680 Nov 9 2023 /mnt/fat/start4x.elf
-rwxr-xr-x 1 root root 803964 Nov 9 2023 /mnt/fat/start_cd.elf
-rwxr-xr-x 1 root root 4816712 Nov 9 2023 /mnt/fat/start_db.elf
-rwxr-xr-x 1 root root 3720360 Nov 9 2023 /mnt/fat/start_x.elf
Maybe you got similar ones in your armbian system.
Obviously this image does not aim much at EFI firmware. At least no
/EFI/BOOT directory is to see.
There are no files in the Debian arm64 ISO with a name matching "*.elf".
The wiki
https://wiki.debian.org/RaspberryPi
does not point to arm64 ISOs but rather to
https://wiki.debian.org/RaspberryPiImages
which points to
https://raspi.debian.net/
Partition 2 is according to "file" an ext4 "(needs journal recovery)".
Its content looks more like GNU/Linux:
...
-rw-r--r-- 1 root root 30964073 Nov 9 2023 /mnt/ext4/boot/initrd.img-6.1.0-13-arm64
-rw-r--r-- 1 root root 32622528 Sep 29 2023 /mnt/ext4/boot/vmlinuz-6.1.0-13-arm64
...
Have a nice day :)
Thomas
.
On Sun, Aug 04, 2024 at 02:01:24AM -0400, gene heskett wrote:
On 8/4/24 01:17, David Wright wrote:
On Sat 03 Aug 2024 at 20:04:08 (-0400), gene heskett wrote:
On 8/3/24 19:39, gene heskett wrote:
[ISO] debian-12.6.0-arm64-DVD-1.iso
This will work on an arm64 board potentially that is in a desktop/server.
It will also work on a Raspbberry Pi 4 that's booting from a port of Tianocore. (EDK - the UEFI basis) [For the Pi 4, Pete Batard has done
a port].
It does seem to be a 2 stage thing. But it does by at a fraction of CYes, no response, written to /dev/sdl or to .dev/sdl1. The armbian .img's
for noble and bookworm written to /dev/sdl, booted to a cli in 30 or 40
seconds.
RIGHT - see previous note about Armbian and how they take the vendor
core support and make it boot. You've got a .img file - kernel, initrd
and (probably) u-boot in one file. You put it in and it boots.
The 30-40s is probably u-boot kicking in, initialising hardware
including any dtb and then booting up.
If you _know_ how to build u-boot for yourself, you can possibly
get it to boot anything arbitrary but at that point it gets complicated:
see, for example https://www.earth.li/~noodles/blog/2023/10/debian-on-bpi-m2-zero.html
or did you mystify yourself by trying to mount the partitions and
then abandon the process in favour of:
Now writing it to /dev/sdl1.
that didn't work either. The 2 armbian .img files worked fine, the
debian.iso failed 100%. This thing should work for amanda, it has
recognized all 4 of the 4t SP SSD's. And in past linux installs from stretch >> to buster, rpi-os just worked I had built earlier versions of amanda with
little problems as long as I skipped the docs. Thats always a problem for
intel stuff, dependency hell, for both amanda and linuxcnc. I believe
that's my problem as the linuxcnc buildbot is doing them ok recently.
which is an odd thing to do.
Well, I'm tired of trying to make debian-arm work so you guys aren't
hassling me for bringing armbian questions here, while armbian Just Works
for everything once the network is configured. Getting the network
configured on armbian is a pita though. Never have made it work on
debian-arm since wheezy.
One topic at a time, please, Gene :)
Cheers,
David.
Thanks David, take care & stay well.
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
.
/dev/sdl2 7783552 7798783 15232 7.4M ef EFI (FAT-12/16/32)
Now, that looks like something that might boot an intel system,
Now power it down, pull the card and put it back in the reader, and write
the armbian server .img file to it.
/dev/sdl1 8192 4161535 4153344 2G 83 Linux
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.
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/,
On Sat, Aug 03, 2024 at 08:04:08PM -0400, gene heskett wrote:
On 8/3/24 19:39, gene heskett wrote:
[ISO] debian-12.6.0-arm64-DVD-1.isoWrote it to /dev/sdl, won't mount on sdl or sdl1. gparted says sdl2 is the >> dos partition??
Now writing it to /dev/sdl1. card adapter traffic led blinks for either
write.
but...:
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 would be the whole card. Now how big is the sdl1 partition?
Could you please do a "sudo sfdisk -l /dev/sdl" (NOTE: NO PARTITION NUMBER SUFFIX)
for us?
thanks & cheers
Hi,
Gene Heskett wrote:
/dev/sdl2 7783552 7798783 15232 7.4M ef EFI (FAT-12/16/32)
Now, that looks like something that might boot an intel system,
Or on one of the other systems with EFI firmware.
EFI boot program names are defined for 32-bit and for 64-bit ARM CPUs.
But - as you meanwhile pointed out - there are ARM systems without EFI.
Now power it down, pull the card and put it back in the reader, and write
the armbian server .img file to it.
/dev/sdl1 8192 4161535 4153344 2G 83 Linux
Are there any files matching "start*.elf" to see in that filesystem ?
find ...where.it.is.mounted... -name 'start*.elf'
If so, then you may hope that the Debian Raspberry .img.xz and armbian
are following a similar boot path.
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.
The Debian wiki
https://wiki.debian.org/RaspberryPi
does not talk of "bootp" but points to the promising download page
https://raspi.debian.net/tested-images/
and to descriptions of particular versions like
https://wiki.debian.org/RaspberryPi4
which talks of
"Current status (2024-07)"
So it is actively maintained.
... and it has lots of detail and links to interesting tangents.
George at Clug wrote:Except it does not work, no disk activity, & no boot. And I've tried debian-arm all the way back to jessie over the years. But cleaned that directory out yesterday.
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/,
Seen from Linux userland, a USB stick and a SD card behave the same,
namely like conventional hard disks. After all you see yours as /dev/sdl,
a disk device operated by SCSI commands.
Insofar the advise is correct for your case.
Any differences between usual USB sticks and your storage device have for
now to be considered red herrings.
The obvious problem is that your system has no EFI but the Debian arm64
ISO aims at EFI as boot firmware.
Have a nice day :)
ThomasThank you Thomas. Take care & stay well yourself.
.
On 8/4/24 01:13, tomas@tuxteam.de wrote:
Could you please do a "sudo sfdisk -l /dev/sdl" (NOTE: NO PARTITION NUMBER SUFFIX)
for us?
128GB SD Card has already been overwritten with a ubuntu/noble server img. And its waiting for me to create a 30+ char root pw.
thanks & cheers
Take care & stay well yourself Tomas.