main.efi: PE Unknown PE signature 0x642e x86-64
I have tried to build a efi test file by reading: https://wiki.osdev.org/GNU-EFI but the file did not loaded... and then I saw that file show what seems an invalid file format: paul@starman:~/efitest$ file main.efi main.efi: PE Unknown PE signature 0x642e x86-64 (stripped to external PDB), for MS Windows where when I do: paul@starman:~/efitest$ file /media/paul/VTOYEFI/EFI/BOOT/BOOTX64.EFI /media/paul/VTOYEFI/EFI/BOOT/BOOTX64.EFI: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows (I test it by copying main.efi over BOOTX64.EFI on the Ventoy USB key). Why I don't get the same file format? I suspect this is a bug, but I am writing to ask before filing one. Also this seems to exist since 2015: " # $(OBJCOPY) -B i386 -I binary -O pei-i386 $(INSERT_NAME) $(INSERT_NAME).o # This objcopy produces .o file, for which file says: "foo.bar.o: PE Unknown PE signature 0x642e (Unknown subsystem 0x0) Intel 80386 (stripped to external PDB), for MS Windows" " taken from: https://ubuntuforums.org/archive/index.php/t-2288915.html-- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re : Looking at Package Management for Karmic or Karmic+1
Someone said: >One gigantic improvement would be downloading package deltas instead of >whole >.DEB files. I care even more about doing that for apt-get update, than apt-get upgrade. I am using a bit 56k, and I have seen in last few days that apt-get update is part of cron.daily now. I did not deactivated it yet, but I think to do it, because it is a long process under 56k, and it make things go extremely slow while you browse. Better do that when you are away from keyboard. But it should not be long to download the list of packages updated... I think this is text files no? Tools for text diff are there for so long. You'd have to have many such diff files however... diff for latest hour, latest 6 hours, latest day, latest 4 days... and I would stop there. (If it makes 1 week you did not update, better take the full files). I can imagine that these diff for .deb could be a pression either on hard disk space if you save them, either on CPU if you have to calculate them before sending to the client. But on the list of packages... for me it make a lot of sense. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re : setresuid, setreuid AIO, bug? where?
Scott said: The Samba bug appears to be a race condition between AIO and setresuid() Yep, but I tend to believe that this race condition is directly inside the kernel. My reasoning is that the http://samba.org/~tridge/junkcode/aio_uid.c does seems to be all inside a simple process and not be using pthreads. My understanding is that only when you use pthreads, should setreuid become non-atomic (because then it has to iterate the thread group in user-space, like you said). But aio_uid seems to bug when using setresuid, not when using setreuid. Which is the reverse than what I could expect. 2009/3/23, Scott James Remnant : > On Sun, 2009-03-22 at 22:58 -0400, Paul Dufresne wrote: > >> But the comment from a glibc developer: >> https://bugzilla.redhat.com/show_bug.cgi?id=459901#c1 >> made me thinks: Hey, don't they know at glibc that this is setreuid >> that is in Posix standard, >> not setresuid!? >> > Unless I'm mistaken, you've made the same confusion in your mail here? > > The Samba bug appears to be a race condition between AIO and setresuid() > > setresuid() is a Linux-specific system call added in Linux 2.1.44, and > glibc 2.3.2; while it's also apparently implemented by HP-UX and some > of the BSDs, there's never any guarantee that the implementations are > entirely compatible. > > > On the other hand, you seem to have started to look for the > implementation of setresuid() and then segued into the implementation of > setreuid(). > > setreuid() is specified by POSIX.1-2001 > > > Now, you quote Jakub Jeliner in a Red Hat bug report saying: > > It is not about glibc trying to be smart, it is simply that POSIX > requires the call to affect the whole process, and kernel folks > refusing to implement that behavior in the kernel. > > What he's basically saying here is that POSIX requires that "the current > process" includes all threads; this is likely specified for setreuid() > so they match the behaviour for setresuid(). > > As you may know, the Linux kernel actually implements threads as > separate processes! There's no "thread" primitive in the kernel. So at > a first pass, syscalls would only affect the calling _thread_, not the > calling process. > > He says that the Kernel developers refuse to hide this behaviour from > the system call layer, and instead you have to deal with it in > userspace. This has actually been an advantage in the past, it's > allowed Linux to change threading libraries and models - so it's > arguable that it's been a good thing. > > So in userspace, in order to implement the POSIX-specified behaviour of > "calling process", you have to iterate the thread group. This makes it > non-atomic. > > Scott > -- > Scott James Remnant > sc...@canonical.com > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
setresuid, setreuid AIO, bug? where?
While investigating Samba? bug:
https://bugs.launchpad.net/bugs/216358
I came on:
http://webui.sourcelabs.com/rhel/issues/459901
Well, I tested a bit the http://samba.org/~tridge/junkcode/aio_uid.c
program on my system:
Linux version 2.6.28-9-generic (bui...@palmer) (gcc version 4.3.3
(Ubuntu 4.3.3-5ubuntu2) ) #31-Ubuntu SMP Wed Mar 11 15:43:58 UTC 2009
(ubuntu Jaunty 32 bits), and seems to confirm the 'bug' with aio_uid.c
Compiled with 'gcc -lrt aio_uid.c' and then tested with:
sudo ./a.out test.txt
But the comment from a glibc developer:
https://bugzilla.redhat.com/show_bug.cgi?id=459901#c1
made me thinks: Hey, don't they know at glibc that this is setreuid
that is in Posix standard,
not setresuid!?
So I downloaded the glibc-source package and came to the conclusion
that setresuid simply call the kernel as directly as possible:
.../glibc2.9/sysdeps/unix/sysv/linux/setresuid.c is:
int
__setresuid (uid_t ruid, uid_t euid, uid_t suid)
{
return INLINE_SETXID_SYSCALL (setresuid, 3, ruid, euid, suid);
}
and #define INLINE_SETXID_SYSCALL(name, nr, args...) \
INLINE_SYSCALL (name, nr, args)
inside .../glibc2.9/sysdeps/unix/setxid.h
So I thought, well, let's go see how setreuid is coded in glibc.
In .../glibc2.9/sysdeps/unix/sysv/linux/i386/setreuid.c I found what
seems to me like
quite a robust implementation:
#ifdef __NR_setreuid32
# if __ASSUME_32BITUIDS == 0
/* This variable is shared with all files that need to check for 32bit
uids. */
extern int __libc_missing_32bit_uids;
# endif
#endif /* __NR_setreuid32 */
int
__setreuid (uid_t ruid, uid_t euid)
{
int result;
#if __ASSUME_32BITUIDS > 0
result = INLINE_SETXID_SYSCALL (setreuid32, 2, ruid, euid);
#else
# ifdef __NR_setreuid32
if (__libc_missing_32bit_uids <= 0)
{
int saved_errno = errno;
result = INLINE_SETXID_SYSCALL (setreuid32, 2, ruid, euid);
if (result == 0)
goto out;
if (errno != ENOSYS)
return result;
__set_errno (saved_errno);
__libc_missing_32bit_uids = 1;
}
# endif /* __NR_setreuid32 */
if (((ruid + 1) > (uid_t) ((__kernel_uid_t) -1U))
|| ((euid + 1) > (uid_t) ((__kernel_uid_t) -1U)))
{
__set_errno (EINVAL);
return -1;
}
result = INLINE_SETXID_SYSCALL (setreuid, 2, ruid, euid);
# ifdef __NR_setreuid32
out:
# endif
#endif
return result;
}
Well, I have no idea which implementation is call on my system.
But the conclusion that come to my mind, is perhaps the AIO and
setresuid problem, is inside the kernel, not inside glibc, as the bug
reporter at Red Hat suggest.
Samba seems to have taken the decision to switch to using setreuid,
after this bug report.
I wish a much competent than me could take a look at this issue,
figure out if there is no
problem with http://samba.org/~tridge/junkcode/aio_uid.c (I don't
understand really, but man usleep suggest that the interaction with
alarm might be problematic).
I am not much use to system programming under Linux, and would like
someone more competent than myself to have a look, and eventually if
it is a bug in the kernel, submit it upstream.
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
ghc6 (Haskell compiler) becoming old
One of my new year resolution is to become a not too bad Haskell programmer in 2008. That said, I would like to have latest development version of ghc6 (Glasgow Haskell Compiler) which is the most well known Haskell compiler in Haskell community, inside Hardy. Unfortunately, Debian Sid just have the 6.6.1 version (that was released april 26, 2007) and the current version on ghc web site is 6.8.2. (released december 12, 2007). See http://packages.debian.org/sid/ghc6 for Debian packages. See http://www.haskell.org/ghc/index.html for upstream version. According to http://www.haskell.org/ghc/distribution_packages.html#debian we should expect to find latest version at: http://haskell-unsafe.alioth.debian.org/haskell-unsafe.html but even there it is only at 6.6.1 (oct 12, 2006), see: http://haskell-unsafe.alioth.debian.org/archive/i386/unstable/g/ghc6/ (Please don't ask me how they had 6.6.1 for Debian oct 12, 2006, as it was released only april 26, 2007, I don't know) I found that, but I am not sure how relevant it is: http://svn.debian.org/wsvn/pkg-haskell/?opt=dir&sc=1 It seems to be very recently updated (3 days ago). I am pretty sure there is/was a Debian Haskell mailing list, but I don't find it any more in: http://lists.debian.org/completeindex.html I am not an Ubuntu nor Debian developer. I could consider to try packaging it, but as this is a pretty complicated *Maybe* the reason is that many sub libraries need to be rebuilt with a new compiler, and *maybe* this is a lot of job, I don't know. Hope someone here can inform me better about this. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: bug #129910 tty[1-6] are active but display nothing in Gutsy
> Oh, actually, wait, I've asked the kernel team several time and got an answer: > 'just remove vga= from your startup kernel command line' The problem is that I am affected by this bug (or at least a very similar one in symptoms), but have no vga= in /boot/grub/menu.lst on kernel lines. Also, modprobe of the suggested modules does not help at all for me. So I will stop making my bug a duplicate of bug #129910. My bug is: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/162400 I can understand that the answer you get is simply remove vga= from startup kernel command line. Many people wrongly think that this reflect the resolution of the screen in X, but AFAIK only change splash screen, and now I realise TTY screens. Indeed, this make it an easy workaround, and I would use it if not for the fact that I am already using it with no success. :-) -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
bug #129910 tty[1-6] are active but display nothing in Gutsy
Bug #129910 is becoming very messy with it's 20 duplicates and apparently no known developer making clear comments. https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/129910 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
New spec: Configuration files upgrades made easier
This is to inform you of a new specification, beginning to be drafted: Configuration files upgrades made easier Summary: When upgrading a package for which you have made changes, intelligently merge old configuration file, with the new one, rather then choosing the old one or the new one. https://wiki.ubuntu.com/Configuration_files_upgrades_made_easier/ The best way to comment this spec, is to edit: https://wiki.ubuntu.com/Configuration_files_upgrades_discussion Thanks. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: What do I do with disturbing bug reports in Wine about system crashes?
For adding a task on an other package, I go to the pink 'Actions' menu in upper left, click on 'Also affects distribution', choose 'Ubuntu' as distribution in upper textbox, and the the package you guess the bug apply in lower textbox. Then click 'continue' button. I really suggest you guess the package. As a bug triager, that's what we invite bug reporters to do. So as a developer, your guess may well be better than what I guess anyway as a bug triager. Most bugs on Ubuntu get lost for a long time. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
UDEV vs. HAL responsability
I feel like opening a flame war. Basically, the question that come to my mind is about /etc/udev/rules.d/45-libgphoto2.rules . I am not even sure but I think most entries in there is making in sort that camera devices get mounted automatically. And that it requires to add a line for any known camera devices. Would it be possible to do the same with HAL? Actually, I am just beginning to read about HAL at: http://www.freedesktop.org/wiki/Software/hal more specifically at: http://people.freedesktop.org/~david/hal-spec/hal-spec.html#device-properties-info-callouts I feel that using HAL would be more appropriate, as it would use HAL database rather than reinvent a new hardware database. Also, it make it easier to port Ubuntu to a non-Linux OS. But I am just beginning to understand what UDEV and HAL are about, so I am opening the discussion here to more knowledgeable than me. I sure feel that if the answer is not obvious or require many changes, than obviously a new specification should be written. But on the other hand, maybe this have been really discussed and decided. The general question is what is/can/should be made by HAL, and what is/can/should be made by UDEV? -- http://www.fastmail.fm - IMAP accessible web-mail -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Implementation section of specs
While some nice comment have been made on how to make good quality spec (for the mouseTweaks spec I did not look yet), I'd like to share one compaint I have about how many (if not most) specs treat the implementation section. My problem is that specifications have no section in which they say how the implementation is advancing or going. I know Launchpad have a field indicating progression, but there is no way to know which parts of the design have been implemented yet and which don't. In fact as I read this, I come to the conclusion that my complaint seems to be a bug in https://wiki.ubuntu.com/SpecTemplate itself. In https://wiki.ubuntu.com/SpecSpec, it is a bit unclear if "Implementation Plan" is a different section than "Implementation". As I read and understand it, they should be separated sections, the "Implementation" section being edited by the assignee as it implements it, first saying what is implemented or not, and when implementation is finished, only a note saying it has been fully implemented should stay, with information with what is different than the design. I think what most people, and the Template for now, is using the "Implementation" section, should be "Implementation Plan". In fact SpecSpec say that "Implementation Plan" should contains: "This section is usually broken down into subsections, such as the packages being affected, data and system migration where necessary, user interface requirements and pictures (photographs of drawings on paper work well).". Clearly way too much to also serve to show what is the progress of the implementation. So to summarize, I propose to edit SpecTemplate, to contains no "Implementation" section, and to add these two sections: "Implementation Plan" and "Implementation Progress". This should make it more probable to be used correctly by a new spec writer. -- http://www.fastmail.fm - Or how I learned to stop worrying and love email again -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
