gmane.linux.distributions.grml.user

Grml download size

treaki — 2013-05-07T21:07:25

Hi,

at first thanks for the good work. in my oppinion you offer the best
linux live cd. but i have one thing to inprove:

at your download site is written that the multiarch download size is
700MB. But infact that are  731MB to download. normaly its ok to round
such sizes but at this point it isnt. im sure you know why :)

so please correct this

greetings and keep up the good work

treaki

Re: odd console output

Frank Terbeck — 2013-05-02T08:22:56

[...]

This is what I hinted at on the zsh mailing list already.

Do *NOT* mess with $TERM unless you _know_ what you're doing is correct.

The linux console is not xterm. Xterm would also allow terminal title
setting, which the setup then tries. The correct $TERM for the linux
console is "linux".

Note that there are very few cases where setting TERM makes sense at
all. For example, most modern versions of xterm support both "xterm" and
"xterm-256color". Tmux supports "screen" and "screen-256color"...

But you cannot just TERM as you please. It has consequences for programs
running inside the terminal (such as zsh). If you'd set TERM to
"xterm-256color" for rxvt for example, you're asking for trouble and
things are going to break.

So, the short answer is: Don't mess with $TERM.


Regards, Frank

Re: odd console output

f gr — 2013-05-02T07:20:16

Frank Terbeck [2013-05-01T21:40+0200]:


Yes.


It's 'xterm-256color' (setting up within $HOME/.zshrc.local file)


Regards

Re: odd console output

Frank Terbeck — 2013-05-01T19:40:40


So, we're talking about the linux kernel's non-graphical (perhaps
framebuffer-based) terminal emulation?

What's the value of "$TERM" in your running shell session?


Regards, Frank

odd console output

f gr — 2013-05-01T14:46:05

Hello.
I use grml's zsh configuration on my distro.
If I run the system by runlevel 1 (or 3) and type the command ls, zsh
shows the following (as a normal user the same):

;root< at >hostname: ls [without any line breaks]

The odd thing is that when I run the shell by a terminal emulator (in
my case xfce4-terminal) the output is OK.

set nomail on zifumuur

odd console output

f gr — 2013-05-01T14:36:21

Hello.
If I run the system by runlevel 1 (or 3) and type the command ls, zsh
shows the following (as a normal user the same):

;root< at >hostname: ls [without any line breaks]

The odd thing is that when I run the shell by a terminal emulator (in
my case xfce4-terminal) the output is OK.

set authenticate zifumuur

set delivery off

Re: partition tables

Michael Prokop — 2013-04-22T10:08:57

Hi,

* Lupe Christoph [Sun Apr 21, 2013 at 12:13:29PM +0200]:


[...]
[...]



Google Translate says:

  "Hui 䡏 approved Wei d Zhen, ╛ Rong> hammer"

;)




Well, this is caused by isohybrid which we're running with the
"--uefi" option to get those hybrid ISOs.

So if you'd like to see this changed you'd have to bug isohybrid's
upstream (being the syslinux maintainers). But I'm not too
optimistic there exists a reliable way to change that since hybrid
ISOs (and therefore the isohybrid tool) are using quite some hacks
to work on all/most machines and that's what you're currently
seeing in the MBR of the ISOs. ;)


Yeah, that's actually the recommended way to get flexible systems. :)

regards,
-mika-

partition tables

Lupe Christoph — 2013-04-21T10:13:29

Hi!

I just wrote GRML 96 Full 2013.02 to a new USB stick and wanted to
adjust the partition table. But that wasn't valid (I'll demonstrate
using the ISO):

------------------------------------------------------------------------
$ fdisk -l /sw/archive/grml/grml96-full_2013.02.iso 

WARNING: GPT (GUID Partition Table) detected on '/sw/archive/grml/grml96-full_2013.02.iso'! The util fdisk doesn't support GPT. Use GNU Parted.

$ gdisk -l /sw/archive/grml/grml96-full_2013.02.iso 
GPT fdisk (gdisk) version 0.8.5

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: present

Found valid MBR and GPT. Which do you want to use?
 1 - MBR
 2 - GPT
 3 - Create blank GPT

Your answer: 1
Warning! Main partition table overlaps the first partition by 34 blocks!
You will need to delete this partition or resize it in another utility.

Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.
Disk /sw/archi

Re: RC: disable zshrc's share_history feature by default?

Darshaka Pathirana — 2013-03-31T14:43:12

Ack.


Maybe not. But it would remind /me/ (and maybe others) to change to the
prefered setting (whatever the default setting is going to be..)


Same as above. Whatever the setting is going to be, it would be
definitly nice if *grml* would provide a quick way to change the
default. Maybe something like: grml-zsh-share-history enable|disable
(Again, just thinking loud here..)


Ok. See below.


As I tried to say before. I think the "principle of least surprise"
heavily depends on what the user expects (even if all the "other"
shells do not have this default setting). We are talking about grml
users here (at least thats what I thought) and maybe they expect
something *grml* provides (since ages - since when actually?). But
obvioulsy you are not that kind of (grml) user. So there might be no
definite truth here.

As I did not see this discussion about convincing anyone what the
"best" setting is or should be and as you noted that this is not a
vote I do not think I can help anymore in finding the answer what

Re: RC: disable zshrc's share_history feature by default?

Gregor Perner — 2013-03-28T19:46:02




Frank Terbeck <ft< at >grml.org> schrieb:


This.

I agree with the principle of least surprise on the live-cd. But because I really like this feature in my environment I would appreciate it if it was easy to activate...

best regards
gregor

Re: RC: disable zshrc's share_history feature by default?

Frank Terbeck — 2013-03-28T19:31:46

[...]

I usually do different things in different shells. Hence that feature is
absolutely the worst for *me*. But this is not about personal preference.

[...]

This is not going to help.


I would rather change the default on the live-medium than use a
grml-quickconfig setting. Not because it's better but because the
quickconfig approach is not easily possible.


Again, this isn't a vote.

If you could make a convincing argument, that share_history indeed does
not violate the principle of least surprise, then that could make a
difference.  But I doubt you can. Because zsh is pretty much the only
shell that implements this. And even with zsh, it's *not* the default
setting.

After realising, that it does in fact violate said principle, you can
absolutely still like the feature. There is nothing wrong with liking
it. But enabling it, should be an conscious decision by *you* the user.
It should not be the default.


Regards, Frank

installing onto harddisc?

Dietmar Segbert — 2013-03-28T17:51:00

Hello

can i install the latest grml on to a harddisk?
I want to use grml on a dualbootsystem with windows8.

Is speakup, brltty and espeakup or speechdispatcher included in the latest  
grml-version and is there a switch swspeak or blrtty?

Regards.

Dietmar

Re: RC: disable zshrc's share_history feature by default?

Darshaka Pathirana — 2013-03-28T16:56:11

+1


Yeah. Two different defaults would be confusing.

That said, I also love that share_history feature!
I am not sure how you guys work but I usually remember my last command
(regardless which terminal I currently use). It often happens that I
get interrupted, switch away from (or even close) the terminal and
when trying to return find myself in a different terminal where I have
no access to my last command....

Or the other way around: I always "expected" to find my last command
across all terminals (long before I found grml default zsh
share_history feature). But as that did not happen I often found
myself issuing the wrong "last" command.

So the same potential "harm" (issuing the wrong "last" command) could
also arise without this setting enabled.

I am sure that there a few people who are annoyed by shared_history
but I am not sure if these people form a majority.

Thinking loud here:
* what about putting a note at the end of the boot process which
informs the user about that fact (if you really thin

Re: Persistence not working

Josh Lawrence — 2013-03-25T21:27:00

Evgeni - sorry for my very slow response.  I will test this within a
few days and write back.


I don't know what kind of persistence I'm using, I simply followed the
wiki's instructions here:

http://wiki.grml.org/doku.php?id=persistency

My persistence.conf looks exactly like the wiki's example.

grml2usb version is 0.13.4 installed on Debian Wheezy.

Is this helpful in any way?  I'll get the debug information to you
very soon.  Thank you again for your help!

Re: RC: disable zshrc's share_history feature by default?

Michael Prokop — 2013-03-25T10:39:45

* Csillag Tamas [Mon Mar 25, 2013 at 11:31:28AM +0100]:





Oh, right - that's another option.
But I'm afraid that people would be even more confused about the
inconsistency between the different environments.

regards,
-mika-

Re: RC: disable zshrc's share_history feature by default?

Csillag Tamas — 2013-03-25T10:31:28

... 

I try to explain a bit what I meant above:
Maybe it can make sense to enable this feature on a grml live system and
disable otherwise.

Regards, 
  cstamas

Re: RC: disable zshrc's share_history feature by default?

Michael Prokop — 2013-03-25T10:23:57

[Removing grml-devel from Cc]

* Csillag Tamas [Mon Mar 25, 2013 at 11:13:33AM +0100]:





If you have e.g. 'rm -rf $whatever' in one of your sessions and then
<enter><cursor-up> in another session then you might have 'rm -rf
$whatever' in your command line while expecting something different.
(Yeah, don't execute without reading what's there, but if you're
used to something different and fast working...)



Yeah, they will be "merged".


No, you won't lose any history information.



Yeah, but people use grml-zshrc also outside of Grml, even on
different operating systems. So we don't have to care just about the
Grml live mode use case but also about the more generic one. :)

Thanks for your feedback,
regards,
-mika-

Re: RC: disable zshrc's share_history feature by default?

Csillag Tamas — 2013-03-25T10:13:33

hi,

On Mon, Mar 25, 2013 at 10:47:40AM +0100, Michael Prokop wrote:

What is the potential harm?


What will happen then?

The histories will still get merged, but only at the end of the session?
If one or the other overwrites the history file I would vote against it.

On the other hand it is grml where I learned and got used to zsh and this was
one of its great features. :)

Maybe the grml distribution and users fetching grml's zsh config from grml.org/zsh
has a different use case (I am not sure) let me explain:
On a server there can be more root users operating in parallel
on a grml live system there is usually one and typing in one shell then the
capability to see that on the other's history is a great thing.

Regards,
  cstamas

RC: disable zshrc's share_history feature by default?

Michael Prokop — 2013-03-25T09:47:40

Hi,

Grml's zshrc [http://grml.org/zsh/] uses 'setopt share_history' by
default since ages.

This option is responsible for making the history of one Zsh session
available to others "kind-of-immediately". So when sending 'echo
foobar' in one terminal, then pressing e.g. <return> in another zsh
session of the same user then cursor up will show 'echo foobar' on
the command line.

While I personally like the feature and somewhat got used to it it's
also one of the most discussed settings of grml-zshrc. It has the
potential to do harm, especially if you aren't aware of that
feature.

This is why I'd like to disable this setting by default (but provide
it as commented feature so it's trivial to just enable it on
request). Of course you will be able to just customize it via e.g.
.zshrc.local, it's really just about the default behaviour.

Any objections against that switch? Happy to hear your {N,}ACKs. :)

regards,
-mika-

Re: Persistence not working

Evgeni Golov — 2013-03-16T13:47:47

Hi Josh,

On Thu, Mar 14, 2013 at 04:57:18PM -0500, Josh Lawrence wrote:


Sounds sane so far. Can you boot with debug=1 and provide the log file 
from /var/log/live/boot.log?


Expected, it tries too hard to mount sometimes :)


Mhh...


What kind of persistence are you using? bind? union? link?
Can you post your persistence.conf please.

What version of grml2usb are you using? The 0.12.2 from wheezy?

Greets
Evgeni

Persistence not working

Josh Lawrence — 2013-03-14T21:57:18

Hello all,

I cannot get persistency to work with grml 2013.02.  I'm creating a
live USB stick using grml2usb installed on my Debian Wheezy machine.
Per the wiki, I create a 700 MB fat16 partition for grml and give the
remaining space as an ext3 partition labeled "persistence".  On the
persistence partition is persistence.conf setup per the wiki.  I
execute grml2usb either with --bootoptions="persistence" or by
choosing persistence from the menu at boot (same result).  When
booting, here's what I see on the screen:

    mount:  mounting /dev/sda on /root/lib/live/mount/persistence/sda
failed:  No such device
    [...snip...scans sdb sdc]

later I get:

    mounting /live/medium on /root/lib/live/mount/medium failed:
Invalid argument

and later:

    Mount point '/root/lib/live/mount/persistence/sdb1' does not
exist.  Skipping mount ...

Am I doing something wrong somewhere in this process?  If not, is
there a work-around that I can use?

Thank you!

Josh