Hi,
Marco Amadori wrote (25 Jan 2010 07:41:23 GMT) :
> In data domenica 24 gennaio 2010 22:53:58, Sebastian Ortwein ha scritto:
>> > Features
>> a feature which will save only selected files permanently on net, local.
>> e.g., so you can easy build mediacenter images
>> the files can be saved on
Hi,
Daniel Baumann wrote (11 May 2010 16:34:37 GMT) :
> On 05/10/2010 10:11 PM, intrigeri wrote:
>> Are there any plans for the persistency redo?
> nice. if you're not so much in a hurry and can wait until mid july
> when i'm finished with the basic re-implementation of live-initramfs
> (core fe
On 05/10/2010 10:11 PM, intrigeri wrote:
> Are there any plans for the persistency redo?
not yet. there is a strange bug in current git (debian-next branch),
introduced by de4c25fd53eab811eebfd1c7194226bf96e45dd1 that leads to no
autologin (the debconf thing does , once that's fixed, i can start w
Hi,
Daniel Baumann wrote (25 Jan 2010 19:19:12 GMT) :
> Philippe Lelédy wrote:
>> 2) persistent=home to bypass global persistence.
> persistency needs to be redone, this is one of the reasons to do
> exactely. had that already in mind :)
Are there any plans for the persistency redo?
We have pl
2010/1/29 Philippe Lelédy :
> Daniel Baumann wrote:
>>
>> Hi,
>>
>> I'd like to gather a list of features (not their
>> implementation!, that's a step later) that you need/want/like/use/miss
>> from live-initramfs.
>
> Usage Clarification: because there may be contradictory wishes for
> different
Daniel Baumann wrote:
Hi,
I'd like to gather a list of features (not their
implementation!, that's a step later) that you need/want/like/use/miss
from live-initramfs.
Usage Clarification: because there may be contradictory wishes for
different goal.
Something like
lh config --usage=mobile
On 2010-01-19 Daniel Baumann wrote:
> Features
>
> *
> * Redo login manager support (kdm, gdm, nodm, plain startx on tty1)
Can there also be an option to not do autologin, but show username/password
combo on the login page
(or sth like that)?
For (at least) KDE that would eliminate
Daniel Baumann wrote:
As a first step, I'd like to gather a list of features (not their
implementation!,
- Timestamps in /var/log/debug.log (much more an initramfs-tools issue
than a live-initramfs issue !)
Discussion:
I use this patch in /usr/share/initramfs-tools/scripts/functions:
_log_
Daniel Baumann wrote:
Philippe Lelédy wrote:
Daniel Baumann wrote:
Philippe Lelédy wrote:
1) It would be nice to specify that internal disks are not to be used at
all, even read/only:
currently, if you don't enable swap nor persistency, internal disks
arenot use
Philippe Lelédy wrote:
> Daniel Baumann wrote:
>> Philippe Lelédy wrote:
>>
>>> 1) It would be nice to specify that internal disks are not to be used at
>>> all, even read/only:
>>>
>>
>> currently, if you don't enable swap nor persistency, internal disks
>> arenot used, except for searching
Daniel Baumann wrote:
Philippe Lelédy wrote:
1) It would be nice to specify that internal disks are not to be used at
all, even read/only:
currently, if you don't enable swap nor persistency, internal disks
arenot used, except for searching the live-media.
And persistent partitions
Philippe Lelédy wrote:
> 1) It would be nice to specify that internal disks are not to be used at
> all, even read/only:
currently, if you don't enable swap nor persistency, internal disks
arenot used, except for searching the live-media.
when we rework the searching procedures, we can make that
Philippe Lelédy wrote:
> Not easy !
indeed. :)
> For now, I am using the aufs and live-initramfs feature that allows many
> stacked filesystems R/O.
> So little updates are easy to download (my main filesystem.squashfs is
> 1.3 M !).
> But it's all manual work. Having software in little independe
Daniel Baumann wrote:
Philippe Lelédy wrote:
3) I would like to make frequent updates to all these keys I spread. An
rsync at live-initramfs time would be nice. Stacking of little .squashfs
files in live directory is enough for me to distribute small updates. I
yet use these features but it n
1) It would be nice to specify that internal disks are not to be used at
all, even read/only:
hdparm -Y /dev/sda gives you silence.
2) [issues related to initramfs-tools]
2.1) break=all would be useful to debug initramfs. Currently you can
only have *one* breakpoint.
2.2) When at a break po
* intrigeri wrote:
> Michael Prokop wrote (24 Jan 2010 12:50:50 GMT) :
>> But if you're working in IT forensics and/or have special security
>> requirements this won't be enough. Someone could prepare a device
>> that fullfills the uuid requirements but provides a hacked
>> filesystem which does
Hello,
Michael Prokop wrote (24 Jan 2010 12:50:50 GMT) :
> But if you're working in IT forensics and/or have special security
> requirements this won't be enough. Someone could prepare a device
> that fullfills the uuid requirements but provides a hacked
> filesystem which does "something you defi
Michael Prokop wrote:
>> what do you understand under 'display executed code', something like
>> what you'd see from set -x?
>
> Jepp. This would allow users to debug initramfs (and provide
> screenshots/logs to developers) without having to rebuild it
> manually (which sometimes just isn't possib
Philippe Lelédy wrote:
> liveUSB distributors know exactly where their stuff is,
> and it would be nice it it was possible to by-pass all the search.
this has been already mentioned, and will be implemented at some point.
> 2) persistent=home to bypass global persistence.
persistency needs to be
1) For LiveUSB distributors.
I make up Live USB for my students with home persistency. All these
Live USBs have essentially the same layout: home-rw on /dev/sdb2 and
filesystem.squashfs on /dev/sdb3. I would like something like these
cheatcodes
force-filesystem=/dev/sdb3 force-home-rw=/dev/
In data domenica 24 gennaio 2010 22:53:58, Sebastian Ortwein ha scritto:
> > Features
> a feature which will save only selected files permanently on net, local.
> e.g., so you can easy build mediacenter images
> the files can be saved on shutdown and loaded on boot
This is the actual /etc/live-s
Daniel Baumann schrieb:
Hi,
over the time, the current live-initramfs has shown that new features
cannot be added without ugly hacks and that it needs to be rewritten in
a more modern, modular way.
As a first step, I'd like to gather a list of features (not their
implementation!, that's a step
* Daniel Baumann wrote:
> Michael Prokop wrote:
>> * Provide a bootoption which displays the currently executed code.
>> This avoids panic on user's side if something takes longer than
>> usual, so let’s inform the user instead.
> what do you understand under 'display executed code', somethi
Hi,
I've summed up all the messages from the previous thread and sorted the
list by priority: http://live.debian.net/devel/live-initramfs/features
More feedback is of course welcome. In the beginning of the next week,
I'll post some notes about starting the implementation.
Regards,
Daniel
--
A
Michal Suchanek wrote:
> I was just wondering what would happen when you boot 100 d-ls that use
> the same network persistency location.
fedora afaik supports that, i'm really not sure about that, but i think
i remember that they do it by appending the mac to the name of the share
to avoid that pr
to...@tuxteam.de wrote:
> (and how cool would be an rsyncrypto, where you can have your
> persistency on an untrusted server?)
indeed, added to the list.
--
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email: daniel.baum...@panthera-systems.net
Internet: ht
Tom Deblauwe wrote:
> - You should be able to boot a live system and it should be able to
> mount certain partitions that it reads from some config file in the
> binary filesystem.
that live-initramfs mounts certain partitions automatically means, that
/etc/fstab needs to have a configuration mech
On 19/01/2010 17:09, Daniel Baumann wrote:
As a first step, I'd like to gather a list of features (not their
implementation!, that's a step later) that you need/want/like/use/miss
from live-initramfs.
Here are the things I was thinking about:
- You should be able to boot a live system and it s
Michael Prokop wrote:
> Addon: the network configuration should be made more flexible and
> robust. I've been working on this recently, see:
> http://grml.supersized.org/archives/337-More-robust-network-booting.html
thanks for the pointer, for me it's about implementation, so i'll take
it up in th
* Daniel Baumann wrote:
[...]
> As a first step, I'd like to gather a list of features (not their
> implementation!, that's a step later) that you need/want/like/use/miss
> from live-initramfs. So please also list things that the current
> live-initramfs does. If possible, please send in your lis
2010/1/20 Daniel Baumann :
> Michal Suchanek wrote:
>>> Hi,
>
> Hi,
>
> as implied in the mail, some things are more important than others. this
> was a list without priorities, so e.g. while booting over iscsi is
> certainly nice to have, it will not happen that fast as other things are
> more imp
On Wed, Jan 20, 2010 at 05:08:44AM +0100, Daniel Baumann wrote:
> Michal Suchanek wrote:
> > Also consider the security of the vmlinux/initramfs. Is adding more
> > security later really useful?
>
> if you can't trust the kernel and initrd, you're almost lost anyway.
While not a personal interes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Jan 20, 2010 at 05:08:44AM +0100, Daniel Baumann wrote:
> Michal Suchanek wrote:
[...]
> > I don't think rsync or ftp is utterly useful - AFAIK they are wget
> > equivalent (which still has its uses, especially with the cheap RAM
> > these da
Marco Amadori wrote:
>> it needs to be rewritten in a more modern, modular way.
>
> Not also changing language from shell to python/perl/C, right ? :-)
i guess you didn't mean it dead serious, but since otavio brought it up
yesterday too..
stuff in the initrd needs to be best written in a langua
Michal Suchanek wrote:
>> Hi,
Hi,
as implied in the mail, some things are more important than others. this
was a list without priorities, so e.g. while booting over iscsi is
certainly nice to have, it will not happen that fast as other things are
more important. however, it's good to keep it in m
On Tuesday 19 January 2010 23:39:44 Daniel Baumann wrote:
> Hi,
>
> over the time, the current live-initramfs has shown that new features
> cannot be added without ugly hacks and that it needs to be rewritten in
> a more modern, modular way.
Not also changing language from shell to python/perl/C,
2010/1/19 Daniel Baumann :
> Hi,
>
> over the time, the current live-initramfs has shown that new features
> cannot be added without ugly hacks and that it needs to be rewritten in
> a more modern, modular way.
>
> As a first step, I'd like to gather a list of features (not their
> implementation!,
Hi,
over the time, the current live-initramfs has shown that new features
cannot be added without ugly hacks and that it needs to be rewritten in
a more modern, modular way.
As a first step, I'd like to gather a list of features (not their
implementation!, that's a step later) that you need/want/
38 matches
Mail list logo
