reinstallation with host machine - no success
Hi, since reinstalling on my old memory machine is a dead-end, I tried another route: I took the disk from my PII machine to another box, which has 1GB of RAM, 1.6GHz processor but still has PATA so I could attach my disk. Since the old box did run HURD for years, I hope it will become usable again once reinstalled. Installation on the fast box (an IBM NetVista) went quite fine, I could also use the pseudo-graphical install. Everything is faster of course, no problem with drivers and it installed GRUB and all packages. However, at reboot, after GRUB, the machine hangs! Exactly in the same place! The installer doesn't install also the debug kernel by default, right? Out of curiosity, I took the HD and put it in the original machine an there it just self-reboots instead of displaying GRUB. This is much worse than before :( Riccardo
Re: reinstallation with host machine - no success
On Sat, 2014-11-22 at 15:02 +0100, Riccardo Mottola wrote: > Hi, > > since reinstalling on my old memory machine is a dead-end, I tried > another route: I took the disk from my PII machine to another box, which > has 1GB of RAM, 1.6GHz processor but still has PATA so I could attach my > disk. Since the old box did run HURD for years, I hope it will become > usable again once reinstalled. > > Installation on the fast box (an IBM NetVista) went quite fine, I could > also use the pseudo-graphical install. Everything is faster of course, > no problem with drivers and it installed GRUB and all packages. > > However, at reboot, after GRUB, the machine hangs! Exactly in the same > place! > > The installer doesn't install also the debug kernel by default, right? > > Out of curiosity, I took the HD and put it in the original machine an > there it just self-reboots instead of displaying GRUB. This is much > worse than before :( Which image did you use? And if using the latest image did you enable network or not? I think you should use a known working image and install without upgrading (i.e. no network) intil the install is completed. It can happen that the latest sid version is broken (happened to me a few times)
Re: Release process & rolling new releases
Hi! Justus, believe me, I do understand your frustration. Thank you very much for being insistent, instead of just going away. On Thu, 20 Nov 2014 14:03:43 +0100, Justus Winter <4win...@informatik.uni-hamburg.de> wrote: > Either more people have to review the patches, or we need to > change the commit policy. I agree. > Also, let's just merge the startup patch series. The hairy part of it > has been tested in Debian Hurd for a year now. We agree on the > principle, and noone took the time or cared enough to disagree with > the patch series. A reasonable assertion. > The glibc change is trivial. And even if the change is not applied to > the glibc, it only breaks the system shutdown. Furthermore, I believe > that we, the Hurd developers, should be entitled to make such a change > without the explicit consent of the glibc developers. If this is not > the case, then I do not believe that developing the Hurd is very > practical, or even possible, given that half of the Hurd system is > implemented in the glibc. Yes. I have already started discussing some procedural changes, and will follow up once I'm back home (currently travelling), in early December. Grüße, Thomas signature.asc Description: PGP signature
Re: [PATCH,Hurd] Fix deallocation after proc_getprocinfo call
Hello Samuel,
On Sun, Nov 02, 2014 at 04:25:37PM +0100, Samuel Thibault wrote:
> 2014-10-02 Samuel Thibault
>
> * gdb/gnu-nat.c (inf_validate_procinfo): Multiply the number of
> elements pi_len by the size of the elements before calling
> vm_deallocate.
> (inf_validate_task_sc): Likewise, and properly deallocate the
> noise array.
Again, sorry about the late review...
I only have a few minor comments, almost trivial in nature. In
the ChangeLog entry above, watch out that the last 2 lines are
indented using spaces intead of tabs.
> diff --git a/gdb/gnu-nat.c b/gdb/gnu-nat.c
> index d17a750..c571190 100644
> --- a/gdb/gnu-nat.c
> +++ b/gdb/gnu-nat.c
> @@ -804,7 +804,7 @@ inf_validate_procinfo (struct inf *inf)
>inf->nomsg = !!(pi->state & PI_NOMSG);
>if (inf->nomsg)
> inf->traced = !!(pi->state & PI_TRACED);
> - vm_deallocate (mach_task_self (), (vm_address_t) pi, pi_len);
> + vm_deallocate (mach_task_self (), (vm_address_t) pi, pi_len * sizeof
> (*(procinfo_t) 0));
The line is too long (soft limit is 74 characters, hard limit is 80).
Suggest using "sizeof (struct procinfo)", which I think is better
than dereferencing a NULL pointer. This is based on guessing that
type procinfo_t is a pointer to struct procinfo, as suggested by
the code in inf_validate_procinfo.
>if (noise_len > 0)
> vm_deallocate (mach_task_self (), (vm_address_t) noise, noise_len);
> }
> @@ -844,9 +844,9 @@ inf_validate_task_sc (struct inf *inf)
>
>suspend_count = pi->taskinfo.suspend_count;
>
> - vm_deallocate (mach_task_self (), (vm_address_t) pi, pi_len);
> + vm_deallocate (mach_task_self (), (vm_address_t) pi, pi_len * sizeof
> (*(procinfo_t) 0));
Same as above.
>if (noise_len > 0)
> -vm_deallocate (mach_task_self (), (vm_address_t) pi, pi_len);
> +vm_deallocate (mach_task_self (), (vm_address_t) noise, noise_len);
>
>if (inf->task->cur_sc < suspend_count)
> {
Thank you,
--
Joel
