On 5/29/2014 5:33 PM, David Brown wrote:
> I was trying to encourage thinking rather than giving
> direct answers, but I worded it very badly.  Sometimes it is easy to do
> that on Usenet, without noticing how your posts come across -

Yes, it is easy to make a post that doesn't sound to others like it did 
to yourself when writing it.  I understand and have made the same 
mistake myself any number of times.  Maybe that is why I spotted it so 
easily, lol


> thank you
> for point it out to me.  And I hope my later post gave Edward some help
> or ideas.

I hope so too.

-- 

Rick

On Thursday, May 29, 2014 2:33:15 PM UTC-7, David Brown wrote:
> On 29/05/14 19:19, rickman wrote:

> > Another reply that should have been in your earlier post.
 
> > I'm not trying to give you a hard time.  I'm just trying to point out
> > how your original post came across.
 
> You (and Edward) are right - I was rude in my post, without any 
> justification.  I was trying to encourage thinking rather than giving 
> direct answers, but I worded it very badly.  Sometimes it is easy to do 
> that on Usenet, without noticing how your posts come across - thank you 
> for point it out to me.  And I hope my later post gave Edward some help 
> or ideas.

OK, thanks.  I think i have a workaround for the moment.  The problem is that mountall and network-manager are both talking to the plymount dbus daemon.  I can't find the exact version of dbus to match the existing distribution (linuxmint 15).  I tried dbus-1.6.8 (for mint 15) and dbus-1.6.18 (for mint 17).  When i install either version of dbus, network-manager went crazy with 99% CPU time. So, i just install a new mountall without installing dbus.  Mountall probably went crazy for a short time, but all is well when it's done.  However, network-manager need to run all the time.

The new mountall does not check the root drive like the old one.  The old mountall was saying: "my current disk drive is not ready" or like "The ground i am walking on does not exist."

On 29/05/14 19:19, rickman wrote:

> Another reply that should have been in your earlier post.
>
> I'm not trying to give you a hard time.  I'm just trying to point out
> how your original post came across.
>

You (and Edward) are right - I was rude in my post, without any 
justification.  I was trying to encourage thinking rather than giving 
direct answers, but I worded it very badly.  Sometimes it is easy to do 
that on Usenet, without noticing how your posts come across - thank you 
for point it out to me.  And I hope my later post gave Edward some help 
or ideas.

On 5/29/2014 9:52 AM, David Brown wrote:
> On 28/05/14 19:56, edward.ming.lee@gmail.com wrote:
>>> I have no idea why you are having trouble doing something millions of
>>> other people have managed fine,
>>
>> I don't know why you are always so negative.
>>
>
> I am not trying to be negative - sorry if I sound that way.  (My recent
> posts in another couple of threads, from the same OP, have been worded
> rather negatively - they are based on substantial threads on other
> newsgroups, and I really do think that the OP there should be
> discouraged from his current plans.)  If I give negative comments or
> criticism, it is with the best of intentions.

It is not what you said, but how you said it.  I was going to post a 
response to your first post too but decided to read a bit before I did. 
  So now you have been informed that your post came off as a bit 
"negative".  I would even say it was rude.  Not so much because of what 
you are trying to say, but how you said it.  I think the above quote 
(the first one) sets a rude tone for the entire rest of the post.


>>> why you think kernel 3.6 is "new",
>>
>> I don't know of any stable version newer than 3.6.18
>
> For many purposes, any recent kernel, including 3.6, is likely to be
> good enough.  But the current release is 3.14.4, and I believe the
> latest with long-term support is 3.12.

Isn't that much more informative than saying you don't know 'why you 
think kernel 3.6 is "new"'?


>>> why you are posting to a Usenet group for embedded systems,
>>
>> My target is an embedded system, probably the Intel Minnow Max board
>> when it is ready.
>
> c.a.e. is mainly targeted at smaller embedded systems, with a discussion
> of hardware, software and other aspects of such systems.  Embedded Linux
> systems are, obviously, "embedded" - but they are at the limit of the
> areas of interest for this group and don't come up often.  For the most
> part, when you are using an off-the-shelf x86 based board for Linux, you
> will get best results by viewing it as a normal PC - particularly when
> you are talking about booting from a USB stick.
>
> There is also the group comp.os.linux.embedded, which might be a good
> place to look.

Again, much more helpful than, "why you are posting to a Usenet group 
for embedded systems".


>>> or why you think LILO is a good choice of bootloader in the 21st
>>> century.
>>
>> LILO is simple and good enough for me.  I don't need fancy boot options.
>
> If you had got everything booting correctly, that might be fair enough.
>   But LILO is an old bootloader - grub is much more popular and has a
> lot more features and flexibility.  When you are trying to get things
> working on a newer card, it makes sense to use the tools everyone else
> uses.  (On embedded Linux systems, especially non-x86 cards, the other
> popular choice is uboot.)

Ditto, a much better reply than your opener.


>>> I suspect you
>>> have a little knowledge of Linux from long ago, and are making things
>>> far more complicated for yourself as a result.
>>
>> True.
>
> The trouble with this is that things change - and they can change quite
> rapidly in the Linux world.  Techniques that worked well a few years ago
> can be outdated now - and sometimes you need to change to get things
> working with the latest hardware and the latest software.  I know that I
> suffer from this - and I recognize it in others.  There are times when
> the best solution is, as I said, to pretend you know nothing and do
> things the modern newbie way until you see how it fits together.

Another reply that should have been in your earlier post.

I'm not trying to give you a hard time.  I'm just trying to point out 
how your original post came across.

-- 

Rick

> For many purposes, any recent kernel, including 3.6, is likely to be 
> good enough.  But the current release is 3.14.4, and I believe the 
> latest with long-term support is 3.12.

My mistake. I am using 3.13.  Will try 3.14.

> >> why you are posting to a Usenet group for embedded systems,
 
> > My target is an embedded system, probably the Intel Minnow Max board when it is ready.
 
> c.a.e. is mainly targeted at smaller embedded systems, with a discussion 
> of hardware, software and other aspects of such systems.  Embedded Linux 
> systems are, obviously, "embedded" - but they are at the limit of the 
> areas of interest for this group 

I believe it's a hardware issue, the difference between SATA and USB MSD, and a software bug for reporting boot drive not ready.  It works on SATA, but obviously does not work on USB.  The desktop version Redhat, Ubuntu, Mint) are all geared for UI, which is not what i want for embedded board. The Dbus, NIH, plymouth, etc are tying everything together, including boot modules and network manager.  It is a nightmare maintenance issue.  I am trying to build a simpler system, at the expense of flexibility.

I can fix/patch mountall by not checking the boot drive.  It is ridiculous to report the drive containing the running program "not ready" anyway.  However, the way "modern Linux" are setup.  I have to compile the whole system to change one line.

I will likely separate and/or remove the linkage between booting and other system managers. 

On 28/05/14 19:56, edward.ming.lee@gmail.com wrote:
>> I have no idea why you are having trouble doing something millions of
>> other people have managed fine,
>
> I don't know why you are always so negative.
>

I am not trying to be negative - sorry if I sound that way.  (My recent 
posts in another couple of threads, from the same OP, have been worded 
rather negatively - they are based on substantial threads on other 
newsgroups, and I really do think that the OP there should be 
discouraged from his current plans.)  If I give negative comments or 
criticism, it is with the best of intentions.

>> why you think kernel 3.6 is "new",
>
> I don't know of any stable version newer than 3.6.18

For many purposes, any recent kernel, including 3.6, is likely to be 
good enough.  But the current release is 3.14.4, and I believe the 
latest with long-term support is 3.12.

>
>> why you are posting to a Usenet group for embedded systems,
>
> My target is an embedded system, probably the Intel Minnow Max board when it is ready.

c.a.e. is mainly targeted at smaller embedded systems, with a discussion 
of hardware, software and other aspects of such systems.  Embedded Linux 
systems are, obviously, "embedded" - but they are at the limit of the 
areas of interest for this group and don't come up often.  For the most 
part, when you are using an off-the-shelf x86 based board for Linux, you 
will get best results by viewing it as a normal PC - particularly when 
you are talking about booting from a USB stick.

There is also the group comp.os.linux.embedded, which might be a good 
place to look.

>
>> or why you think LILO is a good choice of bootloader in the 21st century.
>
> LILO is simple and good enough for me.  I don't need fancy boot options.

If you had got everything booting correctly, that might be fair enough. 
  But LILO is an old bootloader - grub is much more popular and has a 
lot more features and flexibility.  When you are trying to get things 
working on a newer card, it makes sense to use the tools everyone else 
uses.  (On embedded Linux systems, especially non-x86 cards, the other 
popular choice is uboot.)

>
>> I suspect you
>> have a little knowledge of Linux from long ago, and are making things
>> far more complicated for yourself as a result.
>
> True.

The trouble with this is that things change - and they can change quite 
rapidly in the Linux world.  Techniques that worked well a few years ago 
can be outdated now - and sometimes you need to change to get things 
working with the latest hardware and the latest software.  I know that I 
suffer from this - and I recognize it in others.  There are times when 
the best solution is, as I said, to pretend you know nothing and do 
things the modern newbie way until you see how it fits together.

>
>> Pretend you know nothing about Linux and consider yourself a complete
>> newbie.  As "the web" how you make a live bootable USB stick with a
>> modern easy-to-use Linux distribution.  My recommendation is Linux Mint
>> - you can try the latest release candidate of version 17 from
>> <http://www.linuxmint.com/>.  The downloaded iso files can be put
>> directly on a USB or a DVD - see
>
> I have my base system from linuxmint version 15 and all the update modules are equivalent to version 17.
>

> If this is failing to mount the drive because it isn't alive yet (some USB
> sticks take a while to warm up) you can say rootdelay=30 on the kernel
> command line to give it 30s to come alive.  rootwait will wait indefinitely.

I replace the "mountall" command with a script, calling:

df
mountall.exe (was mountall)

"df" shows the root drive properly.  The fact that this script is running shows that the drive is alive and well.  But mountall.exe stills say it's not ready.

edward.ming.lee@gmail.com wrote:
> Trying to build a USB bootable drive with Wifi and GSM. One of the Wifi
> driver is in the newer kernel only (3.6).  However, during boot, Linux
> complaints about "boot drive not ready", "press a key to wait, skip or
> manual" to continue.  The problem is in "mountall", but a "df" before
> "mountall" shows that the boot drive is alive and well.  So, the USB
> subsystem is not reporting something correctly to "mountall".

If this is failing to mount the drive because it isn't alive yet (some USB
sticks take a while to warm up) you can say rootdelay=30 on the kernel
command line to give it 30s to come alive.  rootwait will wait indefinitely.

If it's further down the boot process (ie not the root device) you can add
nobootwait as a mount option is /etc/fstab so it won't stall waiting for
something to mount that isn't there.

It could be you have a race: boot stalls because the root hasn't mounted,
then the root mounts will sitting at the 'press to wait' prompt.  One or
other of these might help it.

Theo

> > why you think kernel 3.6 is "new", 
 
> I don't know of any stable version newer than 3.6.18

Sorry, i meant 3.13.6

>  As "the web" how you make a live bootable USB stick with a 
> > modern easy-to-use Linux distribution.  

I tried making USB key from LinuxMint 15 DVD before, it lockup during installation process.  I don't have the external DVD drive to try newer version.

> I have no idea why you are having trouble doing something millions of 
> other people have managed fine, 

I don't know why you are always so negative.

> why you think kernel 3.6 is "new", 

I don't know of any stable version newer than 3.6.18

> why you are posting to a Usenet group for embedded systems, 

My target is an embedded system, probably the Intel Minnow Max board when it is ready.

> or why you think LILO is a good choice of bootloader in the 21st century.  

LILO is simple and good enough for me.  I don't need fancy boot options.

> I suspect you 
> have a little knowledge of Linux from long ago, and are making things 
> far more complicated for yourself as a result.

True.

> Pretend you know nothing about Linux and consider yourself a complete 
> newbie.  As "the web" how you make a live bootable USB stick with a 
> modern easy-to-use Linux distribution.  My recommendation is Linux Mint 
> - you can try the latest release candidate of version 17 from 
> <http://www.linuxmint.com/>.  The downloaded iso files can be put 
> directly on a USB or a DVD - see 

I have my base system from linuxmint version 15 and all the update modules are equivalent to version 17.