refractasnapshot-base syslinux arm64

arm64_newbie · 2024-12-26 14:48:05

I have Debian Bookworm sysvinit on a credit card sized arm64 pc.
I am trying to install refractasnapshot-base and have all dependencies installed except syslinux.
Correct me if I am mistaken but it appears that syslinux arm64 does not exist.
What can we do!

ralph.ronnquist · 2024-12-26 22:01:42

In short I think you can reuse the debian boot setup and just replace the root filesystem.

If your debian system is on an SD-card, then you should copy that whole card (including the MBR sectors), then mount the root filesystem partition (of the copy) on another computer so as to replace the whole filesystem with a devuan/arm64 root filesystem. The latter you can set up using debootstrap, and the best is to just make a "minbase" variant; then you would install the rest oer the network on the target after bootup.

EDIT: BUT do remeber to keep the few extra files in /boot (boot.scr and the dtb tree), AND you should also make sure to keep the 99-uboot script (/etc/initramfs/post-update.d/99-uboot) that makes an uImage of the initrd as hook for update-initramfs.... it requires that you install u-boot-tools and device-tree-compiler. You may also need a light hand-edit of that script which otherwise will want to source enironment settings that are not needed for the function of the script.

arm64_newbie · 2024-12-27 12:07:11

I have already done a Debian live-build, I could see that Refracta is built on this.
On an amd64 pc I am quite familiar with using refractasnapshot in Devuan, most pleasant indeed.
Unlike live-build, refractasnapshot don't need to be connected to network.
I started looking at documentation for live-build, but found it truly quite awful, even for Linux.
I am not being lazy posting here, just seeking some ideas.
Does a Debian arm64 installer iso boot syslinux?
I will determine.
I am grateful for your reply.

arm64_newbie · 2024-12-27 12:44:35

I have just mount -o loop the arm64 netinstall iso on /tmp
I guess I don't need to dd the iso to a TF card, but I can.
boot folder & EFI folder is all grub.

RedGreen925 · 2024-12-27 12:49:55

Does a Debian arm64 installer iso boot syslinux?

From playing around with my Pi4 they use uboot I believe it is as they have all the files required to boot in the /boot directory with the device tree overlays (.dtb files) that are used. They do not boot the same way as other machines. Now I mount the drive for it they are in the / of the drive.

root@9600k:~# mount /dev/sdb1 /tmp/root
root@9600k:~# ll /tmp/root/
total 128528
-rwxrwxr-x 1 root root    26538 Sep 10 05:54 bcm2711-rpi-4-b.dtb
-rwxrwxr-x 1 root root    27111 Sep 10 05:54 bcm2711-rpi-cm4-io.dtb
-rwxrwxr-x 1 root root    14723 Sep 10 05:54 bcm2837-rpi-3-a-plus.dtb
-rwxrwxr-x 1 root root    14995 Sep 10 05:54 bcm2837-rpi-3-b.dtb
-rwxrwxr-x 1 root root    15351 Sep 10 05:54 bcm2837-rpi-3-b-plus.dtb
-rwxrwxr-x 1 root root    14369 Sep 10 05:54 bcm2837-rpi-cm3-io3.dtb
-rwxrwxr-x 1 root root    52456 Jul  1 22:58 bootcode.bin
-rwxrwxr-x 1 root root       99 Sep 10 05:54 cmdline.txt
-rwxrwxr-x 1 root root      289 Sep 10 05:54 config.txt
-rwxrwxr-x 1 root root     3187 Jul  1 22:58 fixup4cd.dat
-rwxrwxr-x 1 root root     5448 Jul  1 22:58 fixup4.dat
-rwxrwxr-x 1 root root     8452 Jul  1 22:58 fixup4db.dat
-rwxrwxr-x 1 root root     8454 Jul  1 22:58 fixup4x.dat
-rwxrwxr-x 1 root root     3187 Jul  1 22:58 fixup_cd.dat
-rwxrwxr-x 1 root root     7314 Jul  1 22:58 fixup.dat
-rwxrwxr-x 1 root root    10298 Jul  1 22:58 fixup_db.dat
-rwxrwxr-x 1 root root    10298 Jul  1 22:58 fixup_x.dat
-rwxrwxr-x 1 root root 27165545 Aug 11 04:17 initrd.img-5.10.0-31-arm64
-rwxrwxr-x 1 root root 27166803 Sep 10 05:54 initrd.img-5.10.0-32-arm64
-rwxrwxr-x 1 root root   793116 Jul  1 22:58 start4cd.elf
-rwxrwxr-x 1 root root  3722504 Jul  1 22:58 start4db.elf
-rwxrwxr-x 1 root root  2228800 Jul  1 22:58 start4.elf
-rwxrwxr-x 1 root root  2981192 Jul  1 22:58 start4x.elf
-rwxrwxr-x 1 root root   793116 Jul  1 22:58 start_cd.elf
-rwxrwxr-x 1 root root  4794472 Jul  1 22:58 start_db.elf
-rwxrwxr-x 1 root root  2952960 Jul  1 22:58 start.elf
-rwxrwxr-x 1 root root  3704808 Jul  1 22:58 start_x.elf
-rwxrwxr-x 1 root root     1076 Oct  1 23:58 sysconf.txt
-rwxrwxr-x 1 root root 27469760 Aug 11 04:17 vmlinuz-5.10.0-31-arm64
-rwxrwxr-x 1 root root 27469760 Sep 10 05:54 vmlinuz-5.10.0-32-arm64

Edit: Now I remember and clue in that was the firmware partition that is mounted as /boot/firmware.

root@9600k:~# mount /dev/sdb2 /tmp/root
root@9600k:~# cat /tmp/root/etc/fstab 
# The root file system has fs_passno=1 as per fstab(5) for automatic fsck.
LABEL=RASPIROOT / ext4 rw 0 1
# All other file systems have fs_passno=2 as per fstab(5) for automatic fsck.
LABEL=RASPIFIRM /boot/firmware vfat rw 0 2
root@9600k:~# blkid |grep RASPI |sort -n
/dev/sdb1: SEC_TYPE="msdos" LABEL_FATBOOT="RASPIFIRM" LABEL="RASPIFIRM" UUID="0570-6A9B" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="a2760bd5-f1e2-4765-a0ec-ca7ed959c066"
/dev/sdb2: LABEL="RASPIROOT" UUID="b00e7b01-391c-4729-85b4-7aa97205664a" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="08aa064e-f0a4-492e-a096-45b797c76e22"

Last edited by RedGreen925 (2024-12-27 12:57:48)

arm64_newbie · 2024-12-27 13:08:03

I'm starting with a Khadas VIM1 pc, board been out 10 years.
I use vanilla Debian|Devuan installer, not bespoke u-boot particular installer iso.
I installed offline and chroot /target sysvinit & dependencies
I have u-boot bootable TF card & chainload rEFIind takes me to grub 'automatic.'
for sysvinit to work I have to add kernel boot console=ttyAML0 console=tty0
inittab T0:23:respawn:/sbin/getty -L ttyAML0 vt100
‘Activate’ RTC chip, generate hwclock.
touch /etc/init.d/hwclock0.sh
chmod 755 /etc/init.d/hwclock0.sh
#!/bin/sh
case “$1” in
start)
echo hym8563 0x51 > /sys/class/i2c-adapter/i2c-1/new_device
;;
esac

https://forum.khadas.com/t/howto-not-to … os/23517/7

Last edited by arm64_newbie (2024-12-27 13:13:48)

arm64_newbie · 2024-12-27 13:10:51

My basic idea is please Devuan can you ditch the syslinux dependency from your marvellous Refracta tools.

arm64_newbie · 2024-12-27 13:23:22

Mine,
/usr/lib/linux-image-6.1.0-28-arm64/amlogic/meson-gxl-s905x-khadas-vim.dtb

I'm Logout for 90 mins now.

Last edited by arm64_newbie (2024-12-27 13:24:53)

arm64_newbie · 2024-12-27 15:41:59

I used to love lilo very much, and syslinux was really great until about version 4 or 6 or something, but now I think it's time for syslinux to be below ground.

Last edited by arm64_newbie (2024-12-27 16:30:46)

RedGreen925 · 2024-12-27 16:14:14

I used to love lilo very much

Indeed me too but we needed to yet again chase the new shinny, a wide spread disease in Linux, get something working great then they have to blow it all up and start with the latest fad yet again. I do not know how many times I have seen it happen in these few decades of using it, to numerous to list really.

arm64_newbie · 2024-12-27 16:27:40

If it wasn't for Roderick rEFInd's work at Ubuntu, we'd all be stuck in Windows and unable to boot Linux.
More hooks & backdoors than a bordello full of gilfs.

arm64_newbie · 2024-12-27 17:05:48

The whole point is the present|future is open-source, it WILL manifest, it's called evolution.

arm64_newbie · 2024-12-27 17:15:13

forums.debian.net is a fantastic forum, but it's a bit large, this forum is probably the best on earth.
Pity chewitt is not on it.
I don't know why fredsmith ain't inputted yet, I sincerely do hope very much indeed, to say the least, that he is in good health.
Ideally he is sat in a comfortable armchair, doing absolutely nothing, cept hitting a second bottle of single malt.
At the end of the day I'll get Ridley Scott to fix 20 lines of code . . .

arm64_newbie · 2024-12-27 17:23:05

Regular users need to be able to do the work they need to do, not everybody is a Doctor of nanotechnology and silicon technology who can sort it.
A user needs to be able to generate a pristine live, this is what Shingledecker & Kauler et al have been working on for ages.
It's irrelevant who you are, a regular bloke moving money, or special forces.
Everything is about the timing.

Last edited by arm64_newbie (2024-12-27 17:31:05)

c0rnelius · 2024-12-29 14:53:28

If the unit is using U-Boot, which most are, you could use Extlinux instead of boot scripts. No packages are required to be installed. It is the ARM / RISCV variant of Syslinux.

Example:

bananapi: ~  $ cat /boot/extlinux/extlinux.conf
label default
	kernel ../Image
	initrd ../uInitrd
	fdtdir ../amlogic/
	fdt ../amlogic/meson-g12b-bananapi-cm4-cm4io.dtb
	fdtoverlays ../amlogic/overlays/meson-g12b-bananapi-cm4-pwm-gpioh-5-fan.dtbo
	append earlyprintk console=tty1 console=ttyAML0,115200n8 rw root=PARTUUID=8e95b500-02 rootwait rootfstype=xfs fsck.repair=yes loglevel=1 net.ifnames=0 no_console_suspend init=/sbin/init

fsmithred · 2025-03-05 21:44:19

Sorry I missed this thread when it was new. Running refractasnapshot without syslinux would result in the script failing because it looks for syslinux/isolinux files to put into the iso. It might be possible to run it and then chroot into the filesystem copy to make changes and then run the xorriso command manually to pack it into an iso file.

I don't have any arm hardware to play with this. If anyone figures out how to do it, please let me know. If someone feels competent enough to try, I can help with pointing where to look in the script so they don't have to follow every strand of spaghetti.

dzz · 2025-03-06 19:01:52

Refractasnapshot (sort of) working here on arm64, a Raspberry Pi 3b+.

I recompiled refractasnapshot from source tarball. Far as I can see it doesn't need dependency on syslinux. Most (all?) of the syslinux files to be copied over are actually part of syslinux-common, that's for all arches. For Daedalus at least. Kept isolinux (not arch-specific) dependency.

I also disabled in the script, the part where ssh is modified, by making it a function which doesn't actually run. Not sure if that was actually necessary but first try, I couldn't ssh it and this machine is intended to be headless.

Only other changes were refractasnapshot.conf and snapshot_exclude.list to suit.

This pi has uefi emulation boot (not uboot) therefore I can use grub to boot the snapshot iso. And boot it does, given the right cmdline (note "nocomponents" to disable live-config). It networks automatically and accepts ssh.

Snip from /etc/grub.d/40_custom:

menuentry "Refractasnapshot ARM ISO boot" {
  set isofile="(hd0,2)/home/snapshot/snapshot.iso"
  loopback loop $isofile
  linux    (loop)/live/vmlinuz-6.13.0-rc7 boot=live findiso=/home/snapshot/snapshot.iso nocomponents 
  initrd   (loop)/live/initrd.img-6.13.0-rc7

}

How useful this all is is another matter, the machine itself first needs a working grub (maybe not extlinux) to boot an actual iso. The other snapshot files, outside /live, are probably redundant in this scenario. Anyway it's a good backup and potentially installable.

fsmithred · 2025-03-07 10:37:57

Of course, having someone who knows where to look is even better. Thanks, dzz.

I'm not sure what's up with ssh. In the excalibur isos I've made recently, live-config keeps turning off password authentication. I resorted to making a live-config script to look for 'SSH-ON' in the boot command.

dzz · 2025-03-07 19:33:25

(Apologies, off-topic): My previous script ssh edits were unnecessary. Whatever is in the script's ssh function (hence the final iso) gets changed by live-config's openssh-server on boot. Only way round that is, disable it (and deal with the security risk yourself) or make a custom live-config script to run after it. Or use a "live-hook" script which could go in /live.

I disabled it on the cmdline. In fact I disabled live-config altogether, for this build, none of it is needed.

Or chmod -x it, dpkg-divert it or delete it.. but.. I noticed in refractasnapshot-base_10.4.2 line 824>:

# Enable or disable password login through ssh for users (not root)
# Remove obsolete live-config file 
if [[ -e "$work_dir"/myfs/lib/live/config/1161-openssh-server ]] ; then
	rm -f "$work_dir"/myfs/lib/live/config/1161-openssh-server
fi

That won't work, it's actually "1160-openssh-server" in Daedalus>!

On topic, I added near the top of the mkefi function a test for arm64

# Detect if arch is arm64
arch=$(dpkg --print-architecture)
if [ "$arch" = "amd64" ]; then

	efi_files="x86_64-efi"
	efi_binary="bootx64.efi"

elif [ "$arch" = "arm64" ]; then
	efi_files="arm64-efi"
	efi_binary="bootaa64.efi"
fi

Then replaced further down all instances of x86_64-efi with ${efi_files} and bootx64.efi with ${efi_binary}.

It works and produces arm64-efi files and bootaa64.efi in the iso.
Not that it's of much use if your hardware can't boot an iso directly..

Last edited by dzz (2025-03-07 20:26:48)

fsmithred · 2025-03-07 20:34:14

I think 1161-openssh-server was a hack that I threw into Refracta isos and then later wanted to make sure it was gone. That's a good reminder of why I should use a hook script instead. Thanks.

dzz · 2025-03-16 16:19:21

I think the OP's original question is mostly answered, i.e. refractasnapshot can work on arm64 with some very minor modification. At least for efi-capable hardware. I don't agree that isolinux/syslinux is deprecated (yet), it remains a boot iso standard for bios/mbr hardware. Most such iso's also include grub for efi including refractasnapshot. But I have still more to add, re Refracta tools + arm64

We already have tested that another grub can boot the iso image via "loopback". Now I see that, although this machine seems unable to boot a dd'd isohybrid (pukes on loading the kernel), it can boot a usb with the snapshot live iso files simply copied.

Now I discover that refractainstaller can work on arm64 without modification! A live snapshot here was installed to a dedicated partition (not on the boot drive) and can be booted with, so far, no apparent problems. I chose to not do grub-install, I have grub manually configured elsewhere.

The officially official Devuan Forum!

#1 2024-12-26 14:48:05

refractasnapshot-base syslinux arm64

#2 2024-12-26 22:01:42

Re: refractasnapshot-base syslinux arm64

#3 2024-12-27 12:07:11

Re: refractasnapshot-base syslinux arm64

#4 2024-12-27 12:44:35

Re: refractasnapshot-base syslinux arm64

#5 2024-12-27 12:49:55

Re: refractasnapshot-base syslinux arm64

#6 2024-12-27 13:08:03

Re: refractasnapshot-base syslinux arm64

#7 2024-12-27 13:10:51

Re: refractasnapshot-base syslinux arm64

#8 2024-12-27 13:23:22

Re: refractasnapshot-base syslinux arm64

#9 2024-12-27 15:41:59

Re: refractasnapshot-base syslinux arm64

#10 2024-12-27 16:14:14

Re: refractasnapshot-base syslinux arm64

#11 2024-12-27 16:27:40

Re: refractasnapshot-base syslinux arm64

#12 2024-12-27 17:05:48

Re: refractasnapshot-base syslinux arm64

#13 2024-12-27 17:15:13

Re: refractasnapshot-base syslinux arm64

#14 2024-12-27 17:23:05

Re: refractasnapshot-base syslinux arm64

#15 2024-12-29 14:53:28

Re: refractasnapshot-base syslinux arm64

#16 2025-03-05 21:44:19

Re: refractasnapshot-base syslinux arm64

#17 2025-03-06 19:01:52

Re: refractasnapshot-base syslinux arm64

#18 2025-03-07 10:37:57

Re: refractasnapshot-base syslinux arm64

#19 2025-03-07 19:33:25

Re: refractasnapshot-base syslinux arm64

#20 2025-03-07 20:34:14

Re: refractasnapshot-base syslinux arm64

#21 2025-03-16 16:19:21

Re: refractasnapshot-base syslinux arm64

Board footer