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�