This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------n0YM8AKYWt16Sl7gbn5aloXS
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

SGVsbG8gbGlzdCwNCg0KSSB3YXMgZ2V0dGluZyB2ZXJ5IHNsb3cgYm9vdCBzcGVlZHMgb24g b2xkIFdZU0UgQzEwTEUgdGhpbiBjbGllbnQgd2l0aCANClZJQSBDNyBDUFUgYW5kIFBob2Vu aXggYmlvcyAoeWVhciAyMDA4KS4gVGhpcyBpcyBkdWUgdG8gY29tYmluYXRpb24gb2YgDQpC SU9TLCBHUlVCLCBhbmQgd2hhdCBJIGFzc3VtZSBEZWJpYW4taW5zdGFsbGVyIGJ1Z3MuDQoN Ckxvbmcgc3Rvcnkgc2hvcnQsIERlYmlhbiB3cml0ZXMgc3RyYW5nZS9pbmNvcnJlY3QgQy9I L1MgdmFsdWVzIHRvIHRoZSANCk1CUiBwYXJ0aXRpb24gdGFibGUgdXBvbiBpbnN0YWxsYXRp b24sIHRvIHdoaWNoIHRlc3RkaXNrIHNvZnR3YXJlIA0KY29tcGxhaW5zIGFzICJCYWQgcmVs YXRpdmUgc2VjdG9yIi4NCg0KSSd2ZSB0cmllZCB0byBpbnN0YWxsIERlYmlhbiAxMiBpMzg2 IHRvIGEgOEcgZGlzaywgdXNpbmcgcWVtdSwgd2l0aCANCmd1aWRlZCBhdXRvbWF0aWMgcGFy dGl0aW9uaW5nLiBUZXN0ZGlzayBkYXRhIHJpZ2h0IGFmdGVyIHRoZSBpbnN0YWxsYXRpb246 DQoNCj4gRGlzayB0ZXN0ei5pbWcgLSA4NTg5IE1CIC8gODE5MiBNaUIgLSBDSFMgMTA0NSAy NTUgNjMNCj4gQ3VycmVudCBwYXJ0aXRpb24gc3RydWN0dXJlOg0KPiAgICAgIFBhcnRpdGlv biAgICAgICAgICAgICAgICAgIFN0YXJ0ICAgICAgICBFbmQgICAgU2l6ZSBpbiBzZWN0b3Jz DQo+IA0KPiAgMSBQIExpbnV4ICAgICAgICAgICAgICAgICAgICAwICAzMiAzMyAgIDkxOSAx OTkgNDggICAxNDc3NDI3Mg0KPiANCj4gQmFkIHJlbGF0aXZlIHNlY3Rvci4NCj4gIDIgRSBl eHRlbmRlZCAgICAgICAgICAgICAgIDkxOSAyMzIgMTYgIDEwNDQgIDUyIDMyICAgIDE5OTY4 MDINCj4gDQo+IEJhZCByZWxhdGl2ZSBzZWN0b3IuDQo+IE5vIHBhcnRpdGlvbiBpcyBib290 YWJsZQ0KPiAgNSBMIExpbnV4IFN3YXAgICAgICAgICAgICAgOTE5IDIzMiAxOCAgMTA0NCAg NTIgMzIgICAgMTk5NjgwMA0KPiANCj4gQmFkIHJlbGF0aXZlIHNlY3Rvci4NCg0KDQpJdCBz ZWVtcyB0aGF0IHRlc3RkaXNrIGF1dG9tYXRpY2FsbHkgcmVjYWxjdWxhdGVzIEMvSC9TIHZh bHVlcyBhbmQgc2hvd3MgDQpjb3JyZWN0ZWQgZGF0YSAoaW4gdGhlIHRhYmxlIGFib3ZlKS4N Cg0KSGVyZSdzIHdoYXQgcmVhbGx5IGlzIHByZXNlbnQgaW4gdGhlIE1CUiAoZGF0YSBvZiB0 aGUgZmlyc3QgcGFydGl0aW9uIA0KZW50cnkpOg0KDQo+ICQgLi9tYnJfbXkucHkgdGVzdHou aW1nIA0KPiBTdGF0dXM6ICAgICAgICAgICAgICAgICAgMHgwDQo+IEMvSC9TIHN0YXJ0OiAg ICAgICAgICAgICA0IDQgMQ0KPiBQYXJ0IHR5cGU6ICAgICAgICAgICAgICAgMHg4Mw0KPiBD L0gvUyBlbmQ6ICAgICAgICAgICAgICAgMTAyMyAyNTQgMg0KPiBMQkEgb2YgZmlyc3Qgc2Vj dG9yOiAgICAgMjA0OA0KPiBTZWN0b3IgY291bnQ6ICAgICAgICAgICAgMTQ3NzQyNzINCg0K DQpmZGlzay9jZmRpc2sgYW5kIHBhcnRlZCBhbGwgY3JlYXRlIHBhcnRpdGlvbnMgZm9yIHdo aWNoIHRlc3RkaXNrIGRvZXMgDQpub3QgY29tcGxhaW4uDQo=

--------------n0YM8AKYWt16Sl7gbn5aloXS--

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEMiogvXcpmS32v71gXNcgLu+I93IFAmSpqFIFAwAAAAAACgkQXNcgLu+I93L2 9A//dWqu/ltTKX8fgQgYKFOoTHxFcxWmGLJLF8OGUXYSxjRNGRAym4KSyKRoiv18vsLc+YvPlQgB B0Tp7bZHtow/YNQNlK2jqy6Irlv5sgy4SCsMPy7Si381YXhOvDeaSBq7O283FBR73M+Or9RJYWSC h+Ww+N6NjIJvobNv5f6p+kxBCdEEKFD3cKJQAHZJf36PdGulAzWR5795FNbcEwltsVNm9g6EQyfZ gfob5RIl/ENFPuCqX6lQEGyKfXuHhwRQNnHKsKFDLk00I4ZMC7EovjDMHat9RLWKbdC5myKZ041j D1ao0WgwozoVIw6PS5mQEBdObHIfKktlnqhZnzV6V3V8seLGwgN/Q2OOgt7VqTRst+0dzpIrSLQg MQAMy+3pNeg9JeALt/BcEH7kHB2teDJoDegy+SaT+HAc36SAx+qdqKwNchdKbg059dxFwBnetI06 Z63HDxVTYLhbOIe4x9m+d6BJUdL/wJ+mbdiB27XyFI/KtWJfhSNvYzkCOYZ6apguibaxYbj79xbG ueUcVsCHfjAlm3T/3OEM5sH4gphX2h9Ou7ImX9n6ch61aKneORvWKOpc9EGpFnRZ/hcJotTbzZsi BCKByzEFMM1tWfQghQjtxUrfmIABB4NwPk2Cm5HjfkP0QoIzUCKeHMZG0fGAh+WJtV8Vux3am9RW rWA=
=ZWEU
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Valdikss,

On Sat, Jul 08, 2023 at 09:17:54PM +0300, ValdikSS wrote:

Hello list,

I was getting very slow boot speeds on old WYSE C10LE thin client with VIA C7 >CPU and Phoenix bios (year 2008). This is due to combination of BIOS, GRUB, >and what I assume Debian-installer bugs.

Long story short, Debian writes strange/incorrect C/H/S values to the MBR >partition table upon installation, to which testdisk software complains as >"Bad relative sector".

Nothing should be caring about C/H/S at all in the 21st century. Using
C/H/S only allows you to access 515MB of disk [1]. *Everything* these
days uses LBA instead.

What makes you think that the BIOS on this old machine cares about
C/H/S? What happens if you tweak the partitioning by hand when
installing?

I've tried to install Debian 12 i386 to a 8G disk, using qemu, with guided >automatic partitioning. Testdisk data right after the installation:

Disk testz.img - 8589 MB / 8192 MiB - CHS 1045 255 63
Current partition structure:
Partition Start End Size in sectors

1 P Linux 0 32 33 919 199 48 14774272

Bad relative sector.
2 E extended 919 232 16 1044 52 32 1996802

Bad relative sector.
No partition is bootable
5 L Linux Swap 919 232 18 1044 52 32 1996800

Bad relative sector.

It seems that testdisk automatically recalculates C/H/S values and shows >corrected data (in the table above).

Here's what really is present in the MBR (data of the first partition entry):

$ ./mbr_my.py testz.img Status: 0x0
C/H/S start: 4 4 1
Part type: 0x83
C/H/S end: 1023 254 2
LBA of first sector: 2048
Sector count: 14774272

fdisk/cfdisk and parted all create partitions for which testdisk does not >complain.

d-i drives parted to make partitions...

[1] https://forums.tomshardware.com/threads/lba-chs-bios-prob.685748/


--
Steve McIntyre, Cambridge, UK. [email protected] "We're the technical experts. We were hired so that management could
ignore our recommendations and tell us how to do our jobs." -- Mike Andrews

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Jul 09, 2023 at 12:15:35AM +0300, ValdikSS wrote:

On 09.07.2023 00:02, Steve McIntyre wrote:

Nothing should be caring about C/H/S at all in the 21st century. Using C/H/S only allows you to access 515MB of disk [1]. *Everything* these
days uses LBA instead.

What makes you think that the BIOS on this old machine cares about
C/H/S?

My machine is old, it's a 32-bit CPU from 2006 in a machine from 2008.

That's sad. My 486 from 1993 uses LBA correctly and doesn't care about
CHS at all. How could a machine from 15 years later when disks much
much bigger than CHS supported possibly care at all?

--
Len Sorensen

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)