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ã