Re: [cooking] various boot modes, successes and failures

[Indigo <pointofavailability@xxxxxxxxx>]

Pascal and Rohit, thank you - I will work with the new iso starting
today.  Don't worry about laziness.  I am the most unproductive person
I know.  And I am happy to help with testing.  While I have not
learned enough to start coding, not a developer or package maintainer,
I have been bug testing this distro for more than a year and offer
what support I can on IRC.  And I have learned a lot from Slitaz!

I do understand I am working with a testing level iso - my complaint
was because we see the same questions all the time in IRC.  The first
season I was here, it was 'how do I install flash?' because
libflashplayer.so wasn't getting copied correctly.  For this cooking
version, there have been a lot of problems with wifi drivers and
netbooks.  And for as long as I can remember, there have been problems
with xorg.  It doesn't help that companies keep making new proprietary
hardware...

As for xorg, I don't think the problem is related to groups or
permissions.  While xorg is undergoing changes (which also doesn't
help), the issue has to do with hardware recognition.  It seems xorg
is unable to query the display for the proper refresh rates and falls
back to default values which are out of range for many screens.  So,
it gets stuck in 800x600, even after installing a new driver with
tazx, unless the proper modeline is added manually.  Also, tazx (last
I checked) still says the file xorg.conf.new has been written to
/root, but this is no longer the case.

As of a recent version of xorg, not only has the structure of config
files changed, it now depends on udev -- and udev fails on boot in an
installed system.  The issue is that udev is getting started while the
filesystem is still mounted read-only, so it's unable to create a
cache file.  After bootup, it seems to be running, but everytime a
process tries to use it, it respawns and leaves an error that it's
already running (log level debug)... I don't know for sure, but I
suspect fixing this might solve the xorg problem.

I am working on fixing this today, but any ideas are appreciated.
Other distros use devtmpfs, which has now been compiled into the
slitaz kernel, but will require changes in /etc/init.d - another idea
is to start udev after the filesystem has been remounted read-write,
but I'm not sure if that will work.  I will let you know if I find a
solution.

As for documentation, not much needs to be done - there is a lot of
information online, but some of it is outdated, and I have learned
about quite a few options from reading through the scripts, things
that I never noticed in the documentation.  For the most part, the
docs just need to be cleaned up a little, but they're still better
than most of the distros out there.

I look forward to the future of Slitaz.  It is a very different kind
of linux, perfect for virtual machines, running live, or for old
hardware.  It's real value, though, is in it's flexibility.  I am
thrilled with tazpkg's new ability to convert packages made for other
distros, and happy to see it gaining international language support.
I can't wait to see a hundred different flavors and the further
development of slitaz-pizza...

But enough for now - I am known for being long winded.  Thank you
again for such a quick response to my complaints.  (I am also known
for being moody.)  I certainly will test this new iso and will
continue to help however I can.  As 3.0 was a tremendous improvement
over 2.0, I can't wait to see the next stable release.

------ Indigo


On Thu, Dec 23, 2010 at 4:22 AM,  <pascal.bellard@xxxxxxxxxx> wrote:
> Hi,
>
> I have tagged slitaz-tools, slitaz-boot-scripts and tazlito, and updated
> undigest ISO. http://mirror.slitaz.org/iso/undigest/
> Would you mind test it ?
>
> -pascal
>
>> Hi Indigo,
>>
>> It seems the latest version of the slitaz-tools (
>> http://hg.slitaz.org/slitaz-tools/) has not been tagged and rolled out
>> yet.
>> Yes, we are lazy! :-) . Typically, we tag it when there are enough changes
>> made for the new rollout. So, I guess the login problem still exist in
>> core.iso and multiple user fix still needs to be tested.
>>
>> I have missed mails and posts on udev/xorg, so I am not aware of the
>> issues
>> but I feel most likely the problem should be related to "permissions" and
>> "groups" to multiple users. So, the correct assignment of a user to a
>> group
>> should fix those issue.
>>
>> You are right that we need a good testing team. Many of the bugs can be
>> easily fixed. Moreover, we need to improve the documentation a lot. This
>> require a lot of effort and motivation. We are always looking for
>> community
>> to help and improve.
>>
>> Rohit
>>
>> On Wed, Dec 22, 2010 at 12:53 PM, Indigo
>> <pointofavailability@xxxxxxxxx>wrote:
>>
>>> I've just tested the core.iso in from the undigest repo -- and it
>>> still doesn't work after install.
>>> This is the same problem as before, the config files being copied to
>>> /home, instead of /home/$USER --
>>> and with the same chown errors.  Looking at tazx, it seems the cause
>>> is the same, the line:
>>>     USER=`cat /etc/passwd | grep 1000 | cut -d ":" -f 1`
>>> Gokhlayeh suggests a wrapper for adduser, which makes sense in many
>>> ways, as both tazx and tazctrl box have to be run,
>>> otherwise -- but using the iso to upgrade a system with a persistent
>>> home, or just using tazx, still needs to handle multiple users.
>>>
>>> Although Slitaz is a wonderful LiveCD, it's also good as a VM or on
>>> old machines --
>>> and just about all of the problems I see on IRC are on installed images..
>>> Please, let's also test the isos installed before releasing...
>>>
>>> Also, udev/xorg still have problems - fixing this should be a priority
>>> before the next stable release.
>>> I will work on trying to get udev to not fail on an installed version
>>> and, hopefully, this will fix the xorg issue.
>>>
>>>
>>> On Wed, Dec 22, 2010 at 8:09 AM, Christopher Rogers
>>> <slaxemulator@xxxxxxxxx> wrote:
>>> > The squashfs+xz is not build into kernel. Its build as a module. Need
>>> to
>>> > install linux-squashfs to use it.
>>> >
>>> > Also i was the one to add the patches to the kernel. I have even
>>> tested
>>> with
>>> > my own version of a livecd. So i know its there.
>>> >
>>> > 2010/12/22 Philippe Lelédy <slitaz@xxxxxxxxx>
>>> >>
>>> >> Thanks for this good news.
>>> >>
>>> >> On 21/12/2010 16:58, pascal.bellard@xxxxxxxxxx wrote:
>>> >>>>
>>> >>>> the 2 LORAMs cooking from the mirror: the kernel crashes. I was
>>> unable
>>> >>>> to rebuild (tazlito build-loram) because now kernel is 2.6.36 and
>>> >>>> cooking from the mirror is 2.6.34, and linux-aufs is no more
>>> available
>>> >>>> for 2.6.34.
>>> >>>> Solution: squashfs in 2.6.36 doesn't support LZMA compression, so
>>> patch
>>> >>>> tazlito.
>>> >>>
>>> >>> Tazlito has not been release in wok. Coming soon.
>>> >>>
>>> >>> linux-aufs has been renamed to aufs
>>> >>> http://hg.slitaz.org/tazlito/rev/233dc896fb14
>>> >>>
>>> >>> It support xz compression :
>>> >>> http://hg.slitaz.org/tazlito/rev/0c75c957b322
>>> >>>
>>> >>> xz is supported by squashfs :
>>> >>> http://hg.slitaz.org/wok/rev/1bea914df3b9
>>> >>
>>> >> Add squashfs+xz to kernel ...
>>> >> Which kernel ?
>>> >> Linux slitaz 2.6.36-slitaz #2 SMP Fri Dec 17 06:45:50 CST 2010 i686
>>> >> GNU/Linux
>>> >> doesn't seem to have this feature
>>> >>>
>>> >>> http://hg.slitaz.org/wok/rev/13e4d4e6fcc1
>>> >>>
>>> >>> loram flavor use xz compression too :
>>> >>> http://hg.slitaz.org/wok/rev/0a217ca53bab
>>> >>>
>>> >>> -pascal
>>> >>>
>>> >>>
>>> >>> ---
>>> >>> SliTaz GNU/Linux Mailing list - http://www.slitaz.org/
>>> >>>
>>> >>
>>> >>
>>> >> ---
>>> >> SliTaz GNU/Linux Mailing list - http://www.slitaz.org/
>>> >>
>>> >
>>> >
>>>
>>> ---
>>> SliTaz GNU/Linux Mailing list - http://www.slitaz.org/
>>>
>>>
>>
>
>
>
> ---
> SliTaz GNU/Linux Mailing list - http://www.slitaz.org/
>
>

---
SliTaz GNU/Linux Mailing list - http://www.slitaz.org/