I have a headless sbc. It cannot be made not headless (i.e. there is no HDMI port on the damn thing). In order to try to get synchronet to compile on it, I had to update g++ which somehow meant I needed a new kernel.

So, long story short of course it lead to a kernel panic (or something that I cannot access the board to see). Used to be I could just take the sd card out, change the grub configuration to point back to the old kernel and get access to the board again.

However, some dumbass programmer decided at some point that we need to use a new and improved grub and the only way to update anything is to edit the config and then you have to run a program to actually apply the update because that is somehow better than having only one step to do it.

OK all fine and dandy but I don't think running that update program on my laptop is going to cause the grub config on the sd card for the sbc to actually be updated.

So is there a way to get the grub on the sd card updated from another machine so that the sbc will boot again? I am thinking maybe I can rename the vmlinuz and initrd images in the /boot directory (to back them up) for the version that won't boot, and then create symlinks named after them that point to the old versions instead. That is the only think I have come up with so far but have not tried it yet. :(

---
� Synchronet � CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP

Re: Updating grub boot order w/out update-grub?
By: Dumas Walker to All on Sun Sep 22 2019 02:22 pm

So is there a way to get the grub on the sd card updated from another machine so that the sbc will boot again? I am thinking maybe I can rename the vmlinuz and initrd images in the /boot directory (to back them up) for the version that won't boot, and then create symlinks named after them that point to the old versions instead. That is the only think I have come up with so far but have not tried it yet. :(

My suggestion:

insert the card or storage media of the sbc into
a running system with a matching architecture,
mount that card and chroot to it. ie:

# mount /dev/your_card /mnt/whatever
# mount -o bind,dev /dev /mnt/whatever/dev
# mount -o bind,proc /proc /mnt/whatever/proc
# mount -o bind,sys /sys /mnt/whatever/sys
# chroot /mnt/whatever sh

Now you are inside the operating system of the
card. Configure the bootloader to your leissure
. You may also want to give other boot loaders
a try, such as Lilo or Syslinux, which imo are
way more sane for small simple setups.

---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

My suggestion:

insert the card or storage media of the sbc into
a running system with a matching architecture,
mount that card and chroot to it. ie:

# mount /dev/your_card /mnt/whatever
# mount -o bind,dev /dev /mnt/whatever/dev
# mount -o bind,proc /proc /mnt/whatever/proc
# mount -o bind,sys /sys /mnt/whatever/sys
# chroot /mnt/whatever sh

Now you are inside the operating system of the
card. Configure the bootloader to your leissure
. You may also want to give other boot loaders
a try, such as Lilo or Syslinux, which imo are
way more sane for small simple setups.

That is a great idea, thanks! BTW, I remember that I had a cable for it, serial-to-USB, I think, that allowed me to plug it in as a USB device and
boot it that way. It did boot, but the logon program is issuing a seg
fault when I try to log on! I am guessing the networking is also hosed,
which is why I could not connect via SSH or get it to respond to a ping request.

I am guessing that chrooting it is not going to fix that issue with the
logon program. I think I really hosed something up. I think I rebooted it
at the wrong time during the upgrade. It had installed the new kernel but
I was doing a "limited space" upgrade where you do an "apt-get upgrade" and then "dist-upgrade." Since the kernel had updated, I thought I should
reboot but I had only done the first of the two steps. No telling what
state I left it in. :(

Either that, or there is a problem with the board now. Seg faults can be caused by a hardware issue, but I am hoping it is either my "bad state"
theory or an issue with the SD card.

---
� SLMR 2.1a � Basic Flying Rule #1: Keep the pointy end forward.
� Synchronet � CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP