Re: [Astlinux-devel] Not enough free space for new firmware on the RUNNIX partition.

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Thanks Lonnie.  I have updated my KCMD entries, with luck I won't run into
this again.

Thanks for your help.

David

On Mon, Jun 28, 2021 at 11:24 PM Lonnie Abelbeck <li...@lo...>
wrote:

> 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
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>