Menu
▾
▴
Re: [Astlinux-devel] Not enough free space for new firmware on the RUNNIX partition.
|
From: Lonnie A. <li...@lo...> - 2021-06-29 03:24:25
|
David, That explains what you are seeing. The 'noram' would be in the /oldroot/cdrom/os/*run.conf file(s) KCMD string. # grep '^KCMD' /oldroot/cdrom/os/*run.conf You need to mount /oldroot/cdrom read-write and remove the 'noram' option from those file(s). This 'noram' option had to be manually defined at some point, but every upgrade from then on would copy forward 'noram' if it existed. FYI, When 'noram' is set the run image is mounted via a loop device directly from the vfat partition. Normally the run image is copied to a tmpfs device from the vfat partition. Interestingly, with 'noram' set, if you did a "revert to previous" and *then a reboot* and then "upgrade with new" after the reboot it would work without messing-up the vfat partition since the loop device's filesystem would not be removed in the upgrade process. Lonnie > On Jun 28, 2021, at 9:33 PM, David Kerr <da...@ke...> wrote: > > Lonnie, > "noram" is indeed set on my test system, but not on my production. I am not conscious of having set this and I have 2GB ram assigned. But it is possible that when I first installed I had much less and then increased it later. Where is that parameter set? > > pbx-test ~ # cat /proc/cmdline > root=/dev/ram0 rw init=/linuxrc astlinux=genx86_64-vm astimg=astlinux-1.4-bdb746.run astkd=auto asturw=auto astlive noram libata.dma=3 > pbx-test ~ # > > Thanks > David > > On Mon, Jun 28, 2021 at 7:04 PM Lonnie Abelbeck <li...@lo...> wrote: > David, > > > What I am doing is "revert to previous" followed immediately by "upgrade with new" and a reboot. > > That is what I always do. > > If for some reason "noram" gets added to "cat /proc/cmdline" then that could explain what you are seeing. > > But usually "noram" is only for very tight RAM situations. Unless you added it manually. > > Lonnie > > > > > On Jun 28, 2021, at 5:49 PM, David Kerr <da...@ke...> wrote: > > > > I don't know what's going on booting into shell... I have the version that requires typing "shell". I just tried again and it failed so I'll need to investigate further. > > > > On the dirty disk problem, it occurred again. What I am doing is "revert to previous" followed immediately by "upgrade with new" and a reboot. After doing this three times I get the error. And there are three .REC files on the disk (after fsck repair). All this because, btw, /usr/sbin is no longer in unionfs so I have to make tweaks to file I am editing offline, then make a new image, upgrade, etc. > > > > David > > > > On Mon, Jun 28, 2021 at 6:36 PM Lonnie Abelbeck <li...@lo...> wrote: > > Hi David, > > > > Great you got things going again. > > > > > Worse, it looks like I cannot boot into "shell" from initial boot, whatever I select it just boots the main system. > > > > I just tested both a VMware Fusion VM and Proxmox VM and both were able to boot into "shell". Both had the latest runnix-0.6.3, though one had the old syslinux 3.x and the other had the newer syslinux 6.x ... on one I typed "shell" the other I arrowed down to "shell". Both worked for me. > > > > Being a VM gives you a lot of repair/recovery options. > > > > Lonnie > > > > > > > > > On Jun 28, 2021, at 3:44 PM, David Kerr <Da...@Ke...> wrote: > > > > > > Answering my own question... thanks to the magic of VMware I was able to attach my test vmdk image to another running astlinux VM and inside that run fsck.fat -a /dev/sdb1 (where it was attached) and that cleaned up the "dirty bit". Then I could delete 150MB of "recovered" files and now I am back in business. > > > > > > David > > > > > > On Mon, Jun 28, 2021 at 4:08 PM David Kerr <da...@ke...> wrote: > > > One of my test systems has got into a state where I cannot upgrade the firmware anymore... "Not enough free space for new firmware on the RUNNIX partition." I have tried everything I can think of to fix it. I'm having problems unmounting /dev/sda1 (device is busy) so have not been able to run fsck on it. Worse, it looks like I cannot boot into "shell" from initial boot, whatever I select it just boots the main system. > > > > > > I may just have to rebuild my test system (not a huge issue, it is afterall just a VM test system), but any suggestions on how to fix this? > > > > > > Thanks, > > > David > > > _______________________________________________ > > > Astlinux-devel mailing list > > > Ast...@li... > > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > > > > > _______________________________________________ > > Astlinux-devel mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > _______________________________________________ > > Astlinux-devel mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
