Testing whether Greater Security for Linux 2.4.x patch for 2.4.18 applies (dry run):
1 out of 1 hunk FAILED -- saving rejects to file fs/proc/proc_tty.c.rej
1 out of 11 hunks FAILED -- saving rejects to file include/linux/sched.h.rej
Greater Security for Linux 2.4.x patch for 2.4.18 does not apply cleanly
kann mir da jemand helfen oder muss ich wie im debian howto beschrieben einfach abwarten und tee trinken?
danke
Last edited by tommytom on 2003-11-05 17:30, edited 1 time in total.
Im Debian-Howto ganz oben steht der Hinweis, dass seit den ptrace-bugfixeten Debian kernelsourcen der GRSecurity-patch nicht mehr anzuwenden ist.
Schau mal im "Userprojekte unter freiene Lizenzen" beim Debianhowto, da gibt's fertige Kernelimages, die den Patch schon beeinhalten, und noch dazu für Rooties optimiert wurden.
CaptainCrunch wrote:Im Debian-Howto ganz oben steht der Hinweis, dass seit den ptrace-bugfixeten Debian kernelsourcen der GRSecurity-patch nicht mehr anzuwenden ist.
Schau mal im "Userprojekte unter freiene Lizenzen" beim Debianhowto, da gibt's fertige Kernelimages, die den Patch schon beeinhalten, und noch dazu für Rooties optimiert wurden.
cd /usr/src/
wget http://deb.debianhowto.de/dists/testing/debianhowto/binary-i386/kernel-image-2.4.21-grsec-ipv6_1_i386.deb
dpkg -i kernel-image-2.4.21-grsec-ipv6_1_i386.deb
shutdown -r now
und jetzt will meine maschine nicht mehr booten... war ich zu mutig mit dem einspielen der 2.4.21 oder habe ich gar was beim einspielen falsch gemacht?
wirsing wrote:Hat der Kernel devfs? (ist so eine böse Falle, wenn man dann nicht den devfsd installiert hat - devfs an sich ist ne tolle Sache)
gute frage.. im moment kämpfe ich noch damit in's rescue system zu gelangen.. manchmal dauert das gut 10 minuten bis das teil reagiert.. hatte heute schon mehrmals im rescue modus gehangen und konnte nicht mehr umstellen auf normal system.. nun ist es umgekehrt...
wie kann ich das problem aus dem rescue system lösen?
hatte hier noch in dieser mail angenommen das meine partition table geschrottet war.. aber etwas studieren brachte das dort alles in ordnung ist.. ich habs dann so gefixed:
rescue system booten:
mount /dev/hda3 /mnt
mount /dev/hda1 /mnt/boot
chroot /mnt
kernel fixen:
cd /boot
cp vmlinuz vmlinuz.new
cp vmlinuz.old vmlinuz
lilo
Mit exit aus dem chroot raus... danach dann
umount /mnt/boot
umount /mnt
shutdown -r now
(vorher im rescue system wieder auf normales system gestellt)
Es Läuft :lol:
Frage: gibts auch ein "version" kommando womit man sich die aktuelle kernel version anzeigen lassen kann? vertrauen ist ja gut, aber kontrolle ist besser!
und jetzt werde ich den RICHTIGEN kernel installieren!
Sofern man die Fragen, die einem debconf bei der Installation des Kernels (also bzgl. lilo.conf und Co.) nicht oder falsch beantwortet, braucht man sich auch nicht wundern, dass die Kiste nicht mehr hochkommt. ;)
Sorry, aber exakt dieser Kernel läuft auf diversen 1&1-Rooties wie am Schnürchen. Ich wüsste nicht, warum er das nicht auch bei dir tun sollte.
CaptainCrunch wrote:Sofern man die Fragen, die einem debconf bei der Installation des Kernels (also bzgl. lilo.conf und Co.) nicht oder falsch beantwortet, braucht man sich auch nicht wundern, dass die Kiste nicht mehr hochkommt. ;)
Sorry, aber exakt dieser Kernel läuft auf diversen 1&1-Rooties wie am Schnürchen. Ich wüsste nicht, warum er das nicht auch bei dir tun sollte.
und jetzt will meine maschine nicht mehr booten... war ich zu mutig mit dem einspielen der 2.4.21 oder habe ich gar was beim einspielen falsch gemacht?