Menu
▾
▴
astlinux-devel — The AstLinux development environment, compilation, etc
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
(41) |
Apr
(35) |
May
(18) |
Jun
(5) |
Jul
(4) |
Aug
(37) |
Sep
(9) |
Oct
(20) |
Nov
(50) |
Dec
(217) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(212) |
Feb
(76) |
Mar
(113) |
Apr
(88) |
May
(130) |
Jun
(54) |
Jul
(208) |
Aug
(223) |
Sep
(112) |
Oct
(63) |
Nov
(131) |
Dec
(103) |
| 2010 |
Jan
(247) |
Feb
(130) |
Mar
(43) |
Apr
(92) |
May
(40) |
Jun
(43) |
Jul
(43) |
Aug
(80) |
Sep
(44) |
Oct
(74) |
Nov
(21) |
Dec
(46) |
| 2011 |
Jan
(36) |
Feb
(11) |
Mar
(21) |
Apr
(33) |
May
(4) |
Jun
(12) |
Jul
(5) |
Aug
(20) |
Sep
|
Oct
(64) |
Nov
(26) |
Dec
(71) |
| 2012 |
Jan
(13) |
Feb
(24) |
Mar
(11) |
Apr
(2) |
May
(10) |
Jun
(5) |
Jul
(13) |
Aug
(7) |
Sep
(26) |
Oct
(22) |
Nov
(17) |
Dec
(16) |
| 2013 |
Jan
(6) |
Feb
(6) |
Mar
(6) |
Apr
(8) |
May
(20) |
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(18) |
Oct
(3) |
Nov
(14) |
Dec
(33) |
| 2014 |
Jan
(26) |
Feb
(6) |
Mar
(69) |
Apr
(10) |
May
|
Jun
(8) |
Jul
(18) |
Aug
(22) |
Sep
(19) |
Oct
(17) |
Nov
|
Dec
(4) |
| 2015 |
Jan
(14) |
Feb
(18) |
Mar
|
Apr
|
May
(26) |
Jun
(8) |
Jul
(9) |
Aug
(10) |
Sep
(15) |
Oct
(2) |
Nov
(30) |
Dec
(33) |
| 2016 |
Jan
(1) |
Feb
(24) |
Mar
(19) |
Apr
(1) |
May
|
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
(20) |
Oct
(5) |
Nov
(14) |
Dec
(4) |
| 2017 |
Jan
(15) |
Feb
(35) |
Mar
(10) |
Apr
(9) |
May
(14) |
Jun
(33) |
Jul
(1) |
Aug
(27) |
Sep
(7) |
Oct
|
Nov
(10) |
Dec
(15) |
| 2018 |
Jan
(29) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(11) |
Jun
|
Jul
(1) |
Aug
(8) |
Sep
(11) |
Oct
(22) |
Nov
(9) |
Dec
(13) |
| 2019 |
Jan
(1) |
Feb
(7) |
Mar
(3) |
Apr
(21) |
May
(34) |
Jun
(36) |
Jul
(18) |
Aug
(17) |
Sep
(19) |
Oct
(8) |
Nov
(3) |
Dec
|
| 2020 |
Jan
|
Feb
(4) |
Mar
(8) |
Apr
(29) |
May
(50) |
Jun
(8) |
Jul
(2) |
Aug
(10) |
Sep
(1) |
Oct
(7) |
Nov
(9) |
Dec
(19) |
| 2021 |
Jan
(2) |
Feb
(9) |
Mar
(6) |
Apr
(21) |
May
(13) |
Jun
(11) |
Jul
(2) |
Aug
(1) |
Sep
(3) |
Oct
(26) |
Nov
(2) |
Dec
(16) |
| 2022 |
Jan
(8) |
Feb
(7) |
Mar
(1) |
Apr
(13) |
May
(1) |
Jun
(4) |
Jul
(4) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2023 |
Jan
(2) |
Feb
(3) |
Mar
(16) |
Apr
|
May
(2) |
Jun
(1) |
Jul
(4) |
Aug
(13) |
Sep
(8) |
Oct
(6) |
Nov
(4) |
Dec
|
| 2024 |
Jan
(3) |
Feb
(3) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(5) |
Aug
|
Sep
(1) |
Oct
|
Nov
(5) |
Dec
|
| 2025 |
Jan
(4) |
Feb
(2) |
Mar
|
Apr
(11) |
May
(1) |
Jun
(9) |
Jul
(18) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Lonnie A. <li...@lo...> - 2017-09-12 18:55:00
|
Moved to the astlinux-devel list ... I thought of a more elegant solution, how about if in the /usr/sbin/openvpn-tls-verify script we source /mnt/kd/rc.conf.d/gui.openvpn.conf instead of /etc/rc.conf ? Possibly we could make sure /mnt/kd/rc.conf.d/gui.openvpn.conf is newer than /etc/rc.conf as a sanity check. While this would not be perfect, it would use the updated OVPN_VALIDCLIENTS when a new client was added without having to restart OpenVPN. Additionally. if one or more clients are already "Disabled" this would also allow additional clients to be Disabled also without restarting OpenVPN. The only edge condition I can think of is when OpenVPN was last started with "Disabled" clients and later all "Disabled" clients were unchecked (Enabled) and saved, in that case a OpenVPN Server restart would be needed, and no new clients could connect until the restart. A low percentage edge condition compared to the typical operation. Needs some testing ... Lonnie On Sep 11, 2017, at 4:46 PM, Michael Knill <mic...@ip...> wrote: > Hi Lonnie > > Could we reconfigure the script so that when you press the 'New Client' button it automatically does this? > > Regards > Michael Knill > > -----Original Message----- > From: Lonnie Abelbeck <li...@lo...> > Reply-To: AstLinux List <ast...@li...> > Date: Tuesday, 12 September 2017 at 7:01 am > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] OpenVPN on Yealink phones not very reliable > > Michael, > > Not having any "disabled" Client CN's would be a solution. > > Power User tip -> if (only) a new Client is added with previously "disabled" Client CN's and continued "disabled" Client CN's, the CLI command "gen-rc-conf" will apply the new OVPN_VALIDCLIENTS without restarting OpenVPN. > > Lonnie > > > On Sep 11, 2017, at 3:43 PM, Michael Knill <mic...@ip...> wrote: > >> Ah well that explains it then thanks Lonnie. >> >> Im glad I found this out early as I have been looking at building a hosted Astlinux server with connectivity via OpenVPN from Yealink phones and this requirement would certainly make this difficult. >> So are there any other options here? It seems crazy having to drop all your existing OVPN connections just to configure a new one. >> >> Regards >> Michael Knill >> >> -----Original Message----- >> From: Lonnie Abelbeck <li...@lo...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Monday, 11 September 2017 at 11:16 pm >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] OpenVPN on Yealink phones not very reliable >> >> Michael, >> >> If you have OpenVPN Server -> Client Certificates and Keys: -> Client Name with one or more "disabled" checked, you will have to Restart OpenVPN Server whenever you add a new Client. >> >> This is not a OpenVPN requirement per se. but rather the configuration for openvpn. >> >> To explain more ... if there are no "disabled" clients then the rc.conf variable OVPN_VALIDCLIENTS is not defined, the openvpn configuration does not include a tls-verify option. >> >> On the other had, if there are "disabled" clients then the rc.conf variable OVPN_VALIDCLIENTS is defined, the configuration includes a "tls-verify /usr/sbin/openvpn-tls-verify" option. As such only client CN's in OVPN_VALIDCLIENTS are allowed. If you add a new Client you need to Restart OpenVPN Server to update the config, that goes for most any change in OpenVPN Server. >> >> Lonnie >> >> >> >> On Sep 10, 2017, at 11:59 PM, Michael Knill <mic...@ip...> wrote: >> >>> Thanks Lonnie. I suspect that this is not the problem but I cant understand why I need to restart the server before it works. >>> >>> Regards >>> Michael Knill >>> >>> -----Original Message----- >>> From: Lonnie Abelbeck <li...@lo...> >>> Reply-To: AstLinux List <ast...@li...> >>> Date: Monday, 11 September 2017 at 1:24 pm >>> To: AstLinux List <ast...@li...> >>> Subject: Re: [Astlinux-users] OpenVPN on Yealink phones not very reliable >>> >>> Michael, >>> >>> You could try >>> -- OpenVPN Server -- >>> Raw Commands: duplicate-cn >>> -- >>> and see if that helps. But you need to understand if you really need "multiple clients using the same certificate or username to concurrently connect". >>> >>> Is there a OpenVPN client you forgot about ? Are any sharing a username ? >>> >>> I can generate the "duplicate-cn" log myself by connecting, disconnect and re-connecting using the same client. But it all works, no issues. >>> >>> Lonnie >>> >>> >>> On Sep 10, 2017, at 9:22 PM, Michael Knill <mic...@ip...> wrote: >>> >>>> Ah I did remember seeing something in the logs about this: >>>> Mon Sep 11 11:26:06 2017 us=913475 MULTI: new connection by client '001565F4634C' will cause previous active sessions by this client to be dropped. Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect. >>>> >>>> Is this a complaint? Should I just enable it anyway? >>>> I assume I add it to the RAW Commands? >>>> >>>> Regards >>>> Michael Knill >>>> >>>> -----Original Message----- >>>> From: Lonnie Abelbeck <li...@lo...> >>>> Reply-To: AstLinux List <ast...@li...> >>>> Date: Monday, 11 September 2017 at 11:52 am >>>> To: AstLinux List <ast...@li...> >>>> Subject: Re: [Astlinux-users] OpenVPN on Yealink phones not very reliable >>>> >>>> Michael, >>>> >>>> Judging from your error log the Yealink's client CN (Common Name) did not match any of the allowed (non-checked) Clients in the server. As long as you are certain the Yealink client cert is good. >>>> >>>> You are not "sharing" a client certificate are you ? If you are do you have the "duplicate-cn" raw command added ? From the OpenVPN docs ... >>>> >>>> --duplicate-cn >>>> Allow multiple clients with the same common name to concurrently connect. In the absence of this option, OpenVPN will disconnect a client instance upon connection of a new client having the same common name. >>>> >>>> Sounds a little like what you are describing. >>>> >>>> else ... >>>> >>>> Is your Yealink running the latest (or recent) firmware ? >>>> >>>> AstLinux is using the latest OpenVPN series 2.4.x. >>>> >>>> You can increase the Log Verbosity: to High on the server and see if that helps to find a clue. >>>> >>>> Lonnie >>>> >>>> >>>> On Sep 10, 2017, at 8:08 PM, Michael Knill <mic...@ip...> wrote: >>>> >>>>> Hi Lonnie >>>>> >>>>> Do you mean Client Name? Yes I do have one disabled if so but it is not the one I was having problems with. >>>>> >>>>> After testing I can now confirm that this issue occurs when I configure up a new phone and it goes away (and VPN establishes) when I restart the OpenVPN server. >>>>> Can you think why this could be happening? >>>>> >>>>> Regards >>>>> Michael Knill >>>>> >>>>> -----Original Message----- >>>>> From: Lonnie Abelbeck <li...@lo...> >>>>> Reply-To: AstLinux List <ast...@li...> >>>>> Date: Monday, 11 September 2017 at 9:55 am >>>>> To: AstLinux List <ast...@li...> >>>>> Subject: Re: [Astlinux-users] OpenVPN on Yealink phones not very reliable >>>>> >>>>> Michael, >>>>> >>>>> On your OpenVPN Server configuration (at the bottom), you must have at least one CommonName disabled. >>>>> >>>>> Client Certificates and Keys: -> Disabled checked (correct ?) >>>>> >>>>> This will define the variable OVPN_VALIDCLIENTS and is checked with the /usr/sbin/openvpn-tls-verify script >>>>> >>>>> Is your Yealink using one of the "Disabled" CommonNames ? >>>>> >>>>> Lonnie >>>>> >>>>> >>>>> On Sep 10, 2017, at 6:34 PM, Michael Knill <mic...@ip...> wrote: >>>>> >>>>>> I am having some issues with setting up OpenVPN on my Yealink phones. It used to be easy to set up but now it's a bit flakey. >>>>>> Once its up it seems to be fine but getting it to that stage is an issue. >>>>>> >>>>>> I noticed that I am getting these in the logs: >>>>>> Mon Sep 11 08:05:39 2017 us=888912 115.187.181.61:36531 WARNING: Failed running command (--tls-verify script): external program exited with error status: 1 >>>>>> >>>>>> Im not sure what they mean? What could the problem be? >>>>>> >>>>>> Regards >>>>>> Michael Knill >>>>>> ------------------------------------------------------------------------------ >>>>>> Check out the vibrant tech community on one of the world's most >>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ >>>>>> Astlinux-users mailing list >>>>>> Ast...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users >>>>>> >>>>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Check out the vibrant tech community on one of the world's most >>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>>> _______________________________________________ >>>>> Astlinux-users mailing list >>>>> Ast...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users >>>>> >>>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Check out the vibrant tech community on one of the world's most >>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>>> _______________________________________________ >>>>> Astlinux-users mailing list >>>>> Ast...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users >>>>> >>>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >>>>> >>>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>> _______________________________________________ >>>> Astlinux-users mailing list >>>> Ast...@li... >>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users >>>> >>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>> _______________________________________________ >>>> Astlinux-users mailing list >>>> Ast...@li... >>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users >>>> >>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >>>> >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> Astlinux-users mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-users >>> >>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >>> >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> Astlinux-users mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-users >>> >>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >>> >>> >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >> >> > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > |
|
From: Lonnie A. <li...@lo...> - 2017-09-04 18:33:42
|
Devs, Since we have switched to GitHub, I still prefer to use SVN, after accepting some PR's from David Kerr yesterday I got an error today when trying make a "svn ci ..." -- svn: E160024: resource out of date; try updating -- The solution was to "switch" to the current checkout ... -- svn sw https://github.com/astlinux-project/astlinux.git/trunk -- Simply documenting the solution for future reference. Much thanks to this post for the tip: SVN insisting everything out of date after a github pull request? http://preimesberger.blogspot.com/2015/05/svn-insisting-everything-out-of-date.html Lonnie |
|
From: Lonnie A. <li...@lo...> - 2017-09-02 01:04:29
|
Announcing Pre-Release Version: astlinux-1.3-3383-91e0ce Devs, Digium released security fixes for Asterisk ... Asterisk 11.25.2, 13.17.1, 14.6.1, 11.6-cert17, 13.13-cert5 Now Available (Security Release) http://www.asterisk.org/downloads/asterisk-news/asterisk-11252-13171-1461-116-cert17-1313-cert5-now-available-security The AstLinux team expects to release AstLinux 1.3.1 this month containing the above security fixes, earlier than the normal schedule. Given one fix was centered around RTP and NAT, these pre-release images will allow you to test to make sure Digium's fix does not cause any unexpected issues. The "AstLinux Pre-Release ChangeLog" and "Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ... AstLinux Project -> Development http://www.astlinux-project.org/dev.html While these images are considered 'stable', the lack of testing will not make these images suitable for critical production systems. If you should come across an issue, please report back here. AstLinux Team |
|
From: Lonnie A. <li...@lo...> - 2017-08-30 19:03:42
|
Devs, I enabled the e2fsck progress bar ... https://github.com/astlinux-project/astlinux/commit/75d25893e712792192414931481631d1d8dc3c7c For those of you building custom images, be sure to remove "initrd.img" so the initrd gets rebuilt. I tested this on a net5501, Qotom Q190G4N-S07 (video console), Jetway NF9HG-2930, PC Engines APU2 and Lanner LEC-7220-N4 . I pulled the power and saw e2fsck fix with the progress bar. Additionally, as a side benefit, now whether the filesystem was just "cleaned" or also "modified" is shown. Thanks for all the comments and feedback. Lonnie |
|
From: Michael K. <li...@mk...> - 2017-08-30 08:44:58
|
> Am 30.08.2017 um 05:58 schrieb Lonnie Abelbeck <li...@lo... <mailto:li...@lo...>>: > > David, > > Yes you can test .. if you "pull the power" on your box (or power off a VM without a proper shutdown) then use the RUNNIX "shell" to perform: > -- > e2fsck -y -C 0 /dev/sda2 > -- > and if you have a separate /mnt/kd partition > -- > e2fsck -y -C 0 /dev/sda3 > -- > > Using a VM is so fast the progress bar only flashes up for a second. > > I also tested on an APU2, and it worked as expected. A little more output when the filesystem is not clean, but should not be confusing to users. > > Lonnie Works fine for me in a VirtualBox VM. It took about 2-3 seconds. > On Aug 29, 2017, at 9:31 PM, David Kerr <Da...@Ke... <mailto:Da...@Ke...>> wrote: > >> I think using something that is formally part of the application is the best approach. Is there anyway to test it? >> >> David >> >> On Tue, Aug 29, 2017 at 9:37 PM, Lonnie Abelbeck <li...@lo... <mailto:li...@lo...>> wrote: >> Well, it turns out e2fsck has a "progress" bar feature, simply add "-C 0" to the command line. >> >> I'm not sure how this will look when a serial console is attached mid-way through the progress, but there will be activity and it won't look like the box is hung. >> >> So if we replace the current >> -- >> e2fsck -y $ASTURW >/dev/null >> -- with -- >> e2fsck -y -C 0 $ASTURW >> -- >> we will get an extra line for the typical case, and several more lines and possibly a progress bar for the "dirty" case. >> >> Is this the best approach ? >> >> Lonnie >> >> >> On Aug 29, 2017, at 5:56 PM, The Cadillac Kid via Astlinux-devel <ast...@li... <mailto:ast...@li...>> wrote: >> >>> I thought fsck printed out as it goes? with the -v option? does the version in astlinux not? >>> -Christopher >>> >>> From: Lonnie Abelbeck <li...@lo... <mailto:li...@lo...>> >>> To: AstLinux Developers Mailing List <ast...@li... <mailto:ast...@li...>> >>> Sent: Tuesday, August 29, 2017 5:52 PM >>> Subject: Re: [Astlinux-devel] Adding a "spinner" indicator when e2fsck is working >>> >>> Hi Michael, >>> >>> First, this issue that Tim Turpin reported today does not occur very often, but as larger SSD's become less expensive and easier to find, the time it takes to do a fsck after a hard power failure or corruption will become longer and longer. >>> >>> Consider Tim's case, he notices his AstLinux box is not up, power is on ... so he checks the console ... unless there is some "activity" on the console it would appear the box is locked-up, but actually e2fsck is fixing his drive. >>> >>> I don't think some static text before the e2fsck would help too much, easily missed and the asynchronous kernel logs make things more confusing coming in after the e2fsck log. >>> >>> Lonnie >>> >>> >>> On Aug 29, 2017, at 5:18 PM, Michael Knill <mic...@ip... <mailto:mic...@ip...>> wrote: >>> >>>> Do you really need a spinner? >>>> Couldn't you just echo a comment that e2fsk is working and this could take a REAL long time so don't panic? >>>> You could then have another comment after e2fsk saying its done! >>>> >>>> Regards >>>> Michael Knill >>>> >>>> -----Original Message----- >>>> From: Lonnie Abelbeck <li...@lo... <mailto:li...@lo...>> >>>> Reply-To: AstLinux Developers Mailing List <ast...@li... <mailto:ast...@li...>> >>>> Date: Wednesday, 30 August 2017 at 7:58 am >>>> To: AstLinux Developers Mailing List <ast...@li... <mailto:ast...@li...>> >>>> Subject: Re: [Astlinux-devel] Adding a "spinner" indicator when e2fsck is working >>>> >>>> >>>> On Aug 29, 2017, at 1:42 PM, Michael Keuter <li...@mk... <mailto:li...@mk...>> wrote: >>>> >>>>>>> >>>>>>> Lonnie, don't give up so quickly :-). >>>>>>> What you have already is quite a good starting point. >>>>>>> What about adding "something needed" to our initrd busybox.config … >>>>>>> >>>>>>> Michael >>>>>> >>>>>> The initrd busybox config is not the problem, this is a fundamental problem using shell, though easily solved with bash, but bash is not a practical option with our initrd. >>>>>> >>>>>> Get exit status of process that's piped to another >>>>>> https://unix.stackexchange.com/questions/14270/get-exit-status-of-process-thats-piped-to-another <https://unix.stackexchange.com/questions/14270/get-exit-status-of-process-thats-piped-to-another> >>>>>> >>>>>> I dont see an elegant solution. >>>>>> >>>>>> My only other thought would be to create a background "spinner" process, then call "e2fsck -y $1 >/dev/null" and status="$?" then stop the background spinner process. >>>>> >>>>> Sounds not so bad, at least worth a test. >>>> >>>> Here is a working test of a "spinner" function: >>>> https://gist.github.com/abelbeck/40c1da054ae6740f03e09ef70452cf70 <https://gist.github.com/abelbeck/40c1da054ae6740f03e09ef70452cf70> >>>> >>>> In our case, instead of the test examples: >>>> -- >>>> date >>>> sleep 2 >>>> date >>>> sleep 10 >>>> -- >>>> we would have: >>>> -- >>>> e2fsck -y $ASTURW >/dev/null >>>> status=$? >>>> -- >>>> >>>> Seems to work, the question is whether it is worth adding. >>>> >>>> Lonnie Michael http://www.mksolutions.info |
|
From: Lonnie A. <li...@lo...> - 2017-08-30 03:59:07
|
David, Yes you can test .. if you "pull the power" on your box (or power off a VM without a proper shutdown) then use the RUNNIX "shell" to perform: -- e2fsck -y -C 0 /dev/sda2 -- and if you have a separate /mnt/kd partition -- e2fsck -y -C 0 /dev/sda3 -- Using a VM is so fast the progress bar only flashes up for a second. I also tested on an APU2, and it worked as expected. A little more output when the filesystem is not clean, but should not be confusing to users. Lonnie On Aug 29, 2017, at 9:31 PM, David Kerr <Da...@Ke...> wrote: > I think using something that is formally part of the application is the best approach. Is there anyway to test it? > > David > > On Tue, Aug 29, 2017 at 9:37 PM, Lonnie Abelbeck <li...@lo...> wrote: > Well, it turns out e2fsck has a "progress" bar feature, simply add "-C 0" to the command line. > > I'm not sure how this will look when a serial console is attached mid-way through the progress, but there will be activity and it won't look like the box is hung. > > So if we replace the current > -- > e2fsck -y $ASTURW >/dev/null > -- with -- > e2fsck -y -C 0 $ASTURW > -- > we will get an extra line for the typical case, and several more lines and possibly a progress bar for the "dirty" case. > > Is this the best approach ? > > Lonnie > > > On Aug 29, 2017, at 5:56 PM, The Cadillac Kid via Astlinux-devel <ast...@li...> wrote: > > > I thought fsck printed out as it goes? with the -v option? does the version in astlinux not? > > -Christopher > > > > From: Lonnie Abelbeck <li...@lo...> > > To: AstLinux Developers Mailing List <ast...@li...> > > Sent: Tuesday, August 29, 2017 5:52 PM > > Subject: Re: [Astlinux-devel] Adding a "spinner" indicator when e2fsck is working > > > > Hi Michael, > > > > First, this issue that Tim Turpin reported today does not occur very often, but as larger SSD's become less expensive and easier to find, the time it takes to do a fsck after a hard power failure or corruption will become longer and longer. > > > > Consider Tim's case, he notices his AstLinux box is not up, power is on ... so he checks the console ... unless there is some "activity" on the console it would appear the box is locked-up, but actually e2fsck is fixing his drive. > > > > I don't think some static text before the e2fsck would help too much, easily missed and the asynchronous kernel logs make things more confusing coming in after the e2fsck log. > > > > Lonnie > > > > > > On Aug 29, 2017, at 5:18 PM, Michael Knill <mic...@ip...> wrote: > > > > > Do you really need a spinner? > > > Couldn't you just echo a comment that e2fsk is working and this could take a REAL long time so don't panic? > > > You could then have another comment after e2fsk saying its done! > > > > > > Regards > > > Michael Knill > > > > > > -----Original Message----- > > > From: Lonnie Abelbeck <li...@lo...> > > > Reply-To: AstLinux Developers Mailing List <ast...@li...> > > > Date: Wednesday, 30 August 2017 at 7:58 am > > > To: AstLinux Developers Mailing List <ast...@li...> > > > Subject: Re: [Astlinux-devel] Adding a "spinner" indicator when e2fsck is working > > > > > > > > > On Aug 29, 2017, at 1:42 PM, Michael Keuter <li...@mk...> wrote: > > > > > >>>> > > >>>> Lonnie, don't give up so quickly :-). > > >>>> What you have already is quite a good starting point. > > >>>> What about adding "something needed" to our initrd busybox.config … > > >>>> > > >>>> Michael > > >>> > > >>> The initrd busybox config is not the problem, this is a fundamental problem using shell, though easily solved with bash, but bash is not a practical option with our initrd. > > >>> > > >>> Get exit status of process that's piped to another > > >>> https://unix.stackexchange.com/questions/14270/get-exit-status-of-process-thats-piped-to-another > > >>> > > >>> I dont see an elegant solution. > > >>> > > >>> My only other thought would be to create a background "spinner" process, then call "e2fsck -y $1 >/dev/null" and status="$?" then stop the background spinner process. > > >> > > >> Sounds not so bad, at least worth a test. > > > > > > Here is a working test of a "spinner" function: > > > https://gist.github.com/abelbeck/40c1da054ae6740f03e09ef70452cf70 > > > > > > In our case, instead of the test examples: > > > -- > > > date > > > sleep 2 > > > date > > > sleep 10 > > > -- > > > we would have: > > > -- > > > e2fsck -y $ASTURW >/dev/null > > > status=$? > > > -- > > > > > > Seems to work, the question is whether it is worth adding. > > > > > > Lonnie > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: David K. <da...@ke...> - 2017-08-30 02:31:41
|
I think using something that is formally part of the application is the best approach. Is there anyway to test it? David On Tue, Aug 29, 2017 at 9:37 PM, Lonnie Abelbeck <li...@lo...> wrote: > Well, it turns out e2fsck has a "progress" bar feature, simply add "-C 0" > to the command line. > > I'm not sure how this will look when a serial console is attached mid-way > through the progress, but there will be activity and it won't look like the > box is hung. > > So if we replace the current > -- > e2fsck -y $ASTURW >/dev/null > -- with -- > e2fsck -y -C 0 $ASTURW > -- > we will get an extra line for the typical case, and several more lines and > possibly a progress bar for the "dirty" case. > > Is this the best approach ? > > Lonnie > > > On Aug 29, 2017, at 5:56 PM, The Cadillac Kid via Astlinux-devel < > ast...@li...> wrote: > > > I thought fsck printed out as it goes? with the -v option? does the > version in astlinux not? > > -Christopher > > > > From: Lonnie Abelbeck <li...@lo...> > > To: AstLinux Developers Mailing List <astlinux-devel@lists. > sourceforge.net> > > Sent: Tuesday, August 29, 2017 5:52 PM > > Subject: Re: [Astlinux-devel] Adding a "spinner" indicator when e2fsck > is working > > > > Hi Michael, > > > > First, this issue that Tim Turpin reported today does not occur very > often, but as larger SSD's become less expensive and easier to find, the > time it takes to do a fsck after a hard power failure or corruption will > become longer and longer. > > > > Consider Tim's case, he notices his AstLinux box is not up, power is on > ... so he checks the console ... unless there is some "activity" on the > console it would appear the box is locked-up, but actually e2fsck is fixing > his drive. > > > > I don't think some static text before the e2fsck would help too much, > easily missed and the asynchronous kernel logs make things more confusing > coming in after the e2fsck log. > > > > Lonnie > > > > > > On Aug 29, 2017, at 5:18 PM, Michael Knill <michael.knill@ipcsolutions. > com.au> wrote: > > > > > Do you really need a spinner? > > > Couldn't you just echo a comment that e2fsk is working and this could > take a REAL long time so don't panic? > > > You could then have another comment after e2fsk saying its done! > > > > > > Regards > > > Michael Knill > > > > > > -----Original Message----- > > > From: Lonnie Abelbeck <li...@lo...> > > > Reply-To: AstLinux Developers Mailing List <astlinux-devel@lists. > sourceforge.net> > > > Date: Wednesday, 30 August 2017 at 7:58 am > > > To: AstLinux Developers Mailing List <astlinux-devel@lists. > sourceforge.net> > > > Subject: Re: [Astlinux-devel] Adding a "spinner" indicator when e2fsck > is working > > > > > > > > > On Aug 29, 2017, at 1:42 PM, Michael Keuter <li...@mk...> > wrote: > > > > > >>>> > > >>>> Lonnie, don't give up so quickly :-). > > >>>> What you have already is quite a good starting point. > > >>>> What about adding "something needed" to our initrd busybox.config … > > >>>> > > >>>> Michael > > >>> > > >>> The initrd busybox config is not the problem, this is a fundamental > problem using shell, though easily solved with bash, but bash is not a > practical option with our initrd. > > >>> > > >>> Get exit status of process that's piped to another > > >>> https://unix.stackexchange.com/questions/14270/get-exit- > status-of-process-thats-piped-to-another > > >>> > > >>> I dont see an elegant solution. > > >>> > > >>> My only other thought would be to create a background "spinner" > process, then call "e2fsck -y $1 >/dev/null" and status="$?" then stop the > background spinner process. > > >> > > >> Sounds not so bad, at least worth a test. > > > > > > Here is a working test of a "spinner" function: > > > https://gist.github.com/abelbeck/40c1da054ae6740f03e09ef70452cf70 > > > > > > In our case, instead of the test examples: > > > -- > > > date > > > sleep 2 > > > date > > > sleep 10 > > > -- > > > we would have: > > > -- > > > e2fsck -y $ASTURW >/dev/null > > > status=$? > > > -- > > > > > > Seems to work, the question is whether it is worth adding. > > > > > > Lonnie > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > |
|
From: Lonnie A. <li...@lo...> - 2017-08-30 01:37:23
|
Well, it turns out e2fsck has a "progress" bar feature, simply add "-C 0" to the command line. I'm not sure how this will look when a serial console is attached mid-way through the progress, but there will be activity and it won't look like the box is hung. So if we replace the current -- e2fsck -y $ASTURW >/dev/null -- with -- e2fsck -y -C 0 $ASTURW -- we will get an extra line for the typical case, and several more lines and possibly a progress bar for the "dirty" case. Is this the best approach ? Lonnie On Aug 29, 2017, at 5:56 PM, The Cadillac Kid via Astlinux-devel <ast...@li...> wrote: > I thought fsck printed out as it goes? with the -v option? does the version in astlinux not? > -Christopher > > From: Lonnie Abelbeck <li...@lo...> > To: AstLinux Developers Mailing List <ast...@li...> > Sent: Tuesday, August 29, 2017 5:52 PM > Subject: Re: [Astlinux-devel] Adding a "spinner" indicator when e2fsck is working > > Hi Michael, > > First, this issue that Tim Turpin reported today does not occur very often, but as larger SSD's become less expensive and easier to find, the time it takes to do a fsck after a hard power failure or corruption will become longer and longer. > > Consider Tim's case, he notices his AstLinux box is not up, power is on ... so he checks the console ... unless there is some "activity" on the console it would appear the box is locked-up, but actually e2fsck is fixing his drive. > > I don't think some static text before the e2fsck would help too much, easily missed and the asynchronous kernel logs make things more confusing coming in after the e2fsck log. > > Lonnie > > > On Aug 29, 2017, at 5:18 PM, Michael Knill <mic...@ip...> wrote: > > > Do you really need a spinner? > > Couldn't you just echo a comment that e2fsk is working and this could take a REAL long time so don't panic? > > You could then have another comment after e2fsk saying its done! > > > > Regards > > Michael Knill > > > > -----Original Message----- > > From: Lonnie Abelbeck <li...@lo...> > > Reply-To: AstLinux Developers Mailing List <ast...@li...> > > Date: Wednesday, 30 August 2017 at 7:58 am > > To: AstLinux Developers Mailing List <ast...@li...> > > Subject: Re: [Astlinux-devel] Adding a "spinner" indicator when e2fsck is working > > > > > > On Aug 29, 2017, at 1:42 PM, Michael Keuter <li...@mk...> wrote: > > > >>>> > >>>> Lonnie, don't give up so quickly :-). > >>>> What you have already is quite a good starting point. > >>>> What about adding "something needed" to our initrd busybox.config … > >>>> > >>>> Michael > >>> > >>> The initrd busybox config is not the problem, this is a fundamental problem using shell, though easily solved with bash, but bash is not a practical option with our initrd. > >>> > >>> Get exit status of process that's piped to another > >>> https://unix.stackexchange.com/questions/14270/get-exit-status-of-process-thats-piped-to-another > >>> > >>> I dont see an elegant solution. > >>> > >>> My only other thought would be to create a background "spinner" process, then call "e2fsck -y $1 >/dev/null" and status="$?" then stop the background spinner process. > >> > >> Sounds not so bad, at least worth a test. > > > > Here is a working test of a "spinner" function: > > https://gist.github.com/abelbeck/40c1da054ae6740f03e09ef70452cf70 > > > > In our case, instead of the test examples: > > -- > > date > > sleep 2 > > date > > sleep 10 > > -- > > we would have: > > -- > > e2fsck -y $ASTURW >/dev/null > > status=$? > > -- > > > > Seems to work, the question is whether it is worth adding. > > > > Lonnie |
|
From: Lonnie A. <li...@lo...> - 2017-08-29 23:20:12
|
Christopher, AstLinux uses the latest e2fsprogs, we have all the options. I don't have an example in front of me, but if it takes 15+ minutes for a "e2fsck -y /dev/sda2" then there must be a *lot* of fixes spewing on the screen, even without the -v option. I'm not sure if opening up all of e2fsck's stdout is the best approach. Lonnie On Aug 29, 2017, at 5:56 PM, The Cadillac Kid via Astlinux-devel <ast...@li...> wrote: > I thought fsck printed out as it goes? with the -v option? does the version in astlinux not? > -Christopher > > From: Lonnie Abelbeck <li...@lo...> > To: AstLinux Developers Mailing List <ast...@li...> > Sent: Tuesday, August 29, 2017 5:52 PM > Subject: Re: [Astlinux-devel] Adding a "spinner" indicator when e2fsck is working > > Hi Michael, > > First, this issue that Tim Turpin reported today does not occur very often, but as larger SSD's become less expensive and easier to find, the time it takes to do a fsck after a hard power failure or corruption will become longer and longer. > > Consider Tim's case, he notices his AstLinux box is not up, power is on ... so he checks the console ... unless there is some "activity" on the console it would appear the box is locked-up, but actually e2fsck is fixing his drive. > > I don't think some static text before the e2fsck would help too much, easily missed and the asynchronous kernel logs make things more confusing coming in after the e2fsck log. > > Lonnie > > > On Aug 29, 2017, at 5:18 PM, Michael Knill <mic...@ip...> wrote: > > > Do you really need a spinner? > > Couldn't you just echo a comment that e2fsk is working and this could take a REAL long time so don't panic? > > You could then have another comment after e2fsk saying its done! > > > > Regards > > Michael Knill > > > > -----Original Message----- > > From: Lonnie Abelbeck <li...@lo...> > > Reply-To: AstLinux Developers Mailing List <ast...@li...> > > Date: Wednesday, 30 August 2017 at 7:58 am > > To: AstLinux Developers Mailing List <ast...@li...> > > Subject: Re: [Astlinux-devel] Adding a "spinner" indicator when e2fsck is working > > > > > > On Aug 29, 2017, at 1:42 PM, Michael Keuter <li...@mk...> wrote: > > > >>>> > >>>> Lonnie, don't give up so quickly :-). > >>>> What you have already is quite a good starting point. > >>>> What about adding "something needed" to our initrd busybox.config … > >>>> > >>>> Michael > >>> > >>> The initrd busybox config is not the problem, this is a fundamental problem using shell, though easily solved with bash, but bash is not a practical option with our initrd. > >>> > >>> Get exit status of process that's piped to another > >>> https://unix.stackexchange.com/questions/14270/get-exit-status-of-process-thats-piped-to-another > >>> > >>> I dont see an elegant solution. > >>> > >>> My only other thought would be to create a background "spinner" process, then call "e2fsck -y $1 >/dev/null" and status="$?" then stop the background spinner process. > >> > >> Sounds not so bad, at least worth a test. > > > > Here is a working test of a "spinner" function: > > https://gist.github.com/abelbeck/40c1da054ae6740f03e09ef70452cf70 > > > > In our case, instead of the test examples: > > -- > > date > > sleep 2 > > date > > sleep 10 > > -- > > we would have: > > -- > > e2fsck -y $ASTURW >/dev/null > > status=$? > > -- > > > > Seems to work, the question is whether it is worth adding. > > > > Lonnie > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: The C. K. <eld...@ya...> - 2017-08-29 22:56:23
|
I thought fsck printed out as it goes? with the -v option? does the version in astlinux not?-Christopher
From: Lonnie Abelbeck <li...@lo...>
To: AstLinux Developers Mailing List <ast...@li...>
Sent: Tuesday, August 29, 2017 5:52 PM
Subject: Re: [Astlinux-devel] Adding a "spinner" indicator when e2fsck is working
Hi Michael,
First, this issue that Tim Turpin reported today does not occur very often, but as larger SSD's become less expensive and easier to find, the time it takes to do a fsck after a hard power failure or corruption will become longer and longer.
Consider Tim's case, he notices his AstLinux box is not up, power is on ... so he checks the console ... unless there is some "activity" on the console it would appear the box is locked-up, but actually e2fsck is fixing his drive.
I don't think some static text before the e2fsck would help too much, easily missed and the asynchronous kernel logs make things more confusing coming in after the e2fsck log.
Lonnie
On Aug 29, 2017, at 5:18 PM, Michael Knill <mic...@ip...> wrote:
> Do you really need a spinner?
> Couldn't you just echo a comment that e2fsk is working and this could take a REAL long time so don't panic?
> You could then have another comment after e2fsk saying its done!
>
> Regards
> Michael Knill
>
> -----Original Message-----
> From: Lonnie Abelbeck <li...@lo...>
> Reply-To: AstLinux Developers Mailing List <ast...@li...>
> Date: Wednesday, 30 August 2017 at 7:58 am
> To: AstLinux Developers Mailing List <ast...@li...>
> Subject: Re: [Astlinux-devel] Adding a "spinner" indicator when e2fsck is working
>
>
> On Aug 29, 2017, at 1:42 PM, Michael Keuter <li...@mk...> wrote:
>
>>>>
>>>> Lonnie, don't give up so quickly :-).
>>>> What you have already is quite a good starting point.
>>>> What about adding "something needed" to our initrd busybox.config …
>>>>
>>>> Michael
>>>
>>> The initrd busybox config is not the problem, this is a fundamental problem using shell, though easily solved with bash, but bash is not a practical option with our initrd.
>>>
>>> Get exit status of process that's piped to another
>>> https://unix.stackexchange.com/questions/14270/get-exit-status-of-process-thats-piped-to-another
>>>
>>> I dont see an elegant solution.
>>>
>>> My only other thought would be to create a background "spinner" process, then call "e2fsck -y $1 >/dev/null" and status="$?" then stop the background spinner process.
>>
>> Sounds not so bad, at least worth a test.
>
> Here is a working test of a "spinner" function:
> https://gist.github.com/abelbeck/40c1da054ae6740f03e09ef70452cf70
>
> In our case, instead of the test examples:
> --
> date
> sleep 2
> date
> sleep 10
> --
> we would have:
> --
> e2fsck -y $ASTURW >/dev/null
> status=$?
> --
>
> Seems to work, the question is whether it is worth adding.
>
> Lonnie
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Lonnie A. <li...@lo...> - 2017-08-29 22:52:35
|
Hi Michael, First, this issue that Tim Turpin reported today does not occur very often, but as larger SSD's become less expensive and easier to find, the time it takes to do a fsck after a hard power failure or corruption will become longer and longer. Consider Tim's case, he notices his AstLinux box is not up, power is on ... so he checks the console ... unless there is some "activity" on the console it would appear the box is locked-up, but actually e2fsck is fixing his drive. I don't think some static text before the e2fsck would help too much, easily missed and the asynchronous kernel logs make things more confusing coming in after the e2fsck log. Lonnie On Aug 29, 2017, at 5:18 PM, Michael Knill <mic...@ip...> wrote: > Do you really need a spinner? > Couldn't you just echo a comment that e2fsk is working and this could take a REAL long time so don't panic? > You could then have another comment after e2fsk saying its done! > > Regards > Michael Knill > > -----Original Message----- > From: Lonnie Abelbeck <li...@lo...> > Reply-To: AstLinux Developers Mailing List <ast...@li...> > Date: Wednesday, 30 August 2017 at 7:58 am > To: AstLinux Developers Mailing List <ast...@li...> > Subject: Re: [Astlinux-devel] Adding a "spinner" indicator when e2fsck is working > > > On Aug 29, 2017, at 1:42 PM, Michael Keuter <li...@mk...> wrote: > >>>> >>>> Lonnie, don't give up so quickly :-). >>>> What you have already is quite a good starting point. >>>> What about adding "something needed" to our initrd busybox.config … >>>> >>>> Michael >>> >>> The initrd busybox config is not the problem, this is a fundamental problem using shell, though easily solved with bash, but bash is not a practical option with our initrd. >>> >>> Get exit status of process that's piped to another >>> https://unix.stackexchange.com/questions/14270/get-exit-status-of-process-thats-piped-to-another >>> >>> I dont see an elegant solution. >>> >>> My only other thought would be to create a background "spinner" process, then call "e2fsck -y $1 >/dev/null" and status="$?" then stop the background spinner process. >> >> Sounds not so bad, at least worth a test. > > Here is a working test of a "spinner" function: > https://gist.github.com/abelbeck/40c1da054ae6740f03e09ef70452cf70 > > In our case, instead of the test examples: > -- > date > sleep 2 > date > sleep 10 > -- > we would have: > -- > e2fsck -y $ASTURW >/dev/null > status=$? > -- > > Seems to work, the question is whether it is worth adding. > > Lonnie |
|
From: Michael K. <mic...@ip...> - 2017-08-29 22:34:09
|
Do you really need a spinner? Couldn't you just echo a comment that e2fsk is working and this could take a REAL long time so don't panic? You could then have another comment after e2fsk saying its done! Regards Michael Knill -----Original Message----- From: Lonnie Abelbeck <li...@lo...> Reply-To: AstLinux Developers Mailing List <ast...@li...> Date: Wednesday, 30 August 2017 at 7:58 am To: AstLinux Developers Mailing List <ast...@li...> Subject: Re: [Astlinux-devel] Adding a "spinner" indicator when e2fsck is working On Aug 29, 2017, at 1:42 PM, Michael Keuter <li...@mk...> wrote: >>> >>> Lonnie, don't give up so quickly :-). >>> What you have already is quite a good starting point. >>> What about adding "something needed" to our initrd busybox.config … >>> >>> Michael >> >> The initrd busybox config is not the problem, this is a fundamental problem using shell, though easily solved with bash, but bash is not a practical option with our initrd. >> >> Get exit status of process that's piped to another >> https://unix.stackexchange.com/questions/14270/get-exit-status-of-process-thats-piped-to-another >> >> I dont see an elegant solution. >> >> My only other thought would be to create a background "spinner" process, then call "e2fsck -y $1 >/dev/null" and status="$?" then stop the background spinner process. > > Sounds not so bad, at least worth a test. Here is a working test of a "spinner" function: https://gist.github.com/abelbeck/40c1da054ae6740f03e09ef70452cf70 In our case, instead of the test examples: -- date sleep 2 date sleep 10 -- we would have: -- e2fsck -y $ASTURW >/dev/null status=$? -- Seems to work, the question is whether it is worth adding. Lonnie ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Astlinux-devel mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Lonnie A. <li...@lo...> - 2017-08-29 21:58:21
|
On Aug 29, 2017, at 1:42 PM, Michael Keuter <li...@mk...> wrote: >>> >>> Lonnie, don't give up so quickly :-). >>> What you have already is quite a good starting point. >>> What about adding "something needed" to our initrd busybox.config … >>> >>> Michael >> >> The initrd busybox config is not the problem, this is a fundamental problem using shell, though easily solved with bash, but bash is not a practical option with our initrd. >> >> Get exit status of process that's piped to another >> https://unix.stackexchange.com/questions/14270/get-exit-status-of-process-thats-piped-to-another >> >> I dont see an elegant solution. >> >> My only other thought would be to create a background "spinner" process, then call "e2fsck -y $1 >/dev/null" and status="$?" then stop the background spinner process. > > Sounds not so bad, at least worth a test. Here is a working test of a "spinner" function: https://gist.github.com/abelbeck/40c1da054ae6740f03e09ef70452cf70 In our case, instead of the test examples: -- date sleep 2 date sleep 10 -- we would have: -- e2fsck -y $ASTURW >/dev/null status=$? -- Seems to work, the question is whether it is worth adding. Lonnie |
|
From: Lonnie A. <li...@lo...> - 2017-08-29 20:04:52
|
On Aug 29, 2017, at 1:42 PM, Michael Keuter <li...@mk...> wrote: > >> >> The initrd busybox config is not the problem, this is a fundamental problem using shell, though easily solved with bash, but bash is not a practical option with our initrd. >> >> Get exit status of process that's piped to another >> https://unix.stackexchange.com/questions/14270/get-exit-status-of-process-thats-piped-to-another >> >> I dont see an elegant solution. >> >> My only other thought would be to create a background "spinner" process, then call "e2fsck -y $1 >/dev/null" and status="$?" then stop the background spinner process. > > Sounds not so bad, at least worth a test. > BTW: Wasn't there a kind of mini-shell in busybox ("ash" or so)? Yes we are using the Busybox "ash" shell in the initrd. Lonnie |
|
From: Lonnie A. <li...@lo...> - 2017-08-29 20:03:16
|
Hi Christopher,
I guess that is an option as well, but as Tim reported 15 minutes+ of e2fsck spewing messages is not very useful either.
I seem to recall the mainline distros use some sort of spinner wrapper and hide the fsck messages while repairing.
Lonnie
On Aug 29, 2017, at 2:23 PM, The Cadillac Kid via Astlinux-devel <ast...@li...> wrote:
> why not just let the fsck details be printed to the primary console?
>
>
>
> From: Lonnie Abelbeck <li...@lo...>
> To: AstLinux Developers Mailing List <ast...@li...>
> Sent: Tuesday, August 29, 2017 2:12 PM
> Subject: [Astlinux-devel] Adding a "spinner" indicator when e2fsck is working
>
> Hi Devs,
>
> David made a good point, so I looked into piping the output of e2fsck to a "spinner" shell function, triggered by a newline and update no more often then ever second ...
> --
> spinner()
> {
> local i sp secs nsecs line IFS
>
> i=0
> secs=0
>
> unset IFS
> while read line; do
> nsecs=$(cut -d. -f1 /proc/uptime)
> if [ $nsecs -ne $secs ]; then
> secs=$nsecs
> i=$(((i+1)%4))
> case $i in
> 1) sp='-' ;;
> 2) sp='\' ;;
> 3) sp='|' ;;
> *) sp='/' ;;
> esac
> echo -ne " Working[${sp}] \r"
> fi
> done
>
> echo -ne " \r"
> }
> --
> It took some work getting this to work without printf, no date, no bash ${str:1:1}, etc., but it works with the current Busybox configs.
>
> But ... here are the two places "spinner" would apply to ...
>
> 1) in the initrd, linuxrc ...
> --
> e2fsck -y $ASTURW >/dev/null
> status=$?
>
> case $status in
> --
>
> 2) in astlinux, /etc/rc ...
> --
> echo "Checking $1"
> e2fsck -y $1 >/dev/null
>
> status="$?"
>
> case $status in
> --
>
> The plan would be to use:
> --
> e2fsck -y $1 | spinner
> --
> But the return value of $? is no longer from e2fsck, but rather spinner
>
> You might try ...
> --
> ( e2fsck -y $1 ; status="$?" ) | spinner
> --
> Almost, but now "status" is defined in a subshell which is not propagated up and lost.
>
> A simple but ugly solution is to use a temp file ...
> --
> ( e2fsck -y $1 ; echo "$?" > /tmp/e2fsck_status ) | spinner
> status="$(cat /tmp/e2fsck_status)"
> rm /tmp/e2fsck_status
> --
> but not to mention the initrd does not currently mount a /tmp filesystem. We would have to have to create and delete a tmpfs filesystem just to get the return value from e2fsck. :-(
>
> I'm leaning toward leaving things as is, comments ?
>
> Lonnie
>
>
> On Aug 29, 2017, at 8:20 AM, Lonnie Abelbeck <li...@lo...> wrote:
>
>> Hi David,
>>
>> Agreed, no e2fsck output when it is forced to work for a long period is not ideal. Thankfully this is a very rare occurrence.
>>
>> If we can come up with a clever spinning wheel or such counting the lines e2fsck generates might be a good addition.
>>
>> Recall this all occurs in the "initrd", so the available packages and BusyBox config is quite limited.
>>
>> Any further discussion on this idea should move to the astlinux-devel list.
>>
>> Lonnie
>>
>>
>> On Aug 29, 2017, at 7:48 AM, David Kerr <Da...@Ke...> wrote:
>>
>>> Is that a good idea (redirecting e2fsck to null)? 15 minutes is a long time to wait with no indication of anything happening.
>>>
>>> David
>>>
>>> On Tue, Aug 29, 2017 at 8:33 AM, Lonnie Abelbeck <li...@lo...> wrote:
>>> Hi Tim,
>>>
>>> Yes, it was running "e2fsck" with stdout redirected to /dev/null so you did not see it working ... eventually e2fsck will return with a result code if left long enough.
>>>
>>> Good to hear your filesystem is now clean, you might reboot once again to make sure the filesystem is good.
>>>
>>> BTW, if the automatic e2fsck repair did not work, here is the manual fallback procedure:
>>> --
>>> ## reboot, and quickly when the RUNNIX boot menu appears type "shell"
>>> boot: shell
>>>
>>> ## Wait for a "runnix# " CLI prompt.
>>> ## determine the first Linux ext2 partition, usually always /dev/sda2
>>> runnix# findfs LABEL=ASTURW
>>>
>>> ## using the findfs result, run e2fsck manually, you may want to add -y or -p options
>>> runnix# e2fsck /dev/sda2
>>>
>>> ## output a list of options for e2fsck
>>> runnix# e2fsck
>>> Usage: e2fsck [-panyrcdfktvDFV] [-b superblock] [-B blocksize]
>>> [-l|-L bad_blocks_file] [-C fd] [-j external_journal]
>>> [-E extended-options] [-z undo_file] device
>>>
>>> Emergency help:
>>> -p Automatic repair (no questions)
>>> -n Make no changes to the filesystem
>>> -y Assume "yes" to all questions
>>> -c Check for bad blocks and add them to the badblock list
>>> -f Force checking even if filesystem is marked clean
>>> -v Be verbose
>>> -b superblock Use alternative superblock
>>> -B blocksize Force blocksize when looking for superblock
>>> -j external_journal Set location of the external journal
>>> -l bad_blocks_file Add to badblocks list
>>> -L bad_blocks_file Set badblocks list
>>> -z undo_file Create an undo file
>>>
>>> ## Depending on how you initially configured AstLinux, check if you also have a ASTKD partition
>>> ## (typically /dev/sda3 if it exists)
>>> runnix# findfs LABEL=ASTKD
>>> ## If the ASTKD label exists repeat the e2fsck steps above using the ASTKD label partition.
>>>
>>> ## reboot by issuing "exit"
>>> runnix# exit
>>> --
>>>
>>> Lonnie
>>>
>>>
>>> On Aug 29, 2017, at 7:02 AM, Tim Turpin <tt...@z-...> wrote:
>>>
>>>> Never mind. After sitting at that point for about 15 minutes, it somehow recovered and finished booting up. All seems well now.
>>>>
>>>> From: Tim Turpin [mailto:tt...@z-...]
>>>> Sent: Tuesday, August 29, 2017 7:34 AM
>>>> To: ast...@li...
>>>> Subject: [Astlinux-users] ASTLinux stopped booting
>>>>
>>>> We took a power hit on our test system yesterday, and now it will only load up to a certain point and stops with the following screen:
>
> <image001.jpeg>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> <image001.jpeg>------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: The C. K. <eld...@ya...> - 2017-08-29 19:23:19
|
why not just let the fsck details be printed to the primary console?
From: Lonnie Abelbeck <li...@lo...>
To: AstLinux Developers Mailing List <ast...@li...>
Sent: Tuesday, August 29, 2017 2:12 PM
Subject: [Astlinux-devel] Adding a "spinner" indicator when e2fsck is working
Hi Devs,
David made a good point, so I looked into piping the output of e2fsck to a "spinner" shell function, triggered by a newline and update no more often then ever second ...--spinner()
{
local i sp secs nsecs line IFS
i=0
secs=0
unset IFS
while read line; do
nsecs=$(cut -d. -f1 /proc/uptime)
if [ $nsecs -ne $secs ]; then
secs=$nsecs
i=$(((i+1)%4))
case $i in
1) sp='-' ;;
2) sp='\' ;;
3) sp='|' ;;
*) sp='/' ;;
esac
echo -ne " Working[${sp}] \r"
fi
done
echo -ne " \r"
}
--It took some work getting this to work without printf, no date, no bash ${str:1:1}, etc., but it works with the current Busybox configs.
But ... here are the two places "spinner" would apply to ...
1) in the initrd, linuxrc ...-- e2fsck -y $ASTURW >/dev/null
status=$?
case $status in--
2) in astlinux, /etc/rc ...-- echo "Checking $1"
e2fsck -y $1 >/dev/null
status="$?"
case $status in--
The plan would be to use:--e2fsck -y $1 | spinner--But the return value of $? is no longer from e2fsck, but rather spinner
You might try ...--( e2fsck -y $1 ; status="$?" ) | spinner--Almost, but now "status" is defined in a subshell which is not propagated up and lost.
A simple but ugly solution is to use a temp file ...--( e2fsck -y $1 ; echo "$?" > /tmp/e2fsck_status ) | spinnerstatus="$(cat /tmp/e2fsck_status)"rm /tmp/e2fsck_status--but not to mention the initrd does not currently mount a /tmp filesystem. We would have to have to create and delete a tmpfs filesystem just to get the return value from e2fsck. :-(
I'm leaning toward leaving things as is, comments ?
Lonnie
On Aug 29, 2017, at 8:20 AM, Lonnie Abelbeck <li...@lo...> wrote:
Hi David,
Agreed, no e2fsck output when it is forced to work for a long period is not ideal. Thankfully this is a very rare occurrence.
If we can come up with a clever spinning wheel or such counting the lines e2fsck generates might be a good addition.
Recall this all occurs in the "initrd", so the available packages and BusyBox config is quite limited.
Any further discussion on this idea should move to the astlinux-devel list.
Lonnie
On Aug 29, 2017, at 7:48 AM, David Kerr <Da...@Ke...> wrote:
Is that a good idea (redirecting e2fsck to null)? 15 minutes is a long time to wait with no indication of anything happening.
David
On Tue, Aug 29, 2017 at 8:33 AM, Lonnie Abelbeck <li...@lo...> wrote:
Hi Tim,
Yes, it was running "e2fsck" with stdout redirected to /dev/null so you did not see it working ... eventually e2fsck will return with a result code if left long enough.
Good to hear your filesystem is now clean, you might reboot once again to make sure the filesystem is good.
BTW, if the automatic e2fsck repair did not work, here is the manual fallback procedure:
--
## reboot, and quickly when the RUNNIX boot menu appears type "shell"
boot: shell
## Wait for a "runnix# " CLI prompt.
## determine the first Linux ext2 partition, usually always /dev/sda2
runnix# findfs LABEL=ASTURW
## using the findfs result, run e2fsck manually, you may want to add -y or -p options
runnix# e2fsck /dev/sda2
## output a list of options for e2fsck
runnix# e2fsck
Usage: e2fsck [-panyrcdfktvDFV] [-b superblock] [-B blocksize]
[-l|-L bad_blocks_file] [-C fd] [-j external_journal]
[-E extended-options] [-z undo_file] device
Emergency help:
-p Automatic repair (no questions)
-n Make no changes to the filesystem
-y Assume "yes" to all questions
-c Check for bad blocks and add them to the badblock list
-f Force checking even if filesystem is marked clean
-v Be verbose
-b superblock Use alternative superblock
-B blocksize Force blocksize when looking for superblock
-j external_journal Set location of the external journal
-l bad_blocks_file Add to badblocks list
-L bad_blocks_file Set badblocks list
-z undo_file Create an undo file
## Depending on how you initially configured AstLinux, check if you also have a ASTKD partition
## (typically /dev/sda3 if it exists)
runnix# findfs LABEL=ASTKD
## If the ASTKD label exists repeat the e2fsck steps above using the ASTKD label partition.
## reboot by issuing "exit"
runnix# exit
--
Lonnie
On Aug 29, 2017, at 7:02 AM, Tim Turpin <tt...@z-...> wrote:
Never mind. After sitting at that point for about 15 minutes, it somehow recovered and finished booting up. All seems well now.
From: Tim Turpin [mailto:tt...@z-...]
Sent: Tuesday, August 29, 2017 7:34 AM
To: ast...@li...
Subject: [Astlinux-users] ASTLinux stopped booting
We took a power hit on our test system yesterday, and now it will only load up to a certain point and stops with the following screen:
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Michael K. <li...@mk...> - 2017-08-29 18:42:59
|
> Am 29.08.2017 um 20:30 schrieb Lonnie Abelbeck <li...@lo...>:
>
>
> On Aug 29, 2017, at 1:18 PM, Michael Keuter <li...@mk...> wrote:
>
>>
>>> Am 29.08.2017 um 20:12 schrieb Lonnie Abelbeck <li...@lo...>:
>>>
>>> Hi Devs,
>>>
>>> David made a good point, so I looked into piping the output of e2fsck to a "spinner" shell function, triggered by a newline and update no more often then ever second ...
>>> --
>>> spinner()
>>> {
>>> local i sp secs nsecs line IFS
>>>
>>> i=0
>>> secs=0
>>>
>>> unset IFS
>>> while read line; do
>>> nsecs=$(cut -d. -f1 /proc/uptime)
>>> if [ $nsecs -ne $secs ]; then
>>> secs=$nsecs
>>> i=$(((i+1)%4))
>>> case $i in
>>> 1) sp='-' ;;
>>> 2) sp='\' ;;
>>> 3) sp='|' ;;
>>> *) sp='/' ;;
>>> esac
>>> echo -ne " Working[${sp}] \r"
>>> fi
>>> done
>>>
>>> echo -ne " \r"
>>> }
>>> --
>>> It took some work getting this to work without printf, no date, no bash ${str:1:1}, etc., but it works with the current Busybox configs.
>>>
>>> But ... here are the two places "spinner" would apply to ...
>>>
>>> 1) in the initrd, linuxrc ...
>>> --
>>> e2fsck -y $ASTURW >/dev/null
>>> status=$?
>>>
>>> case $status in
>>> --
>>>
>>> 2) in astlinux, /etc/rc ...
>>> --
>>> echo "Checking $1"
>>> e2fsck -y $1 >/dev/null
>>>
>>> status="$?"
>>>
>>> case $status in
>>> --
>>>
>>> The plan would be to use:
>>> --
>>> e2fsck -y $1 | spinner
>>> --
>>> But the return value of $? is no longer from e2fsck, but rather spinner
>>>
>>> You might try ...
>>> --
>>> ( e2fsck -y $1 ; status="$?" ) | spinner
>>> --
>>> Almost, but now "status" is defined in a subshell which is not propagated up and lost.
>>>
>>> A simple but ugly solution is to use a temp file ...
>>> --
>>> ( e2fsck -y $1 ; echo "$?" > /tmp/e2fsck_status ) | spinner
>>> status="$(cat /tmp/e2fsck_status)"
>>> rm /tmp/e2fsck_status
>>> --
>>> but not to mention the initrd does not currently mount a /tmp filesystem. We would have to have to create and delete a tmpfs filesystem just to get the return value from e2fsck. :-(
>>>
>>> I'm leaning toward leaving things as is, comments ?
>>>
>>> Lonnie
>>>
>>>
>>> On Aug 29, 2017, at 8:20 AM, Lonnie Abelbeck <li...@lo...> wrote:
>>>
>>>> Hi David,
>>>>
>>>> Agreed, no e2fsck output when it is forced to work for a long period is not ideal. Thankfully this is a very rare occurrence.
>>>>
>>>> If we can come up with a clever spinning wheel or such counting the lines e2fsck generates might be a good addition.
>>>>
>>>> Recall this all occurs in the "initrd", so the available packages and BusyBox config is quite limited.
>>>>
>>>> Any further discussion on this idea should move to the astlinux-devel list.
>>>>
>>>> Lonnie
>>>>
>>>>
>>>> On Aug 29, 2017, at 7:48 AM, David Kerr <Da...@Ke...> wrote:
>>>>
>>>>> Is that a good idea (redirecting e2fsck to null)? 15 minutes is a long time to wait with no indication of anything happening.
>>>>>
>>>>> David
>>>>>
>>>>> On Tue, Aug 29, 2017 at 8:33 AM, Lonnie Abelbeck <li...@lo...> wrote:
>>>>> Hi Tim,
>>>>>
>>>>> Yes, it was running "e2fsck" with stdout redirected to /dev/null so you did not see it working ... eventually e2fsck will return with a result code if left long enough.
>>>>>
>>>>> Good to hear your filesystem is now clean, you might reboot once again to make sure the filesystem is good.
>>>>>
>>>>> BTW, if the automatic e2fsck repair did not work, here is the manual fallback procedure:
>>>>> --
>>>>> ## reboot, and quickly when the RUNNIX boot menu appears type "shell"
>>>>> boot: shell
>>>>>
>>>>> ## Wait for a "runnix# " CLI prompt.
>>>>> ## determine the first Linux ext2 partition, usually always /dev/sda2
>>>>> runnix# findfs LABEL=ASTURW
>>>>>
>>>>> ## using the findfs result, run e2fsck manually, you may want to add -y or -p options
>>>>> runnix# e2fsck /dev/sda2
>>>>>
>>>>> ## output a list of options for e2fsck
>>>>> runnix# e2fsck
>>>>> Usage: e2fsck [-panyrcdfktvDFV] [-b superblock] [-B blocksize]
>>>>> [-l|-L bad_blocks_file] [-C fd] [-j external_journal]
>>>>> [-E extended-options] [-z undo_file] device
>>>>>
>>>>> Emergency help:
>>>>> -p Automatic repair (no questions)
>>>>> -n Make no changes to the filesystem
>>>>> -y Assume "yes" to all questions
>>>>> -c Check for bad blocks and add them to the badblock list
>>>>> -f Force checking even if filesystem is marked clean
>>>>> -v Be verbose
>>>>> -b superblock Use alternative superblock
>>>>> -B blocksize Force blocksize when looking for superblock
>>>>> -j external_journal Set location of the external journal
>>>>> -l bad_blocks_file Add to badblocks list
>>>>> -L bad_blocks_file Set badblocks list
>>>>> -z undo_file Create an undo file
>>>>>
>>>>> ## Depending on how you initially configured AstLinux, check if you also have a ASTKD partition
>>>>> ## (typically /dev/sda3 if it exists)
>>>>> runnix# findfs LABEL=ASTKD
>>>>> ## If the ASTKD label exists repeat the e2fsck steps above using the ASTKD label partition.
>>>>>
>>>>> ## reboot by issuing "exit"
>>>>> runnix# exit
>>>>> --
>>>>>
>>>>> Lonnie
>>>>>
>>>>>
>>>>> On Aug 29, 2017, at 7:02 AM, Tim Turpin <tt...@z-...> wrote:
>>>>>
>>>>>> Never mind. After sitting at that point for about 15 minutes, it somehow recovered and finished booting up. All seems well now.
>>>>>>
>>>>>> From: Tim Turpin [mailto:tt...@z-...]
>>>>>> Sent: Tuesday, August 29, 2017 7:34 AM
>>>>>> To: ast...@li...
>>>>>> Subject: [Astlinux-users] ASTLinux stopped booting
>>>>>>
>>>>>> We took a power hit on our test system yesterday, and now it will only load up to a certain point and stops with the following screen:
>>
>> Lonnie, don't give up so quickly :-).
>> What you have already is quite a good starting point.
>> What about adding "something needed" to our initrd busybox.config …
>>
>> Michael
>
> The initrd busybox config is not the problem, this is a fundamental problem using shell, though easily solved with bash, but bash is not a practical option with our initrd.
>
> Get exit status of process that's piped to another
> https://unix.stackexchange.com/questions/14270/get-exit-status-of-process-thats-piped-to-another
>
> I dont see an elegant solution.
>
> My only other thought would be to create a background "spinner" process, then call "e2fsck -y $1 >/dev/null" and status="$?" then stop the background spinner process.
Sounds not so bad, at least worth a test.
BTW: Wasn't there a kind of mini-shell in busybox ("ash" or so)?
> Lonnie
Michael
http://www.mksolutions.info
|
|
From: Lonnie A. <li...@lo...> - 2017-08-29 18:30:52
|
On Aug 29, 2017, at 1:18 PM, Michael Keuter <li...@mk...> wrote:
>
>> Am 29.08.2017 um 20:12 schrieb Lonnie Abelbeck <li...@lo...>:
>>
>> Hi Devs,
>>
>> David made a good point, so I looked into piping the output of e2fsck to a "spinner" shell function, triggered by a newline and update no more often then ever second ...
>> --
>> spinner()
>> {
>> local i sp secs nsecs line IFS
>>
>> i=0
>> secs=0
>>
>> unset IFS
>> while read line; do
>> nsecs=$(cut -d. -f1 /proc/uptime)
>> if [ $nsecs -ne $secs ]; then
>> secs=$nsecs
>> i=$(((i+1)%4))
>> case $i in
>> 1) sp='-' ;;
>> 2) sp='\' ;;
>> 3) sp='|' ;;
>> *) sp='/' ;;
>> esac
>> echo -ne " Working[${sp}] \r"
>> fi
>> done
>>
>> echo -ne " \r"
>> }
>> --
>> It took some work getting this to work without printf, no date, no bash ${str:1:1}, etc., but it works with the current Busybox configs.
>>
>> But ... here are the two places "spinner" would apply to ...
>>
>> 1) in the initrd, linuxrc ...
>> --
>> e2fsck -y $ASTURW >/dev/null
>> status=$?
>>
>> case $status in
>> --
>>
>> 2) in astlinux, /etc/rc ...
>> --
>> echo "Checking $1"
>> e2fsck -y $1 >/dev/null
>>
>> status="$?"
>>
>> case $status in
>> --
>>
>> The plan would be to use:
>> --
>> e2fsck -y $1 | spinner
>> --
>> But the return value of $? is no longer from e2fsck, but rather spinner
>>
>> You might try ...
>> --
>> ( e2fsck -y $1 ; status="$?" ) | spinner
>> --
>> Almost, but now "status" is defined in a subshell which is not propagated up and lost.
>>
>> A simple but ugly solution is to use a temp file ...
>> --
>> ( e2fsck -y $1 ; echo "$?" > /tmp/e2fsck_status ) | spinner
>> status="$(cat /tmp/e2fsck_status)"
>> rm /tmp/e2fsck_status
>> --
>> but not to mention the initrd does not currently mount a /tmp filesystem. We would have to have to create and delete a tmpfs filesystem just to get the return value from e2fsck. :-(
>>
>> I'm leaning toward leaving things as is, comments ?
>>
>> Lonnie
>>
>>
>> On Aug 29, 2017, at 8:20 AM, Lonnie Abelbeck <li...@lo...> wrote:
>>
>>> Hi David,
>>>
>>> Agreed, no e2fsck output when it is forced to work for a long period is not ideal. Thankfully this is a very rare occurrence.
>>>
>>> If we can come up with a clever spinning wheel or such counting the lines e2fsck generates might be a good addition.
>>>
>>> Recall this all occurs in the "initrd", so the available packages and BusyBox config is quite limited.
>>>
>>> Any further discussion on this idea should move to the astlinux-devel list.
>>>
>>> Lonnie
>>>
>>>
>>> On Aug 29, 2017, at 7:48 AM, David Kerr <Da...@Ke...> wrote:
>>>
>>>> Is that a good idea (redirecting e2fsck to null)? 15 minutes is a long time to wait with no indication of anything happening.
>>>>
>>>> David
>>>>
>>>> On Tue, Aug 29, 2017 at 8:33 AM, Lonnie Abelbeck <li...@lo...> wrote:
>>>> Hi Tim,
>>>>
>>>> Yes, it was running "e2fsck" with stdout redirected to /dev/null so you did not see it working ... eventually e2fsck will return with a result code if left long enough.
>>>>
>>>> Good to hear your filesystem is now clean, you might reboot once again to make sure the filesystem is good.
>>>>
>>>> BTW, if the automatic e2fsck repair did not work, here is the manual fallback procedure:
>>>> --
>>>> ## reboot, and quickly when the RUNNIX boot menu appears type "shell"
>>>> boot: shell
>>>>
>>>> ## Wait for a "runnix# " CLI prompt.
>>>> ## determine the first Linux ext2 partition, usually always /dev/sda2
>>>> runnix# findfs LABEL=ASTURW
>>>>
>>>> ## using the findfs result, run e2fsck manually, you may want to add -y or -p options
>>>> runnix# e2fsck /dev/sda2
>>>>
>>>> ## output a list of options for e2fsck
>>>> runnix# e2fsck
>>>> Usage: e2fsck [-panyrcdfktvDFV] [-b superblock] [-B blocksize]
>>>> [-l|-L bad_blocks_file] [-C fd] [-j external_journal]
>>>> [-E extended-options] [-z undo_file] device
>>>>
>>>> Emergency help:
>>>> -p Automatic repair (no questions)
>>>> -n Make no changes to the filesystem
>>>> -y Assume "yes" to all questions
>>>> -c Check for bad blocks and add them to the badblock list
>>>> -f Force checking even if filesystem is marked clean
>>>> -v Be verbose
>>>> -b superblock Use alternative superblock
>>>> -B blocksize Force blocksize when looking for superblock
>>>> -j external_journal Set location of the external journal
>>>> -l bad_blocks_file Add to badblocks list
>>>> -L bad_blocks_file Set badblocks list
>>>> -z undo_file Create an undo file
>>>>
>>>> ## Depending on how you initially configured AstLinux, check if you also have a ASTKD partition
>>>> ## (typically /dev/sda3 if it exists)
>>>> runnix# findfs LABEL=ASTKD
>>>> ## If the ASTKD label exists repeat the e2fsck steps above using the ASTKD label partition.
>>>>
>>>> ## reboot by issuing "exit"
>>>> runnix# exit
>>>> --
>>>>
>>>> Lonnie
>>>>
>>>>
>>>> On Aug 29, 2017, at 7:02 AM, Tim Turpin <tt...@z-...> wrote:
>>>>
>>>>> Never mind. After sitting at that point for about 15 minutes, it somehow recovered and finished booting up. All seems well now.
>>>>>
>>>>> From: Tim Turpin [mailto:tt...@z-...]
>>>>> Sent: Tuesday, August 29, 2017 7:34 AM
>>>>> To: ast...@li...
>>>>> Subject: [Astlinux-users] ASTLinux stopped booting
>>>>>
>>>>> We took a power hit on our test system yesterday, and now it will only load up to a certain point and stops with the following screen:
>
> Lonnie, don't give up so quickly :-).
> What you have already is quite a good starting point.
> What about adding "something needed" to our initrd busybox.config …
>
> Michael
The initrd busybox config is not the problem, this is a fundamental problem using shell, though easily solved with bash, but bash is not a practical option with our initrd.
Get exit status of process that's piped to another
https://unix.stackexchange.com/questions/14270/get-exit-status-of-process-thats-piped-to-another
I dont see an elegant solution.
My only other thought would be to create a background "spinner" process, then call "e2fsck -y $1 >/dev/null" and status="$?" then stop the background spinner process.
Lonnie
|
|
From: Michael K. <li...@mk...> - 2017-08-29 18:18:48
|
> Am 29.08.2017 um 20:12 schrieb Lonnie Abelbeck <li...@lo...>:
>
> Hi Devs,
>
> David made a good point, so I looked into piping the output of e2fsck to a "spinner" shell function, triggered by a newline and update no more often then ever second ...
> --
> spinner()
> {
> local i sp secs nsecs line IFS
>
> i=0
> secs=0
>
> unset IFS
> while read line; do
> nsecs=$(cut -d. -f1 /proc/uptime)
> if [ $nsecs -ne $secs ]; then
> secs=$nsecs
> i=$(((i+1)%4))
> case $i in
> 1) sp='-' ;;
> 2) sp='\' ;;
> 3) sp='|' ;;
> *) sp='/' ;;
> esac
> echo -ne " Working[${sp}] \r"
> fi
> done
>
> echo -ne " \r"
> }
> --
> It took some work getting this to work without printf, no date, no bash ${str:1:1}, etc., but it works with the current Busybox configs.
>
> But ... here are the two places "spinner" would apply to ...
>
> 1) in the initrd, linuxrc ...
> --
> e2fsck -y $ASTURW >/dev/null
> status=$?
>
> case $status in
> --
>
> 2) in astlinux, /etc/rc ...
> --
> echo "Checking $1"
> e2fsck -y $1 >/dev/null
>
> status="$?"
>
> case $status in
> --
>
> The plan would be to use:
> --
> e2fsck -y $1 | spinner
> --
> But the return value of $? is no longer from e2fsck, but rather spinner
>
> You might try ...
> --
> ( e2fsck -y $1 ; status="$?" ) | spinner
> --
> Almost, but now "status" is defined in a subshell which is not propagated up and lost.
>
> A simple but ugly solution is to use a temp file ...
> --
> ( e2fsck -y $1 ; echo "$?" > /tmp/e2fsck_status ) | spinner
> status="$(cat /tmp/e2fsck_status)"
> rm /tmp/e2fsck_status
> --
> but not to mention the initrd does not currently mount a /tmp filesystem. We would have to have to create and delete a tmpfs filesystem just to get the return value from e2fsck. :-(
>
> I'm leaning toward leaving things as is, comments ?
>
> Lonnie
>
>
> On Aug 29, 2017, at 8:20 AM, Lonnie Abelbeck <li...@lo...> wrote:
>
>> Hi David,
>>
>> Agreed, no e2fsck output when it is forced to work for a long period is not ideal. Thankfully this is a very rare occurrence.
>>
>> If we can come up with a clever spinning wheel or such counting the lines e2fsck generates might be a good addition.
>>
>> Recall this all occurs in the "initrd", so the available packages and BusyBox config is quite limited.
>>
>> Any further discussion on this idea should move to the astlinux-devel list.
>>
>> Lonnie
>>
>>
>> On Aug 29, 2017, at 7:48 AM, David Kerr <Da...@Ke...> wrote:
>>
>>> Is that a good idea (redirecting e2fsck to null)? 15 minutes is a long time to wait with no indication of anything happening.
>>>
>>> David
>>>
>>> On Tue, Aug 29, 2017 at 8:33 AM, Lonnie Abelbeck <li...@lo...> wrote:
>>> Hi Tim,
>>>
>>> Yes, it was running "e2fsck" with stdout redirected to /dev/null so you did not see it working ... eventually e2fsck will return with a result code if left long enough.
>>>
>>> Good to hear your filesystem is now clean, you might reboot once again to make sure the filesystem is good.
>>>
>>> BTW, if the automatic e2fsck repair did not work, here is the manual fallback procedure:
>>> --
>>> ## reboot, and quickly when the RUNNIX boot menu appears type "shell"
>>> boot: shell
>>>
>>> ## Wait for a "runnix# " CLI prompt.
>>> ## determine the first Linux ext2 partition, usually always /dev/sda2
>>> runnix# findfs LABEL=ASTURW
>>>
>>> ## using the findfs result, run e2fsck manually, you may want to add -y or -p options
>>> runnix# e2fsck /dev/sda2
>>>
>>> ## output a list of options for e2fsck
>>> runnix# e2fsck
>>> Usage: e2fsck [-panyrcdfktvDFV] [-b superblock] [-B blocksize]
>>> [-l|-L bad_blocks_file] [-C fd] [-j external_journal]
>>> [-E extended-options] [-z undo_file] device
>>>
>>> Emergency help:
>>> -p Automatic repair (no questions)
>>> -n Make no changes to the filesystem
>>> -y Assume "yes" to all questions
>>> -c Check for bad blocks and add them to the badblock list
>>> -f Force checking even if filesystem is marked clean
>>> -v Be verbose
>>> -b superblock Use alternative superblock
>>> -B blocksize Force blocksize when looking for superblock
>>> -j external_journal Set location of the external journal
>>> -l bad_blocks_file Add to badblocks list
>>> -L bad_blocks_file Set badblocks list
>>> -z undo_file Create an undo file
>>>
>>> ## Depending on how you initially configured AstLinux, check if you also have a ASTKD partition
>>> ## (typically /dev/sda3 if it exists)
>>> runnix# findfs LABEL=ASTKD
>>> ## If the ASTKD label exists repeat the e2fsck steps above using the ASTKD label partition.
>>>
>>> ## reboot by issuing "exit"
>>> runnix# exit
>>> --
>>>
>>> Lonnie
>>>
>>>
>>> On Aug 29, 2017, at 7:02 AM, Tim Turpin <tt...@z-...> wrote:
>>>
>>>> Never mind. After sitting at that point for about 15 minutes, it somehow recovered and finished booting up. All seems well now.
>>>>
>>>> From: Tim Turpin [mailto:tt...@z-...]
>>>> Sent: Tuesday, August 29, 2017 7:34 AM
>>>> To: ast...@li...
>>>> Subject: [Astlinux-users] ASTLinux stopped booting
>>>>
>>>> We took a power hit on our test system yesterday, and now it will only load up to a certain point and stops with the following screen:
Lonnie, don't give up so quickly :-).
What you have already is quite a good starting point.
What about adding "something needed" to our initrd busybox.config …
Michael
http://www.mksolutions.info
|
|
From: Lonnie A. <li...@lo...> - 2017-08-29 18:12:47
|
Hi Devs,
David made a good point, so I looked into piping the output of e2fsck to a "spinner" shell function, triggered by a newline and update no more often then ever second ...
--
spinner()
{
local i sp secs nsecs line IFS
i=0
secs=0
unset IFS
while read line; do
nsecs=$(cut -d. -f1 /proc/uptime)
if [ $nsecs -ne $secs ]; then
secs=$nsecs
i=$(((i+1)%4))
case $i in
1) sp='-' ;;
2) sp='\' ;;
3) sp='|' ;;
*) sp='/' ;;
esac
echo -ne " Working[${sp}] \r"
fi
done
echo -ne " \r"
}
--
It took some work getting this to work without printf, no date, no bash ${str:1:1}, etc., but it works with the current Busybox configs.
But ... here are the two places "spinner" would apply to ...
1) in the initrd, linuxrc ...
--
e2fsck -y $ASTURW >/dev/null
status=$?
case $status in
--
2) in astlinux, /etc/rc ...
--
echo "Checking $1"
e2fsck -y $1 >/dev/null
status="$?"
case $status in
--
The plan would be to use:
--
e2fsck -y $1 | spinner
--
But the return value of $? is no longer from e2fsck, but rather spinner
You might try ...
--
( e2fsck -y $1 ; status="$?" ) | spinner
--
Almost, but now "status" is defined in a subshell which is not propagated up and lost.
A simple but ugly solution is to use a temp file ...
--
( e2fsck -y $1 ; echo "$?" > /tmp/e2fsck_status ) | spinner
status="$(cat /tmp/e2fsck_status)"
rm /tmp/e2fsck_status
--
but not to mention the initrd does not currently mount a /tmp filesystem. We would have to have to create and delete a tmpfs filesystem just to get the return value from e2fsck. :-(
I'm leaning toward leaving things as is, comments ?
Lonnie
On Aug 29, 2017, at 8:20 AM, Lonnie Abelbeck <li...@lo...> wrote:
> Hi David,
>
> Agreed, no e2fsck output when it is forced to work for a long period is not ideal. Thankfully this is a very rare occurrence.
>
> If we can come up with a clever spinning wheel or such counting the lines e2fsck generates might be a good addition.
>
> Recall this all occurs in the "initrd", so the available packages and BusyBox config is quite limited.
>
> Any further discussion on this idea should move to the astlinux-devel list.
>
> Lonnie
>
>
> On Aug 29, 2017, at 7:48 AM, David Kerr <Da...@Ke...> wrote:
>
>> Is that a good idea (redirecting e2fsck to null)? 15 minutes is a long time to wait with no indication of anything happening.
>>
>> David
>>
>> On Tue, Aug 29, 2017 at 8:33 AM, Lonnie Abelbeck <li...@lo...> wrote:
>> Hi Tim,
>>
>> Yes, it was running "e2fsck" with stdout redirected to /dev/null so you did not see it working ... eventually e2fsck will return with a result code if left long enough.
>>
>> Good to hear your filesystem is now clean, you might reboot once again to make sure the filesystem is good.
>>
>> BTW, if the automatic e2fsck repair did not work, here is the manual fallback procedure:
>> --
>> ## reboot, and quickly when the RUNNIX boot menu appears type "shell"
>> boot: shell
>>
>> ## Wait for a "runnix# " CLI prompt.
>> ## determine the first Linux ext2 partition, usually always /dev/sda2
>> runnix# findfs LABEL=ASTURW
>>
>> ## using the findfs result, run e2fsck manually, you may want to add -y or -p options
>> runnix# e2fsck /dev/sda2
>>
>> ## output a list of options for e2fsck
>> runnix# e2fsck
>> Usage: e2fsck [-panyrcdfktvDFV] [-b superblock] [-B blocksize]
>> [-l|-L bad_blocks_file] [-C fd] [-j external_journal]
>> [-E extended-options] [-z undo_file] device
>>
>> Emergency help:
>> -p Automatic repair (no questions)
>> -n Make no changes to the filesystem
>> -y Assume "yes" to all questions
>> -c Check for bad blocks and add them to the badblock list
>> -f Force checking even if filesystem is marked clean
>> -v Be verbose
>> -b superblock Use alternative superblock
>> -B blocksize Force blocksize when looking for superblock
>> -j external_journal Set location of the external journal
>> -l bad_blocks_file Add to badblocks list
>> -L bad_blocks_file Set badblocks list
>> -z undo_file Create an undo file
>>
>> ## Depending on how you initially configured AstLinux, check if you also have a ASTKD partition
>> ## (typically /dev/sda3 if it exists)
>> runnix# findfs LABEL=ASTKD
>> ## If the ASTKD label exists repeat the e2fsck steps above using the ASTKD label partition.
>>
>> ## reboot by issuing "exit"
>> runnix# exit
>> --
>>
>> Lonnie
>>
>>
>> On Aug 29, 2017, at 7:02 AM, Tim Turpin <tt...@z-...> wrote:
>>
>>> Never mind. After sitting at that point for about 15 minutes, it somehow recovered and finished booting up. All seems well now.
>>>
>>> From: Tim Turpin [mailto:tt...@z-...]
>>> Sent: Tuesday, August 29, 2017 7:34 AM
>>> To: ast...@li...
>>> Subject: [Astlinux-users] ASTLinux stopped booting
>>>
>>> We took a power hit on our test system yesterday, and now it will only load up to a certain point and stops with the following screen:
|
|
From: Lonnie A. <li...@lo...> - 2017-08-25 17:54:53
|
Devs, (update) > -- > Rule: Never remove a directory in the path '/oldroot/mnt/asturw/...' > -- I still recommend the above rule. Though looking at the unionfs kernel documentation -=-=-=-= Documentation/filesystems/unionfs/usage.txt -=-=-=-= CACHE CONSISTENCY ================= If you modify any file on any of the lower branches directly, while there is a Unionfs 2.x mounted above any of those branches, you should tell Unionfs to purge its caches and re-get the objects. To do that, you have to increment the generation number of the superblock using the following command: # mount -t unionfs -o remount,incgen none MOUNTPOINT -=-=-=-= Indeed, if I remove a directory in the path '/oldroot/mnt/asturw/...' and *immediately* follow it with the command ... -- mount -t unionfs -o remount,incgen none / -- it seems to work (*much* better than not issuing the 'remount,incgen'), but I'm not convinced it is *perfect*. BTW as before, directly removing a file in '/oldroot/mnt/asturw/...' does not require the 'remount,incgen' and continues to work fine, as it has in the past. unionfs automatically handles the lower file removal case. So, for development purposes only, I mention this 'remount,incgen' workaround for directly removing a directory in the lower filesystem while unionfs is mounted. Best to also kernel-reboot or reboot afterwords. BTW, in Linux kernels 3.18 and beyond the unionfs alternative is overlayfs, but overlayfs forbids any lower direct file manipulation while mounted ... -=-=-=-= Documentation/filesystems/overlayfs.txt -=-=-=-= Changes to underlying filesystems --------------------------------- Offline changes, when the overlay is not mounted, are allowed to either the upper or the lower trees. Changes to the underlying filesystems while part of a mounted overlay filesystem are not allowed. If the underlying filesystem is changed, the behavior of the overlay is undefined, though it will not result in a crash or deadlock. -=-=-=-= Lonnie On Jun 1, 2017, at 8:30 PM, Lonnie Abelbeck <li...@lo...> wrote: > > On Jun 1, 2017, at 7:21 PM, David Kerr <Da...@Ke...> wrote: > >> Okay, so... occasionally I replace a file in e.g. /usr/sbin while testing some change I may have made. When that change is eventually incorporated into the build tree I am in the habit of going into /oldroot/mnt/asturw/usr and then rm -rf sbin. >> >> I think you are saying that this is bad? Right? > > I used to do that as well, don't remove any directories, though removing a file is fine. I found this out by cleaning-up after editing the traffic shaper plugin for testing. > -- > Rule: Never remove a directory in the path '/oldroot/mnt/asturw/...' > -- > > >> So instead I should go into /oldroot/mnt/asturw/usr/sbin and rm the file, and just leave the sbin directory alone? > > Yes, to help, the new "show-union" will not show you the empty directories anymore. Simply ignore the ASTURW empty directories. > > Some day we may consider automatically cleaning up these empty directories if we ever thought they could be a problem, but a non-issue today. That would have to be done in the initrd. > > >> What are the consequences of erasing the directory? And if I do erase a directory will a reboot make things okay again? > > It seems any open file in the path will get flushed from memory, typically the AIF plugin helper scripts will be effected if '/oldroot/mnt/asturw/usr/...' and as such you won't get a clean shutdown, you will need to power cycle the box. > > We can hope the unionfs folks will generate a new set of patches, but I would expect we just need to live with this. > > As I recall, many years ago in the Linux 2.6 days. several versions of unionfs ago, this same problem existed. > > Lonnie > > > >> Thanks >> David >> >> On Thu, Jun 1, 2017 at 9:55 AM, Lonnie Abelbeck <li...@lo...> wrote: >> Hi Devs, >> >> First, it has been 10 days since we bumped the kernel to 3.16.43, and things appear to be running solid at this point, much thanks for all the assistance in getting this major task accomplished. >> >> Though I ran across a glitch, with unionfs, basically you no longer can remove a *directory* in the path '/oldroot/mnt/asturw/...' as unionfs with kernel 3.16 has an issue with that. Such a deletion now also effects open files in the same path, in memory. >> >> Removing a *file* in the '/oldroot/mnt/asturw/...' path appears to be OK, which is important, since that is the only way to "undo" an edit of a file on '/oldroot/mnt/asturo/...' >> >> I sent an email to Erez Zadok at Stony Brook University as well as the unionfs mailing list, where I go into more detail. >> >> [Unionfs] unionfs with Linux 3.16 >> http://www.fsl.cs.sunysb.edu/pipermail/unionfs/2017-May/006196.html >> >> I looked over our scripts and we only needed a few changes to implement the new rule: >> -- >> Rule: Never remove a directory in the path '/oldroot/mnt/asturw/...' >> -- >> (Revision: 8361) >> >> The 'show-union' command now only shows files, so as not to encourage directory removal, except 'show-union all' shows directories as well. >> >> Any stale directories on ASTURW should not happen for normal users in production, but during development it can be handy to edit ASTURO files, so if you wanted to remove these stale directories (leaving them be is fine) you need to reboot to RUNNIX and mount /dev/sda2 as -t ext2. >> >> Lonnie >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > |
|
From: Lonnie A. <li...@lo...> - 2017-08-18 16:03:16
|
On Aug 18, 2017, at 10:20 AM, Armin Tüting <arm...@tu...> wrote: > On Thu, 2017-08-17 at 10:38 -0500, Lonnie Abelbeck wrote: >> The AstLinux Project is now hosted on GitHub, both 'svn checkout' and >> 'git clone' are supported: > Thanks Loonie. > I've done a git clone and build - all works fine! > The only thing is the versioning - I'm getting 'astlinux-1.3-05163a'. > Looks a bit strange... > > ... > > Regards, > Armin. Hi Armin, thanks for taking the new GitHub repo for a spin. Yes, if you use a "git clone" for the astlinux-project/astlinux.git and build within git, the "astlinux-1.3-05163a" release includes the current git SHA1 hash "05163a" (first 6 chars), with that you can show the last included commit: -- https://github.com/astlinux-project/astlinux/commit/05163a -- Or the history of the current and previous commits: -- https://github.com/astlinux-project/astlinux/commits/05163a -- You could also "svn co https://github.com/astlinux-project/astlinux.git/trunk" and build within an SVN checkout, the same version as above will be marked as "astlinux-1.3-3360-05163a" including a SVN revision number. Your choice. Lonnie |
|
From: Armin T. <arm...@tu...> - 2017-08-18 15:36:35
|
On Thu, 2017-08-17 at 10:38 -0500, Lonnie Abelbeck wrote: > The AstLinux Project is now hosted on GitHub, both 'svn checkout' and > 'git clone' are supported: Thanks Loonie. I've done a git clone and build - all works fine! The only thing is the versioning - I'm getting 'astlinux-1.3-05163a'. Looks a bit strange... ... Regards, Armin. |
|
From: David K. <da...@ke...> - 2017-08-17 21:22:44
|
Thanks Lonnie. I think Github is a much better platform for astlinux and I am honored to have Pull Request #1 accepted into the master. David On Thu, Aug 17, 2017 at 11:38 AM, Lonnie Abelbeck <li...@lo... > wrote: > The AstLinux Project is now hosted on GitHub, both 'svn checkout' and 'git > clone' are supported: > > AstLinux Project at GitHub > https://github.com/astlinux-project/astlinux > > All current development is on GitHub. Pull Requests are welcomed. > > Note: The Sourgeforge mailing lists [astlinux-users] and [astlinux-devel] > will continue to be used as before. > > For AstLinux users, there should be no noticeable change. > > For AstLinux developers, custom builds will require a new checkout: > -- > svn co https://github.com/astlinux-project/astlinux.git/trunk > astlinux/trunk > -- > The Developer docs have been updated, but not much has changed: > https://doc.astlinux-project.org/devdoc:documentation > > > Special thanks to David Kerr for assisting in researching and testing, > making the migration straightforward. > > AstLinux Team > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > |
|
From: Lonnie A. <li...@lo...> - 2017-08-17 15:39:03
|
The AstLinux Project is now hosted on GitHub, both 'svn checkout' and 'git clone' are supported: AstLinux Project at GitHub https://github.com/astlinux-project/astlinux All current development is on GitHub. Pull Requests are welcomed. Note: The Sourgeforge mailing lists [astlinux-users] and [astlinux-devel] will continue to be used as before. For AstLinux users, there should be no noticeable change. For AstLinux developers, custom builds will require a new checkout: -- svn co https://github.com/astlinux-project/astlinux.git/trunk astlinux/trunk -- The Developer docs have been updated, but not much has changed: https://doc.astlinux-project.org/devdoc:documentation Special thanks to David Kerr for assisting in researching and testing, making the migration straightforward. AstLinux Team |
28 messages has been excluded from this view by a project administrator.
