how I'm using debian-live
Hello, thank you so much for working on debian-live. It's vastly improved my release process, now that I have it set up. In case you're curious, I've written a document describing the process I used. It is available at http://www.electricowlstudios.com/EOwl-live-debian.html . There are links at the top to .doc and .pdf format, which I find much easier to read than the dump from Open Office to html. The parts which might interest you are sections 4.2.4 where I do some fairly ugly hacking to dexconf in order to modify xorg.conf, and section 4.2.6, which covers sound; whatever ALSA was doing by default on boot wasn't enough to find and use my motherboard's on-board sound. (Intel 810 chipset, as I recall.) Thanks again, -PL- ___ debian-live-devel mailing list debian-live-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
Re: /sys/class/misc/snapshot/dev doesn't exist.
Mohsen Pahlevanzadeh wrote: Unfortunately, while installation procedure, I receive following error: cat /sys/class/misc/snapshot/dev : no such file or directory Is it because you don't have /sys mounted? Are you building a sid cd? On what kernel? With what host suite? Justin ___ debian-live-devel mailing list debian-live-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
Re: how I'm using debian-live
On Fri, Oct 05, 2007 at 01:17:44AM -0400, Phil Light wrote:
Hello, thank you so much for working on debian-live. It's vastly
improved my release process, now that I have it set up.
Hi Phil,
I had some comments.
You say to use visudo but then to remove the .tmp extension.
Actually you should *not* remove the .tmp. I'm fairly certain that
what's happens is:
lock /etc/sudoers
copies sudoers to sudoers.tmp
/usr/bin/editor /etc/sudoers.tmp
ret=0
diff /etc/sudoers /etc/sudoers.tmp || ret=$?
case $ret in
0) echo Not changed 2 exit 0;;
1) exec mv /etc/sudoers.tmp /etc/sudoers;;
*) exit 1; # error
esac
The important thing here is that mv is guaranteed to be atomic (if
it succeeds fail) when the dst file is on the same filesystem as the
src, which is guaranteed to be true when they're in the same directory
(or a subdirectory created by the process without mounts).
OTOH if the editor saves to sudoers, it's likely to do just
open(); for(;;){write()}; close(); which means that during some
interval there's an incomplete sudoers file. In the case of sudoers,
it's a security thing even, since the incomplete file can have valid
syntax. In particular if there's an incomplete command specified (ls
is written but it's supposed to be lspci) or a command whose arguments
haven't been written yet (which means any arguments are to be allowed)
or a command with [^ ]* argument (which means extra args are allowed
to eg. passwd).
You said that sudo was subly different from su but the critical thing
is that all your user ID's (IIRC: EUID, RUID, FSUID, SSUID) are set to
0 which happens for both. The differences that I can think of:
sudo sets some environment variables (like SUDO_USER)
su waits for the shell to exit instead of just doing exec(/bin/sh)
so that it can write an pam_end() entry.
normal sudo things: it logs commands, doesn't require disclosing the
root pw, allows multiple commands to be run without starting an
interactive root shell, but times out after a matter of 10 minutes
(Debian changes the default)
You did mv etc/init.d/bittorent graveyard/ but update-rc.d says that
this should be something more elaborate. Either update-rc.d remove,
then stop, or something like:
for s in $srv_disable
do
for f in etc/rc?.d/S[0-9][0-9]$s
do
[ -f $f ] || continue
dir=${f%/*}
mv $f $dir etc/rc$g.d/K$s
done
done
You suggested apt-get remove and dpkg --purge. There's also aptitude
purge and apt-get --purge remove as well as aptitude [install|remove]
foo_ (foo- means remove, foo_ means purge). There *was* a bug in
aptitude which prevented it from purging a package which was removed
(in state config-files) but I think this might have been fixed, but I
also can't find the bug.
Justin
___
debian-live-devel mailing list
debian-live-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
Re: Hero wanted. Apply within. Make persistence work.
Alle venerdì 5 ottobre 2007, Ben Armstrong ha scritto: Here's the state of persistence, to the best of my knowledge: Last time I checked just invoking live-snapshot produce a wotking cpio.gz archive that will be added at boot time if placed in the right place. I know and I always told that other targets were unfinished/untested and asked for help when I saw that my time for d-l coding were fading out. The live-snapshot script is not rocket science and a fix should be not a so hard task, the thing it need most is a good .ignore-list default file, so obvious files touched by live-initramfs at startup could be not added (as the default behaviour). queries about this per week on irc but have not had the time to do anything about it myself. I have no time now too, and also no test machine... a lightingbolt killed some boxes in my home! When I'll buy a new VT ready machine* I hope to have the time to proper finish this part. * an account on a big iron with qemu (kvm) and a chroot anyone? -- ESC:wq signature.asc Description: This is a digitally signed message part. ___ debian-live-devel mailing list debian-live-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
Re: how I'm using debian-live
Hi What's in the magic tarball? Tony ___ debian-live-devel mailing list debian-live-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
