Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #183896 > unrolled thread

Installation of debian/stretch 32-bit error

Back to article view | Back to linux.debian.user

Contents

  Installation of debian/stretch 32-bit error Hans <hans.ullrich@loop.de> - 2017-07-19 18:20 +0200
    Re: Installation of debian/stretch 32-bit error "Thomas Schmitt" <scdbackup@gmx.net> - 2017-07-19 18:50 +0200
    Re: Installation of debian/stretch 32-bit error Steve McIntyre <steve@einval.com> - 2017-07-19 18:50 +0200
      Re: Installation of debian/stretch 32-bit error Hans <hans.ullrich@loop.de> - 2017-07-19 19:00 +0200
        Re: Installation of debian/stretch 32-bit error "Thomas Schmitt" <scdbackup@gmx.net> - 2017-07-19 19:40 +0200
          Re: Installation of debian/stretch 32-bit error Hans <hans.ullrich@loop.de> - 2017-07-19 20:30 +0200
        Re: Installation of debian/stretch 32-bit error Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-07-19 20:20 +0200
        Re: Installation of debian/stretch 32-bit error Felix Miata <mrmazda@earthlink.net> - 2017-07-19 21:00 +0200
          Re: Installation of debian/stretch 32-bit error Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-07-20 00:50 +0200
            Re: Installation of debian/stretch 32-bit error Felix Miata <mrmazda@earthlink.net> - 2017-07-20 02:00 +0200
              Re: Installation of debian/stretch 32-bit error Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-07-20 23:00 +0200
              Re: Installation of debian/stretch 32-bit error David Wright <deblis@lionunicorn.co.uk> - 2017-07-21 03:00 +0200

#183896 — Installation of debian/stretch 32-bit error

Hello,

I tried to install debian 9 on an older computer with an IDE hdd. The 
installation went fine, until the installer wantet to install grub into the 
mbr.

The problem: The installer sees the drive as /dev/sda and not, as it should 
be, as /dev/hda.

Then I tried to install the bootloader using TRK (Trinity Rescue Kit), this 
sees the drive as /dev/hda, but is telling me, that it can not be mounted due 
to false tags.

My last installation on an IDE drive is very long ago, so Imight have missedf 
some changes. And afterwards, I was only using scsi and sata drives, so this 
issue never appeared.

Is this issue known at all?

Best

Hans

[toc] | [next] | [standalone]

#183897

Hi,

Hans wrote:
> I tried to install debian 9 on an older computer with an IDE hdd. The 
> installation went fine, until the installer wantet to install grub into the 
> mbr.
> [...]
> Is this issue known at all?

The chances for recognition increases if tangible info is given.
E.g. original messages and the situation in which you end up.


> The problem: The installer sees the drive as /dev/sda and not, as it should 
> be, as /dev/hda.

What in particular indicates that the naming change from /dev/hdX to
/dev/sdN is the reason for the failure ?

According to
  http://www.tldp.org/HOWTO/Partition-Mass-Storage-Definitions-Naming-HOWTO/x99.html
this happened in 2007 when the SATA driver swallowed the IDE driver.
(I dimly remember the name "libata" from times of kernel 2.6.)


> TRK (Trinity Rescue Kit) [...]
> sees the drive as /dev/hda, but is telling me, that it can not be mounted
> due to false tags.

Maybe this has the same cause as the problem with Debian 9 ?

I wonder what might be a "false tag" in the context of which program.
(As said, a few original messages would beautify your re-narration.)

The kernel of TRK must be quite old if it still uses /dev/hdX.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#183898

Hans wrote:
>
>I tried to install debian 9 on an older computer with an IDE hdd. The 
>installation went fine, until the installer wantet to install grub into the 
>mbr.
>
>The problem: The installer sees the drive as /dev/sda and not, as it should 
>be, as /dev/hda.
>
>Then I tried to install the bootloader using TRK (Trinity Rescue Kit), this 
>sees the drive as /dev/hda, but is telling me, that it can not be mounted due 
>to false tags.
>
>My last installation on an IDE drive is very long ago, so Imight have missedf 
>some changes. And afterwards, I was only using scsi and sata drives, so this 
>issue never appeared.

The hdX naming scheme went away a long time ago - all normal disks
should be showing us as sdX whether they're connected via IDE (PATA),
SATA, SCSI or whatever.

Did the installer actually fail to install the bootloader? If so, what
errors did you get?

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"You can't barbecue lettuce!" -- Ellie Crane

[toc] | [prev] | [next] | [standalone]

#183899

Hi Steve,

> The hdX naming scheme went away a long time ago - all normal disks
> should be showing us as sdX whether they're connected via IDE (PATA),
> SATA, SCSI or whatever.
> 
> Did the installer actually fail to install the bootloader? If so, what
> errors did you get?

The text gui offered me MBR, /dev/sda1 (mounted to /boot) and /dev/sda5 
(mounted to /), then I choose mbr and got a red screen, with the very useful 
information "The grub bootloader could not be installed". 

But besides, as now is only /dev/sda, and /dev/hda is no more used, we shoud 
close this issue. No one (except me) will install debian 9 on an IDE drive 
nowadays! 

I wanted just to know, if this is a bug with the "false" naming or unknown. 

Now we know, this is wanted to, so no need to think over again.

Thank you very much for the information and the help!

Best regards

Hans

[toc] | [prev] | [next] | [standalone]

#183901

Hi,

Hans wrote:
> No one (except me) will install debian 9 on an IDE drive nowadays! 

That's not the point. IDE drives are still supported. But they appear
as /dev/sdN rather than as /dev/hdX.

IDE is well practiced, because the man pages of qemu-system-i386
and qemu-system-x86_64 say:

    The QEMU PC System emulator simulates the following peripherals:
    ...
     -   2 PCI IDE interfaces with hard disk and CD-ROM support
    ...

I.e. all qemu -hda or -cdrom devices are handled by the kernel on
the virtual machine as IDE hardware.


The problem is with GRUB's refusal or failure to accept the disk in
the state it is.

What do you get as output if you run on the rescue system:

  fdisk -lu /dev/hda


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#183906

Hi Thomas, 
> The problem is with GRUB's refusal or failure to accept the disk in
> the state it is.
> 
> What do you get as output if you run on the rescue system:
> 
>   fdisk -lu /dev/hda
> 
> 
I am sorry, that I will not be able to check this out any more. As it was not 
my computer, I installed as a solution "Knoppix" on it. The computer is 
intended for the kids of my neighbour (9 and 12 years old) and on this old 
hardware I did not want install windows on it (in fact I never want to install 
windows!!!) so I thought it a good idea, to introduce the kids with linux.

So far, Knoppix is running well, and they will learn using linux with it.

Thanks for any help, but the problem for now can bee seen as solved.
 
Best regards

Hans

> Have a nice day :)
> 
> Thomas

[toc] | [prev] | [next] | [standalone]

#183903

Le 19/07/2017 à 18:58, Hans a écrit :
> 
> The text gui offered me MBR, /dev/sda1 (mounted to /boot) and /dev/sda5
> (mounted to /), then I choose mbr and got a red screen, with the very useful
> information "The grub bootloader could not be installed".

You can get more useful information in the installer log console (one of 
the ttyN virtual consoles), or in the installer logs in /var/log.

[toc] | [prev] | [next] | [standalone]

#183910

Hans composed on 2017-07-19 18:58 (UTC+0200):

>> The hdX naming scheme went away a long time ago - all normal disks
>> should be showing us as sdX whether they're connected via IDE (PATA),
>> SATA, SCSI or whatever.

>> Did the installer actually fail to install the bootloader? If so, what
>> errors did you get?

> The text gui offered me MBR, /dev/sda1 (mounted to /boot) and /dev/sda5 
> (mounted to /), then I choose mbr and got a red screen, with the very useful 
> information "The grub bootloader could not be installed". 

On an old PATA disk, as you call IDE or hda, the partitioning scheme is very
likely the cause of the failure to install to sda, as such schemes can more
frequently than we'd like provide insufficient room on the boot track to fit
Grub2's bloated loader code. Among such schemes, the one producing the largest
boot track space via 255 head and 63 sector "cylinders", a bit over 30kb, is not
always adequate. 240/63, another very common configuration, mostly used by
laptops and Compaq desktops, obviously provides even less.

> But besides, as now is only /dev/sda, and /dev/hda is no more used, we shoud 
> close this issue. No one (except me) will install debian 9 on an IDE drive 
> nowadays! 

Not true. I have several Stretch installations on PATA disks. It is only the
/dev/hdX nomenclature that went away many moons ago.

> I wanted just to know, if this is a bug with the "false" naming or unknown. 

The kernel has been using /dev/sdX for /all/ ATA devices for at least the past 8
years, maybe more than 10 by now.

> Now we know, this is wanted to, so no need to think over again.

If losing data is not a problem for you, the PATA disk, just like any SATA disk,
can be repartitioned with large (1MB) unpartitioned space at start of disk so
that Grub2 can fit into the boot track.

Alternatively, install bootloader into a primary partition, set that partition
active/bootable, and use standard MBR code.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#183937

Le 19/07/2017 à 20:54, Felix Miata a écrit :
> 
> On an old PATA disk, as you call IDE or hda, the partitioning scheme is very
> likely the cause of the failure to install to sda, as such schemes can more
> frequently than we'd like provide insufficient room on the boot track to fit
> Grub2's bloated loader code. Among such schemes, the one producing the largest
> boot track space via 255 head and 63 sector "cylinders", a bit over 30kb, is not
> always adequate. 240/63, another very common configuration, mostly used by
> laptops and Compaq desktops, obviously provides even less.

IME, 31 KiB is still enough to contain a core image when not needing 
costly features such as btrfs, LVM or RAID support.

Anyway, the Debian installer calls grub-install with the --force option 
so that if embedding in the post-MBR area is not possible, the core 
image will be stored as a regular file in /boot and accessed using block 
lists unless the filesystem does not support it. AFAIK, only btrfs is 
not supported with this setup, and a separate /boot is very unlikely to 
use btrfs.

[toc] | [prev] | [next] | [standalone]

#183941

Pascal Hambourg composed on 2017-07-20 0:40 (UTC+0200):

> Felix Miata composed:

>> ...is not
>> always adequate. 240/63, another very common configuration...

> IME, 31 KiB is still enough to contain a core image when not needing 
> costly features such as btrfs, LVM or RAID support.

That's what "not always adequate" means. Partitioning with less than 63 SPT
isn't all that unusual on old PATA disks either. And, sometimes those old
configurations have other things using the boot track. Maybe Grub2's installer
rejects using that space if it's not empty of recognizable content?

> Anyway, the Debian installer calls grub-install with the --force option 
> so that if embedding in the post-MBR area is not possible, the core 
> image will be stored as a regular file in /boot and accessed using block 
> lists unless the filesystem does not support it. AFAIK, only btrfs is 
> not supported with this setup, and a separate /boot is very unlikely to 
> use btrfs.

XFS has not the same limitation as BTRFS?
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#184008

Le 20/07/2017 à 01:57, Felix Miata a écrit :
> Pascal Hambourg composed on 2017-07-20 0:40 (UTC+0200):
> 
>> Felix Miata composed:
> 
>>> ...is not
>>> always adequate. 240/63, another very common configuration...
> 
>> IME, 31 KiB is still enough to contain a core image when not needing
>> costly features such as btrfs, LVM or RAID support.
> 
> That's what "not always adequate" means. Partitioning with less than 63 SPT
> isn't all that unusual on old PATA disks either.

Really ? Even amongst my oldest PATA disks (less that 1 GB capacity), I 
could find only one having less than 63 sectors per track.

> And, sometimes those old
> configurations have other things using the boot track. Maybe Grub2's installer
> rejects using that space if it's not empty of recognizable content?

Maybe. Without the complete error message from grub-install we cannot know.

>> Anyway, the Debian installer calls grub-install with the --force option
>> so that if embedding in the post-MBR area is not possible, the core
>> image will be stored as a regular file in /boot and accessed using block
>> lists unless the filesystem does not support it. AFAIK, only btrfs is
>> not supported with this setup, and a separate /boot is very unlikely to
>> use btrfs.
> 
> XFS has not the same limitation as BTRFS?

Well, I don't know. I have never used it. But using XFS for the /boot 
partition seems very unlikely too.

[toc] | [prev] | [next] | [standalone]

#184018

On Wed 19 Jul 2017 at 19:57:57 (-0400), Felix Miata wrote:
> Pascal Hambourg composed on 2017-07-20 0:40 (UTC+0200):
> 
> > Felix Miata composed:
> 
> >> ...is not
> >> always adequate. 240/63, another very common configuration...
> 
> > IME, 31 KiB is still enough to contain a core image when not needing 
> > costly features such as btrfs, LVM or RAID support.
> 
> That's what "not always adequate" means. Partitioning with less than 63 SPT
> isn't all that unusual on old PATA disks either. And, sometimes those old
> configurations have other things using the boot track. Maybe Grub2's installer
> rejects using that space if it's not empty of recognizable content?

My experience is that it says what it is (and works around it):

# grub-install /dev/sda
/usr/sbin/grub-setup: warn: Sector 5 is already in use by ZISD; avoiding it.
This software may cause boot or other problems in future.
Please ask its authors not to store data in the boot track.
Installation finished. No error reported.
# 

Cheers,
David.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web