Unlucky with booting d-i
Hi, I'm frustrated because I didn't succeed in boot d-i. I burnt the i386 netinst iso on a CD-RW and tried to boot it from a Pioneer DVD-106S. After searching the ISOLinux page [1], it looks like I don't have a proper IDE chipset, namely Promise ATA. I'm not sure it is the root of the problem though. Isn't there any way around else than using a floopy with smb.bin, I haven't had floppies for ages. Thanks. [1] http://syslinux.zytor.com/hardware.php -- Jérôme Marant
Re: Unlucky with booting d-i
[EMAIL PROTECTED] (Jérôme Marant) writes: > Hi, > > I'm frustrated because I didn't succeed in boot d-i. > I burnt the i386 netinst iso on a CD-RW and tried to boot > it from a Pioneer DVD-106S. > > After searching the ISOLinux page [1], it looks like I don't have a > proper IDE chipset, namely Promise ATA. I'm not sure it is the > root of the problem though. Well, no, it is a VIA Apollo KT133 chipset, my bad. -- Jérôme Marant
CD installation successful
Hi, I'm pleased to see the real progress that has been made on boot floppies since potato. Many thanks to te whole team. Also, thanks to the debian-cd team. I successfully installed the test CD, but I have common hardware so it doesn't really count. What I like (among others): - i18n of installation messages - frame buffer - kernel modules choices with bf24 flavour (thanks Eduard) What I don't like: - default 2.2.20 kernel choice (I hadn't read the installation guide though) - I didn't see any "Reboot the system" choice (?!) Cheers, -- Jérôme Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://marant.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#127405: latest python2.1-xml breaks boot-floppies build system.
Junichi Uekawa <[EMAIL PROTECTED]> writes:
> ermmm.. that makes this code unnecessarily large.
>
> Why is it not enough to specify 'utf-8' in here ?
>
> for lang in what:
> if do_convert:
> e = engine ('utf-8', lang.charset)
> else:
> e = do_not_convert ()
I'm sorry but the engine object comes from a module that is neither
part of Python, nor python-xml so I can't really help with it.
--
Jérôme Marant <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
http://marant.org
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python-xml and Debian boot floppies
Mikhail Sobolev <[EMAIL PROTECTED]> writes: > As it seems that bf now depend on python-dev >= 2.1, unicode support (and > character conversion) is certainly there. So the iconv module is no longer > required and needed at all. > > The following patch seems to provide one of the possible solutions. I'd > appreciate if somebody could test it before I put it into CVS. It works for > me. :)) (When I put it into CVS, two more modifications will be done: iconv.c > will be removed, and all the references to this code will also be removed.) The patch works fine. I can reassign the bug to boot-floppies. Good job ! Cheers, -- Jérôme Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://marant.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#127405: latest python2.1-xml breaks boot-floppies build system.
Mikhail Sobolev <[EMAIL PROTECTED]> writes: > JFYI, engine is a wrapper over iconv interface. When all this was started, the > latest version of python was 1.5.2, and there was no way to work with iconv. But python 2.1 neither provide a way to access iconv, IIRC. -- Jérôme Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://marant.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [i386] introducing a kernel 2.4 installation flavor
"John H. Robinson, IV" <[EMAIL PROTECTED]> writes: > 1) (mandatory) we are still able to use ext3/resierfs/xfs(if available) >as the root partition. this would either mean building the install >kernel with ext3/resierfs/xfs(if available) statictly in the kernel >(unlikely) or include them as modules int he RAM disk (possible, but >might take up more room on the root disk that we don't really have). Oh yeah ! Applying the XFS patch would be great! -- Jérôme Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://marant.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: first weekly debian-installer status report
Joey Hess <[EMAIL PROTECTED]> writes: > - documentation [UNCLAIMED} > Not started. I'm willing to help on this. How do I start ? What is the prefered DTD among the following : DebianDoc-SGML Docbook-SGML Docbook-XML Thanks. -- Jérôme Marant <[EMAIL PROTECTED]> http://jerome.marant.free.fr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394871: cdebconf-gtk-udeb: Dead keys do not work with French keyboard (fr-latin9)
Package: cdebconf-gtk-udeb Severity: normal Hi, With latest debian-installer netinst iso (20061023), I could not manage to get dead keys work to type accents (especially "ô") in the user name, before entering the login. I tried other dead keys without any success. I was using a fr-latin9 keymap. Regards, -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-amd64 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- Jérôme Marant
Bug#394871: cdebconf-gtk-udeb: Dead keys do not work with French keyboard (fr-latin9)
Le lundi 23 octobre 2006 22:05, vous avez écrit : > On Mon, Oct 23, 2006 at 04:51:51PM +0200, Jérôme Marant wrote: > > With latest debian-installer netinst iso (20061023), I could not > > manage to get dead keys work to type accents (especially "ô") in the > > user name, before entering the login. > > I tried other dead keys without any success. > > > > I was using a fr-latin9 keymap. > > can you enter those using non-graphical installer or, if using g-i, when you > switch to VT2 (ctrl-alt-f2)? I'm running amd64 so switching to another VT does not work. I'm going to test with the non-graphical installer. BTW, I can help debugging that VT issue if you tell me where I shall look into. Cheers, -- Jérôme Marant
Bug#394871: cdebconf-gtk-udeb: Dead keys do not work with French keyboard (fr-latin9)
Le lundi 23 octobre 2006 23:35, Davide Viti a écrit :
> I see; you can use the very same iso and boot using "install
> DEBIAN_FRONTEND=newt" and
> eventually append also "priority=medium"
I just had to hit Return because it makes use of newt by default.
> > BTW, I can help debugging that VT issue if you tell me where
> > I shall look into.
>
> well, it's not yet clear what is going on;
> I've noticed the following :
>
> when loading the keymap using the graphical frontend, you get the
> following warnings:
>
> INFO: kbd_chooser: setting keymap fr-latin9
> WARNING **: : assuming iso-8859-1 cedilla
> WARNING **: : assuming iso-8859-1 acute
> WARNING **: : assuming iso-8859-1 diaeresis
> WARNING **: : assuming iso-8859-1 brokenbar
> WARNING **: : assuming iso-8859-1 threequarters
> WARNING **: : assuming iso-8859-1 currency
> WARNING **: : assuming iso-8859-1 onehalf
> WARNING **: : assuming iso-8859-1 onequarter
>
> and those are printed only if kbd_mode is different from "3"
> (K_UNICODE, from ); using some extra logs I noticed that
> kbd_mode is "2" (K_MEDIUMRAW) when running the graphical frontend
> and looking at the directfb sources (inputdrivers/keyboard/keyboard.c)
>
> if (ioctl( dfb_fbdev->vt->fd, KDSKBMODE, K_MEDIUMRAW ) < 0) {
> D_PERROR( "DirectFB/Keyboard: K_MEDIUMRAW failed!\n" );
>
> ...
>
> info->desc.max_keycode = 127;
>
> I've tried to change that into K_UNICODE and s/127/255/
>
> the warnings disappear, but I can't get the accented letters I get on VT2
> (for example "["+"e" give me "ê" when I use fr-latin9 on my italian keyboard)
Whenever you change something, you regenerate th udeb then the mini iso
and boot it, right?
--
Jérôme Marant
Bug#394871: cdebconf-gtk-udeb: Dead keys do not work with French keyboard (fr-latin9)
Le mardi 24 octobre 2006 13:30, vous avez écrit : > >Whenever you change something, you regenerate th udeb then the mini iso > >and boot it, right? > > yes > > FYI, I sent a message to the directfb ML: > > http://mail.directfb.org/pipermail/directfb-dev/2006-October/002394.html OK. Does it give clues? I'm not really skilled in this field. BTW, I was told not being able to switch to another VT2 on amd64 is caused by a segfault. Where does it happen? -- Jérôme Marant
Bug#394871: cdebconf-gtk-udeb: Dead keys do not work with French keyboard (fr-latin9)
Le mercredi 25 octobre 2006 20:47, Davide Viti a écrit : > On Tue, Oct 24, 2006 at 02:27:52PM +0200, Jérôme Marant wrote: > > > http://mail.directfb.org/pipermail/directfb-dev/2006-October/002394.html > > > > OK. Does it give clues? I'm not really skilled in this field. > > not much since I'm not very skilled in this either > > > > BTW, I was told not being able to switch to another VT2 on amd64 is caused > > by a segfault. Where does it happen? > > refer to #373253 ; noone has provided backtrace logs or such yet I tried that but I can't find a way to save traces. So I did in rootskel/src/lib/debian-installer/menu: -- strace -f -s 4096 -o /tmp/cdebconf.trace debconf -o d-i $MENU modprobe ext3 mount -t ext3 -o rw /dev/sda1 /mnt cp /tmp/cdebconf.trace /mnt umount /mnt reboot -- My /dev/sda1 is a ext3 partition. I added the ext3 udeb to installer/build/pkg-lists/netboot/gtk/amd64.cfg But it does not work either. Am I doing something wrong? Thanks. -- Jérôme Marant
Bug#394871: cdebconf-gtk-udeb: Dead keys do not work with French keyboard (fr-latin9)
Le dimanche 29 octobre 2006 17:06, Frans Pop a écrit : > > But it does not work either. Am I doing something wrong? > > One possibility is that the code after starting the menu is not run for > some reason. I think it is because I get the reboot few seconds after hitting C-A-F2. > Did you also include the drivers needed to access the USB stick in the > image? I didn't. I'm going to. > It's probably easier to mount the partition before starting the strace and > writing the log directly to it. The problem is that /dev entries need to be available in order for the partition to be mounted, hence the problem. When are they created? > One other thing to be aware of is that the frontend will be restarted by > inittab after a crash and possibly that could overwrite an earlier trace. > You may want to disable that. Well, I already thought about this. I was first writing to cdebconf.trace.$$ so the trace won't get overwritten. Then, I added an entry to finish-install dedicated at moving all traces to the partition. Unfortunately, it made the installer freeze, even before hitting C-A-F2: I guess traces filled the ramdisk till out of space far before reaching the end of the install. > Note that you should be able to tweak things by booting the installer with > BOOT_DEBUG=3. This will give you two debug shells before init is run. Thanks. -- Jérôme Marant
Re: Bug#394871: cdebconf-gtk-udeb: Dead keys do not work with French keyboard (fr-latin9)
Le dimanche 29 octobre 2006 23:37, Frans Pop a écrit : > Taking this to d-boot list as it is kind of OT for the original BR. Let me > know if I can drop the CC. You can drop it. I'm subscribed now. > On Sunday 29 October 2006 22:31, Jérôme Marant wrote: > > The problem is that /dev entries need to be available in order for the > > partition to be mounted, hence the problem. When are they created? > > Not sure during boot, but I guess they must get created. > They also get created during hw-detect by calling 'update-dev' which > trigers udev to do its stuff. Alright. I used the following recipe (packages/rootskel/src/lib/debian-installer/menu) after adding scsi and sata modules to the image: - modprobe sata_nv modprobe ext3 mknod -m 0660 /dev/sda1 b 8 1 mount -t ext3 -o rw /dev/sda1 /mnt strace -f -s 4096 -o /mnt/cdebconf.trace debconf -o d-i $MENU umount /mnt reboot - I hit C-A-F2 at the very beginning, on the first menu item. I put the trace at: http://people.debian.org/~jerome/d-i/cdebconf-broken-vt-switch.trace.bz2 Regards, -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394871: cdebconf-gtk-udeb: Dead keys do not work with French keyboard (fr-latin9)
Le mardi 24 octobre 2006 13:30, Davide Viti a écrit : > >Whenever you change something, you regenerate th udeb then the mini iso > >and boot it, right? > > yes > > FYI, I sent a message to the directfb ML: > > http://mail.directfb.org/pipermail/directfb-dev/2006-October/002394.html Since I can't use dead keys with i386 either , i used this version so I can switch to a VT at least. I got the following error after trying to use dead keys: DirectFB/FBDev: Panning display failed! --> Invalid argument Google does not give any concrete answers but bug reports. BTW, I think it does not matter if directfb makes use of MEDIUMRAW mode. What matters is how gdk-directfb converts it to UTF-8. Regards, -- Jérôme Marant
Re: Bug#394871: cdebconf-gtk-udeb: Dead keys do not work with French keyboard (fr-latin9)
Le lundi 30 octobre 2006 18:05, Attilio Fiandrotti a écrit : > Yesterday, talking with fjp, we noticed that the AltGr-o key combination > correctly produces an "o+^" character, which is something correct > > [EMAIL PROTECTED]:~$ zcat > /usr/share/keymaps/i386/azerty/fr-latin9.kmap.gz |more > # Copyright (c) 1997, 1998 Guylhem Aznar : GPL > # Copyright (c) 1997 Pierre-Charles David > # > # Les accents circonflexes des principales voyelles sont obtenus avec > # la touche Alt_Gr, les trémas sont obtenus par Alt_Gr + Shift. > > Jerome, could you please test if AltGr-o under fr-latin9 produces a > "o+^" letter with your keyboard too ? Yes, it works. I used it while dead keys where not working. But it is a work around right? Dead keys should be working. -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a debugging method for this bug
Le lundi 06 novembre 2006 12:55, Attilio Fiandrotti a écrit : > Jerome, if i provide a simple patch for DFB 0.9.25, could you please > rebuild the libdirectfb-udeb and see if the crash is fixed? > In this case we could backport the fix from DFB 1.0-rc2 to DFB 0.9.25: > would this be possible if fixes this chash? Of course. > Using different signals for cdebconf db saving and DFB vt switching is > good, but still cdebconf's signal handling mechanism may need to be fixed. How does it need to be fixed? Won't using different signal fix the issue? -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a debugging method for this bug
Le lundi 06 novembre 2006 14:51, Attilio Fiandrotti a écrit : > > How does it need to be fixed? Won't using different signal fix the issue? > > > > Using different signals should fix up this specific crash, but basing on > this BR [1] by colin watson cdebconf's signal handling mechanism is not > very robus and needs to be fixed. > If you have some time, could you please boot textual and send to > cdebconf SIGUSR1 and SIGUSR2 signals, to see if it crashes? It crashes on SIGUSR2. It is OK with SIGUSR1. Regards, -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a debugging method for this bug
Le mardi 07 novembre 2006 14:30, Attilio Fiandrotti a écrit : > Jérôme Marant wrote: > > Le lundi 06 novembre 2006 12:55, Attilio Fiandrotti a écrit : > > > > > >>Jerome, if i provide a simple patch for DFB 0.9.25, could you please > >>rebuild the libdirectfb-udeb and see if the crash is fixed? > >>In this case we could backport the fix from DFB 1.0-rc2 to DFB 0.9.25: > >>would this be possible if fixes this chash? > > > > > > Of course. > > hi jerome > > Attached to this mail you will find a patch that moves DFB's 0.9.25.1 > signal handling to different signals than SIGUSR1/2 (during my tests, > those were replaced to signals number 41 and 42 and everything worked > correctly). > > thanks in anticipation for testing. I rebuilt libdirectfb udeb with your patch and re-generated the miniiso. Unfortunately, nothing changed. I can try to provide a new strace output, as soon as someone unbreaks rootskel. -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Lastest klibc breaks rootskel?
Hi, I tried to rebuilt rootskel yesterday and I got: Making install in src-bootfloppy make[2]: entrant dans le répertoire « /home/jerome/d-i/packages/rootskel/src-bootfloppy » Making build in bin make[3]: entrant dans le répertoire « /home/jerome/d-i/packages/rootskel/src-bootfloppy/bin » klcc-c -o cpio.o cpio.c open3: exec of /usr/local/bin/gcc -D__KLIBC__=1 -D__KLIBC_MINOR__=4 -D_BITSIZE=64 -fno-stack-protector -m64 -D__KLIBC__=1 -D__KLIBC_MINOR__=4 -D_BITSIZE=64 -I/usr/lib/klibc/include/arch/x86_64 -I/usr/lib/klibc/include/bits64 -I/usr/lib/klibc/include -Os -fno-asynchronous-unwind-tables -fomit-frame-pointer -falign-functions=1 -falign-jumps=1 -falign-loops=1 -c -o cpio.o -x c cpio.c failed at /usr/bin/klcc line 138 Can anyone confirm? -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a debugging method for this bug
Le mardi 07 novembre 2006 19:01, Attilio Fiandrotti a écrit : > > Unfortunately, nothing changed. > > I can try to provide a new strace output, as soon as someone unbreaks > > rootskel. > > > > So far we stated this bug > > - cannot be reproduced on a regular debian system > - does not look like it's related to the way DFB handles VT switching > > One more test: could you please compile the attached gtk application > (which simply runs a progressbar), pull into the d-i, run it and switch > VT while the progressbar runs to see if crashes? So, I need to boot the d-i with the newt installer, switch to another VT and run the program, right? BTW, how do you easily add a binary to the d-i? Thanks. -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lastest klibc breaks rootskel?
Le mercredi 08 novembre 2006 19:10, Joey Hess a écrit : > Jérôme Marant wrote: > > I tried to rebuilt rootskel yesterday and I got: > > > > Making install in src-bootfloppy > > make[2]: entrant dans le répertoire « > > /home/jerome/d-i/packages/rootskel/src-bootfloppy » > > Making build in bin > > make[3]: entrant dans le répertoire « > > /home/jerome/d-i/packages/rootskel/src-bootfloppy/bin » > > klcc-c -o cpio.o cpio.c > > open3: exec of /usr/local/bin/gcc -D__KLIBC__=1 -D__KLIBC_MINOR__=4 > > -D_BITSIZE=64 -fno-stack-protector -m64 -D__KLIBC__=1 -D__KLIBC_MINOR__=4 > > -D_BITSIZE=64 -I/usr/lib/klibc/include/arch/x86_64 > > -I/usr/lib/klibc/include/bits64 -I/usr/lib/klibc/include -Os > > -fno-asynchronous-unwind-tables -fomit-frame-pointer -falign-functions=1 > > -falign-jumps=1 -falign-loops=1 -c -o cpio.o -x c cpio.c failed at > > /usr/bin/klcc line 138 > > > > Can anyone confirm? > > No, works fine here. Why is your klcc trying to run a gcc in > /usr/local/bin? According to the code, this is where it expects to find gcc. I'm on amd64 BTW. -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lastest klibc breaks rootskel?
Le mercredi 08 novembre 2006 20:39, Jérôme Marant a écrit : > Le mercredi 08 novembre 2006 19:10, Joey Hess a écrit : > > Jérôme Marant wrote: > > > I tried to rebuilt rootskel yesterday and I got: > > > > > > Making install in src-bootfloppy > > > make[2]: entrant dans le répertoire « > > > /home/jerome/d-i/packages/rootskel/src-bootfloppy » > > > Making build in bin > > > make[3]: entrant dans le répertoire « > > > /home/jerome/d-i/packages/rootskel/src-bootfloppy/bin » > > > klcc-c -o cpio.o cpio.c > > > open3: exec of /usr/local/bin/gcc -D__KLIBC__=1 -D__KLIBC_MINOR__=4 > > > -D_BITSIZE=64 -fno-stack-protector -m64 -D__KLIBC__=1 -D__KLIBC_MINOR__=4 > > > -D_BITSIZE=64 -I/usr/lib/klibc/include/arch/x86_64 > > > -I/usr/lib/klibc/include/bits64 -I/usr/lib/klibc/include -Os > > > -fno-asynchronous-unwind-tables -fomit-frame-pointer -falign-functions=1 > > > -falign-jumps=1 -falign-loops=1 -c -o cpio.o -x c cpio.c failed at > > > /usr/bin/klcc line 138 > > > > > > Can anyone confirm? > > > > No, works fine here. Why is your klcc trying to run a gcc in > > /usr/local/bin? > > According to the code, this is where it expects to find gcc. > I'm on amd64 BTW. I confirm that klcc from libklibc-dev 1.4.29 correctly pointed to /usr/bin/gcc. I'll file a bug report. -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lastest klibc breaks rootskel?
Le mercredi 08 novembre 2006 21:04, Joey Hess a écrit :
> Jérôme Marant wrote:
> > > No, works fine here. Why is your klcc trying to run a gcc in
> > > /usr/local/bin?
> >
> > According to the code, this is where it expects to find gcc.
> > I'm on amd64 BTW.
>
> [EMAIL PROTECTED]:~>grep local =klcc
> zsh: exit 1 grep local =klcc
>
> I'm not seeing anything in the code that would make it use a gcc in
> /usr/local/bin, unless you have CC pointing to there.
chenonceaux:~$ grep local /usr/bin/klcc
$CC = "\/usr\/local\/bin\/gcc";
@CC = ("\/usr\/local\/bin\/gcc");
It changed in 1.4.30. I compared with previous version.
--
Jérôme Marant
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lastest klibc breaks rootskel?
Le mercredi 08 novembre 2006 21:17, Joey Hess a écrit :
> Jérôme Marant wrote:
> > chenonceaux:~$ grep local /usr/bin/klcc
> > $CC = "\/usr\/local\/bin\/gcc";
> > @CC = ("\/usr\/local\/bin\/gcc");
> >
> > It changed in 1.4.30. I compared with previous version.
>
> That version's ok on i386. Sounds like a RC bug should be filed on
> libklibc-dev for being broken on amd64.
Yes, I filed it.
--
Jérôme Marant
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lastest klibc breaks rootskel?
Le mercredi 08 novembre 2006 21:17, Joey Hess a écrit :
> Jérôme Marant wrote:
> > chenonceaux:~$ grep local /usr/bin/klcc
> > $CC = "\/usr\/local\/bin\/gcc";
> > @CC = ("\/usr\/local\/bin\/gcc");
> >
> > It changed in 1.4.30. I compared with previous version.
>
> That version's ok on i386. Sounds like a RC bug should be filed on
> libklibc-dev for being broken on amd64.
I filed a bug report but it got lost somewhere (postfix correctly sent
it though).
Anyway, someone did a binNMU. Many thanks to that person.
--
Jérôme Marant
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a debugging method for this bug
Le jeudi 09 novembre 2006 16:22, Attilio Fiandrotti a écrit : > this is exactly what i do in order not to regenrate the iso every time i > have to pull in something new and should work easily. Sorry if I'm late on this, but I'm not sure if I did it properly. Since I have to boot with the newt interface to run the snippet, I don't get the necessary libraries installed (gdk, directfb and so on). So, I mounted partitions of the system where I built it and ran it from this chroot. I switched VT's while the bar was progressing without any crash. Was it a correct procedure? -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Cause of g-i crashing on AMD64 at VT switch found
Le vendredi 24 novembre 2006 15:01, Attilio Fiandrotti a écrit : > Hi > > i recently put my hands on an AMD64 machine, so i had the chance to run > the installer from a chroot and i noticed that the crash produces this log > > libgcc_s.so.1 must be installed for pthread_cancel to work > (!) [ 5905:0.000] --> Caught signal 6 (unknown origin) <-- > libgcc_s.so.1 must be installed for pthread_cancel to work > Aborted > > adding this library (and full libc) to the chroot prevents the crash. > > Try this by yourself > > - boot an amd64 image with DEBIAN_FRONTEND=newt > - proceed with installation process until full libc6 is unpacked > - wget libgcc_s.so.1 into the installer > - export DEBIAN_FRONTEND=gtk > - debian-installer > > now you should be able to chvt without crashing anymore. Thanks for finding this bug! I didn't know that you could change the frontend on the fly. So you interrupted it right after installing the libc and restarted after changing the frontend? -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
