From: David K. <da...@ke...> - 2021-06-29 02:33:55
|
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 > |