debian-user-digest Digest V2007 #2035

Content-Type: text/plain

debian-user-digest Digest Volume 2007 : Issue 2035

Today's Topics:
  Re: Weird partition arrangements and [ "Hamza Saglam" <hamzasaglam@googlem ]   Re: why do iceweasel et al have more [ Erik Persson <erik-maillist@djingis ]

Date: Fri, 27 Jul 2007 03:24:58 +0100
From: "Hamza Saglam" <hamzasaglam@googlemail.com> To: "Nguyen, Cuong K." <cuongkieunguyen@gmail.com> Cc: debian-user@lists.debian.org
Subject: Re: Weird partition arrangements and broken GRUB

Message-ID: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi KC,

Thanks for your suggestions. I have removed the boot flag from sda1 (while keeping it on sda5) and changed the Windows 'root' to (hd0,4), but unfortunately I still get the dreaded 'Filesystem type unknown, partition type 0x7' message.

I have read somewhere else that Windows could only boot from a primary partition, I don't know if that is the issue here but do you think it might be related?

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.debian.org Links debian-announce debian-apache debian-arm-changes debian-beowulf debian-boot debian-cd debian-cd-vendors debian-changes debian-changes-digest debian-isp debian-kde debian-laptop debian-mirrors-announce debian-news debian-security debian-security-announce debian-testing debian-user debian-user-digest Request more information about Pantek

Someone, through another channel, suggested me to use /dev/sda1's bootloader to boot into Windows XP, but seeing that /dev/sda1 contains a crippled WinPE recovery application, I don't think it will really work.

Suggestions would be much appreciated,

Thanks.

On 7/27/07, Nguyen, Cuong K. <cuongkieunguyen@gmail.com> wrote:
>
>
>
> On 7/26/07, Hamza Saglam <hamzasaglam@googlemail.com> wrote:
> >
> > Hi,
> >
> > After reading dozens of GRUB tutorials for a good few hours and not
> > getting anywhere, I've decided to post on this mailing list regarding
> > my problem. If it has been covered before please pardon me, I really
> > can't see it :(
> >
> > Now before I start, I'd like to point out that we are both debian
> > users both due to the nature of our work, we have to have a windows
> > installation on our machines. Sad but true :(
> >
> > A friend of mine brought in his laptop after he said he couldn't get
> > 'windows booting', and when I had a look at the partition table using
> > gparted, I was presented with the following monstrosity:
> >
> > screenshot:
> > http://***image.***bayimg.***com/oaeikaabk.jpg
> > (please get rid of the 9 stars, the mailing list wouldn't accept my
> > message without these)
> >
> >
> > (for the text based readers), it looks a bit like:
> > /dev/sda1 fat32 (boot)
> > /dev/sda2 extended (lba)
> > /dev/sda5 ntfs (boot)
> > /dev/sda6 linux-swap
> > /dev/sda3 ext3
> >
> > The first fat32 partition is the recovery files that came with the
> > laptop, the rest is a bit of mess really :)
> >
> > Relevant bits from /boot/grub/menu.lst:
> >
> > title Debian GNU/Linux, kernel 2.6.18-4-686
> > root (hd0,2)
> > kernel /boot/vmlinuz-2.6.18-4-686
> root=/dev/sda3 ro
> > initrd /boot/initrd.img- 2.6.18-4-686
> > savedefault
> >
> > title Debian GNU/Linux, kernel 2.6.18-4-686 (single-user mode)
> > root (hd0,2)
> > kernel /boot/vmlinuz- 2.6.18-4-686
> root=/dev/sda3 ro single
> > initrd /boot/initrd.img- 2.6.18-4-686
> > savedefault
> >
> > title Microsoft Windows XP
> > root (hd0,3)
> > savedefault
> > makeactive
> > chainloader +1
> >
> > title Acer eRecovery Management
> > root (hd0,0)
> > savedefault
> > makeactive
> > chainloader +1
> >
> >
> > I've tried all the possible combinations for the root directive of the
> > Windows section, but it doesn't want to load windows.
> >
> > Is there any way I can address the ntfs partition within that extended
> > partition, or do I need to modify the structure. (I'd very much prefer
> > not changing the structure, even though it is quite messy)
> >
> >
> > I am stuck so any help would be much appreciated.
> >
> > Many thanks.
> > Hamza
> >
> >
> > --
> > To UNSUBSCRIBE, email to
> debian-user-REQUEST@lists.debian.org
> > with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
> >
> >
>
> If you look at my partition table, you may call it "messier" or "weirder":
>
> Disk /dev/sda: 100.0 GB, 100030242816 bytes
> 255 heads, 63 sectors/track, 12161 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
>
> Device Boot Start End Blocks Id System
> /dev/sda1 1 784 6297448+ 12 Compaq diagnostics
> /dev/sda2 * 785 3356 20659590 7 HPFS/NTFS
> /dev/sda3 4507 12161 61488787+ f W95 Ext'd (LBA)
> /dev/sda4 3357 4506 9237375 7 HPFS/NTFS
> /dev/sda5 4507 7064 20547103+ 83 Linux
> /dev/sda6 7065 7203 1116486 82 Linux swap / Solaris
> /dev/sda7 11974 12161 1510078+ 82 Linux swap / Solaris
> /dev/sda8 7204 9635 19535008+ 83 Linux
> /dev/sda9 9636 11973 18779953+ 83 Linux
>
> Partition table entries are not in disk order
>
> And here is the menu.lst
>
> ## ## End Default Options ##
>
> title Ubuntu, kernel 2.6.20-16-generic
> root (hd0,7)
> kernel /boot/vmlinuz-2.6.20-16-generic root=/dev/sda8 ro quiet splash
> initrd /boot/initrd.img-2.6.20-16-generic
> quiet
> savedefault
>
> title Ubuntu, kernel 2.6.20-16-generic (recovery mode)
> root (hd0,7)
> kernel /boot/vmlinuz-2.6.20-16-generic root=/dev/sda8 ro single
> initrd /boot/initrd.img- 2.6.20-16-generic
>
> title Ubuntu, kernel 2.6.20-15-generic
> root (hd0,7)
> kernel /boot/vmlinuz-2.6.20-15-generic
> root=UUID=3ce886e2-7b3d-4803-ba0e-19a605fb1153 ro quiet
> splash break=top
> initrd /boot/initrd.img- 2.6.20-15-generic
> quiet
> savedefault
>
> title Ubuntu, kernel 2.6.20-15-generic (recovery mode)
> root (hd0,7)
> kernel /boot/vmlinuz-2.6.20-15-generic
> root=UUID=3ce886e2-7b3d-4803-ba0e-19a605fb1153 ro single
> initrd /boot/initrd.img-2.6.20-15-generic
>
> title Ubuntu, memtest86+
> root (hd0,7)
> kernel /boot/memtest86+.bin
> quiet
>
> ### END DEBIAN AUTOMAGIC KERNELS LIST
>
> # This is a divider, added to separate the menu items below from the Debian
> # ones.
> title Other operating systems:
> root
>
>
> # This entry automatically added by the Debian installer for a non-linux OS
> # on /dev/hda1
> title Windows NT/2000/XP Recovery
> root (hd0,0)
> savedefault
> makeactive
> chainloader +1
>
>
> # This entry automatically added by the Debian installer for a non-linux OS
> # on /dev/hda2
> title Microsoft Windows XP Professional
> root (hd0,1)
> savedefault
> makeactive
> chainloader +1
>
>
> # This entry automatically added by the Debian installer for an existing
> # linux installation on /dev/hda5.
> title Mandriva 2007 (on /dev/hda5)
> root (hd0,4)
> kernel /boot/vmlinuz root=/dev/hda5 resume=/dev/hda6 splash=silent
> initrd /boot/initrd.img
> savedefault
> boot
>
>
> # This entry automatically added by the Debian installer for an existing
> # linux installation on /dev/hda5.
> title Mandriva 2007 (recovery mode) (on /dev/hda5)
> root (hd0,4)
> kernel /boot/vmlinuz root=/dev/hda5 resume=/dev/hda6
> initrd /boot/initrd.img
> savedefault
> boot
>
>
> # This entry automatically added by the Debian installer for an existing
> # linux installation on /dev/hda5.
> title failsafe (on /dev/hda5)
> root (hd0,4)
> kernel /boot/vmlinuz root=/dev/hda5 failsafe resume=/dev/hda6
> initrd /boot/initrd.img
> savedefault
> boot
>
> Very similar to your case: I have one Recovery partition (sda1), one Windows
> XP Pro, one Ubuntu box, and one Mandriva box. Everything works just fine: by
> selecting on the boot menu, I can boot into any OS I want.
>
> As about your case, here is my suggestion for menu.lst (not sure it will
> work, but worth giving a try)
>
> title Debian GNU/Linux, kernel 2.6.18-4-686
> root (hd0,2)
> kernel /boot/vmlinuz- 2.6.18-4-686 root=/dev/sda3 ro
> initrd /boot/initrd.img- 2.6.18-4-686
> savedefault
>
> title Debian GNU/Linux, kernel 2.6.18-4-686 (single-user mode)
> root (hd0,2)
> kernel /boot/vmlinuz- 2.6.18-4-686 root=/dev/sda3 ro single
> initrd /boot/initrd.img- 2.6.18-4-686
> savedefault
>
> title Microsoft Windows XP
> root (hd0,4)
> savedefault
> makeactive
> chainloader +1
>
> title Acer eRecovery Management
> root (hd0,0)
> savedefault
> makeactive
> chainloader +1
>
> The only change here is for XP partition: root (hd0,4) not (hd0,3) because
> your ntfs partition is sda5. Also, you may need just one partition to be
> bootable like me (you have two bootable).
>
> Hope that this can help,
>
> KC.
>

Date: Fri, 27 Jul 2007 04:49:41 +0200
From: Erik Persson <erik-maillist@djingis.se> To: debian-user@lists.debian.org
Subject: Re: why do iceweasel et al have more frequent security issues?

Message-ID: <46A95D45.4090904@djingis.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Andrew Sackville-West wrote:
> On Thu, Jul 26, 2007 at 10:52:07PM +0200, Erik Persson wrote:
>
>> Anyhow, the basic fact that there is fewer security alerts in Konq makes
>> this a more secure browser, whether this maybe is because only of a smaller
>> user base or not.
>
> I'm sorry, and i hate to argue with people, but this last statement
> just doesn't fly with me. security alerts are the result of someone
> finding a security problem and reporting it. The fact that fewer
> security alerts exist does _NOT_ mean that konq is more secure. It
> only means it has fewer reported security problems. Now it _could_ be
> that this is because there actually _are_ fewer security problems, but
> it could _also_ be because no one has _found_ or reported
> problems. There's an important distinction there.

The assumption is of course that there is no significant difference in the ratio of reported security issues to discovered security issues, and I can't see any reason those should differ.

Do you need more help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.debian.org Links debian-announce debian-apache debian-arm-changes debian-beowulf debian-boot debian-cd debian-cd-vendors debian-changes debian-changes-digest debian-isp debian-kde debian-laptop debian-mirrors-announce debian-news debian-security debian-security-announce debian-testing debian-user debian-user-digest Request more information about Pantek

Anyhow, it is more likely that a browser with more reported security issues have more discovered security issues. And it is also more likely that a browser with more discovered security issues have more security issues. Both, of course, under the assumption that there is no information that changes this.

>
> WARNING! CAR ANALOGY!
>
> if we have two cars parked side-by-side and mine is stolen (I'll
> take the fall for this analogy ;) and yours is not, does that mean
> that your car is more secure? no. it means someone looked for a way
> into my car and exploited it. maybe they never even looked at your

It also mean that it is more likely that your car is less secure. It is not much data to do reliable statistics on, but since we have some data and it points towards your car being less secure, that would also be the best guess. It may not be the correct guess, but it will be the best guess. Let's say we have 10 cars of type A parked along 10 cars of type B, and there is 8 stolen cars of type A and only one of type B. Then you should guess, if no more information was available, that car type A was less secure.
If you have 10 cars of type A and 5 of type B and 2 A cars, and one B car was stolen, you should guess, if no more information was available, that the cars were about equally secure. No, if you have 10 A cars, and 5 B cars, and 1 A car was stolen and 4 B cars, you should guess that the B cars were less secure.
Now, if you have x A cars and y B cars and you don't know x and y, but you know that more A cars are stolen, it is more likely that the A cars are less secure, since there is no reason to believe that x is larger than y, than believing the opposite.

> END CAR ANALOGY!
>
> a more pertinent fake example.
>
> programmer X finds a security hole in konq that when visiting a
> carefully crafted website, allows remote execution of code, privilege
> escalation and ultimately results in a box getting
> rooted. okay. that's obviously a security problem. but programmer X
> doesn't report this problem and no security alert is issued.
>
> programmer Y finds a security hole in mozilla that allows an already
> installed plugin at a certain version to escalate its own privileges and as a result
> download and save a piece of code to disk with the name
> "execute_me". Now if the user happens to see that file and thinks,
> hmmm... I wonder what that is and executes it (after chmod +x) it does
> a rm -rf on their home. programmer y reports this security hole and a
> security alert is made detailing the problem.
>
> now, clearly, the konq vulnerability is *much* more of a security risk
> than the mozilla error, right? the mozilla one requires the plugin be
> already installed and the right version and then requires the user to
> actually chmod and execute the thing. the konq one just requires the
> user to visit a carefully crafted website.

If this would be the case in the mozilla vs konq situation, you have to explain to me why:
1) konq security issues should be reported at a lower ratio 2) why security issues in konq are more severe eg. why there should be reason to believe that there is a statistically significant bias between the browsers in factors such as reporting security issues and severity of security issues.

I can see no reason to believe one or the other. I just look at the facts - there are less security issues reported for konq. The only reasonable conclusion is that konq is more secure.

> but based on what you've written above, because the mozilla one was
> reported, then mozilla is less secure than konq. that doesn't add
> up. And in fact, in my fake example above, the lack of security alert
> makes konq even more of a security problem because 1) the right devs
> might not know about the problem to issue a patch and 2) the public
> doesn't know about the problem to avoid it until a patch comes along.

As I stated above, you have to explain how this constructed example could have any impact at all on the real mozilla vs konq case.

Can we help you?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.debian.org Links debian-announce debian-apache debian-arm-changes debian-beowulf debian-boot debian-cd debian-cd-vendors debian-changes debian-changes-digest debian-isp debian-kde debian-laptop debian-mirrors-announce debian-news debian-security debian-security-announce debian-testing debian-user debian-user-digest Request more information about Pantek

Do you really mean that there is some sort of bias in how security issues are reported and that this is to the advantage of firefox?

As I said, if it is a fact that there is fewer security alerts in konq, the only reasonable conclusion is that konq has less security issues. All other conclusions rely on some sort of asymmetry between the browsers, for example when it comes to the severity of the reported security issues, the presumed not found or not reported security issues, in the the ratio of reported found security issues etc. If you don't have any facts supporting such kind of asymmetry, you can't argue that there exist such asymmetry, and especially you can't argue that such asymmetry is to the advantage of Firefox (it could just as likely be to the advantage of konq - if it existed).

> A

/erik

End of debian-user-digest Digest V2007 Issue #2035