Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Probable bug in installer formatting (workaround found)

Ask for help with issues regarding the Installations of the Debian O/S.
Post Reply
Message
Author
docduke
Posts: 11
Joined: 2008-09-22 00:54

Probable bug in installer formatting (workaround found)

#1 Post by docduke »

Briefly, I use TeraByte Boot It Bare Metal (BiBM) as my boot manager. The Debian installer reports a non-fatal error, but then refuses to format "/" and continue the install.
Details. I am trying to install Debian 9.5.0 on a 2 TB drive in a Dell computer with an Intel i7 processor. I tried the net install first, then a DVD install, both graphical and non-graphical. They are clearly all using the same script. The drive already has 5 bootable partitions managed by BiBM, and I want to put Debian 9.5.0 in as #6. The partitioner sees 3 primary partitions and a lot of "free space." BiBM is using "embr" disk control, presenting the installer with 3 primary partitions and hiding the rest of the hard drive. The relevant part of the layout appears to the partitioner as follows:

Code: Select all

   pri/log  31.5 GB      FREE SPACE
#1 primary 31.5 GB B f ext4             /
  pri/log 130.1 GB      FREE SPACE
I tell the installer that this is what I want, and press Continue. The installer responds:
The partition /dev/sda1 assigned to / starts at an offset of 2048 bytes from the minimum alignment for this disk, which may lead to very poor performance... Since you are formatting this partition, delete the partition and recreate it in the same position with the same settings. Do you want to return to the partitioning menu? () No () Yes.
If I select "No" I am returned to the partitioner. If I select "Yes" I am returned to the partitioner. If I go back to the installer main menu and try to bypass the partitioner, I am again returned to the partitioner. There appears to be no way to get the partitioner to do its job and move on.
If I go directly to the command prompt option from the main menu, (1) the /target folder does not exist, and the Busybox does not have a formatter. If I follow the quoted advice, it seems likely that the formatter will grab all the "free space" around the deleted partition for itself.
Does anyone have a suggestion how to get around this? What MBR layout is the partitioner looking for? BiBM has given it

Code: Select all

Start End
c  h  s  fs    c  h  s    LBA   Sector
1023 0 1 83h   1023 254 63 3591427140 61432560
The LBA address is exactly 3425*1024*1024. What does the partitioner want?
If there is no workaround for this, where can I find the installer script? Perhaps I can find the branch point for the "No" option in the quote above and redirect it.
Thanks for any help you can give me!
Last edited by docduke on 2018-10-26 03:07, edited 1 time in total.

User avatar
bw123
Posts: 4015
Joined: 2011-05-09 06:02
Has thanked: 1 time
Been thanked: 28 times

Re: Probable bug in installer formatting

#2 Post by bw123 »

I don;t understand what TeraByte Boot It Bare Metal (BiBM) has to do with it, how did you boot the installer? from what media, created by what method?
resigned by AI ChatGPT

docduke
Posts: 11
Joined: 2008-09-22 00:54

Re: Probable bug in installer formatting (workaround found)

#3 Post by docduke »

Boot-It Bare Metal (BiBM) is a boot manager. It is installed from a live CD (or USB).

I ran it to lay out the hard drive. It installs in the MBR and an eMBR partition and lets me create partitions as I wish. I presently have 1 M$ Windows partition, 5 Linux partitions (mostly versions of openSuSE), a Linux swap partition and an NTFS data partition that is shared by all the operating systems. When I boot the computer, BiBM presents me with a menu of all the operating systems. When I select one, it transfers control to that partition. For each Linux OS, I have told Grub to put its boot loader in /dev/sda1. When I select an OS from the menu, BiBM constructs an MBR that tells the OS it has 3 partitions: /dev/sda1 is /, /dev/sda2 is swap and /dev/sda3 is the data partition. When a bootable partition is not found at /dev/sda1, BiBM pauses and instructs me to put the installation media in the DVD drive and boot it.

The workaround is to instead boot SystemRescueCD and use it to format /dev/sda1, in this case as ext4. SysResqCD also notices that the partition does not start where it would prefer, but formats it anyway. When SysResqCD is finished, I again boot the Debian installer and restart the installation. When I get to the partitioner and tell it to treat /dev/sda1 as /, the installer recognizes that it is already formatted, and reports that it will leave the data alone and do the Debian install on this partition without formatting it. The install then proceeds, and completes, normally.

Thanks for your interest. I will enter this issue in the bug tracker, but the workaround should suffice for anyone else who has a similar problem with the installer before it is fixed.

User avatar
bw123
Posts: 4015
Joined: 2011-05-09 06:02
Has thanked: 1 time
Been thanked: 28 times

Re: Probable bug in installer formatting (workaround found)

#4 Post by bw123 »

I don't understand why you think this is a bug in debian installer?
resigned by AI ChatGPT

User avatar
debiman
Posts: 3063
Joined: 2013-03-12 07:18

Re: Probable bug in installer formatting (workaround found)

#5 Post by debiman »

bw123 wrote:I don't understand why you think this is a bug in debian installer?
indeed.

also, i love it when op gives a very detailed description of their perceived Linux problem, but fails to give an adequate description of the most crucial part of the problem - in this case, the esoteric software installed into the MBR. :roll:

but hey, thanks for at least mentioning it.
the typical flow in cases like these is that we don't find out until ~ ten replies in.

p.H
Global Moderator
Global Moderator
Posts: 3049
Joined: 2017-09-17 07:12
Has thanked: 5 times
Been thanked: 132 times

Re: Probable bug in installer formatting (workaround found)

#6 Post by p.H »

I don't think this is related to a specific boot manager. AFAIK, the kernel and system does not care what boot manager is used.
Also, I have seen a post reporting the same error in another Debian forum (and also a Ubuntu forum), so it may well be a Debian installer bug. A common point in both posts was that fdisk reported that the drives had a 512-byte logical sector size and 4096-byte physical sector size, and a weird "optimal" IO/size of 65535*512 bytes.

OP, could you post the output of "fdisk -l" showing the partition table layout, sector and I/O sizes ?

docduke
Posts: 11
Joined: 2008-09-22 00:54

Re: Probable bug in installer formatting (workaround found)

#7 Post by docduke »

Here is the output of fdisk -l:

Code: Select all

Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x034583aa

Device     Boot      Start        End    Sectors  Size Id Type
/dev/sda1  *    3529994580 3591427139   61432560 29.3G 83 Linux
/dev/sda2        614359185  681943184   67584000 32.2G 82 Linux swap / Solaris
/dev/sda3        681955716 3529994579 2848038864  1.3T  7 HPFS/NTFS/exFAT 
Here is the corresponding MBR, as reported by BiBM:

Code: Select all

		 Starting 	 Ending 	
Name 		C 	       H 	S 	FS 	C 	 H 	S 	LBA 	        Sectors
WAAP Active 1023 	0 	1 	83h 	1032 	254 	63 	3529994580 	61432560
WA7P 		1023 	23 	7 	82h 	1032 	254 	63 	614359185 	67584000
WA8P 		1023 	198 	58 	7h 	1032 	254 	63 	681955716 2848038864 
(as close as I can get to aligning the columns). I was incorrect when I stated above that the LBA starting addresses were multiples of 2**20. They are not even multiples of 512. In Python, the remainders are: 3529994580%512 = 340; 614359185%512 = 145 and 681955716%512 = 388. I will post these results with Terabyte and ask them why their partitioner does that.

From the Debian perspective, the question is: Why does the Debian installer have no trouble installing when I use gparted to format the partition, yet it is unable to install (and in fact will not proceed) when it is asked to install on the same partition, when it is not yet formatted?

p.H
Global Moderator
Global Moderator
Posts: 3049
Joined: 2017-09-17 07:12
Has thanked: 5 times
Been thanked: 132 times

Re: Probable bug in installer formatting (workaround found)

#8 Post by p.H »

The optimal I/O size is normal and matches the physical sector size of 4 KiB.
As you noticed, the partitions are not aligned with physical sectors so the installer warning was correct.
I can only guess that the installer does not warn when the unaligned partitions are already formatted because ther is nothing it can do to fix the situation.
The remaining issue is why it goes back to the partitioning menu even regardless of whether you select "yes" or "no". This definitely looks like a bug.
docduke wrote:the /target folder does not exist, and the Busybox does not have a formatter
The installer shell has everything needed to create and format partitions : fdisk, mkfs, parted if you selected it...

docduke
Posts: 11
Joined: 2008-09-22 00:54

Re: Probable bug in installer formatting (workaround found)

#9 Post by docduke »

The installer shell has everything needed to create and format partitions : fdisk, mkfs, parted if you selected it...
I assumed that the list provided by 'help' was exhaustive:

Code: Select all

BusyBox v1.22.1 (Debian 1:1.22.0-19+b3) built-in shell (ash)
Enter 'help' for a list of built-in commands.
~ # help
Built-in commands:
-------------------
         . : [ bg break cd chdir command continue echo eval exec exit
         export false fg getopts hash help history jobs kill let local
         printf pwd read readonly return set shift test times trap true
         type ulimit umask unset wait
~ # fdisk --version
fdisk from util-linux 2.29.2
~ # man fdisk
/bin/sh: man: not found 
Where can one find a list of the non-built-in ash commands?

User avatar
GarryRicketson
Posts: 5644
Joined: 2015-01-20 22:16
Location: Durango, Mexico

Re: Probable bug in installer formatting (workaround found)

#10 Post by GarryRicketson »

Where can one find a list of the non-built-in ash commands?
Does this not contain them ?
https://manpages.debian.org/stretch/ash/ash.1.en.html

And for "busy box":
https://busybox.net/
https://busybox.net/downloads/BusyBox.html
snip-- COMMANDS

Currently available applets include:

[, [[, acpid, addgroup, adduser, adjtimex, ar, arp, arping, ash,
awk, basename, beep, blkid, brctl, bunzip2, bzcat, bzip2, cal, cat,
catv, chat, chattr, chgrp, chmod, chown, chpasswd, chpst, chroot,
chrt, chvt, cksum, clear, cmp, comm, cp, cpio, crond, crontab,
cryptpw, cut, date, dc, dd, deallocvt, delgroup, deluser, depmod,
devmem, df, dhcprelay, diff, dirname, dmesg, dnsd, dnsdomainname,
dos2unix, dpkg, du, dumpkmap, dumpleases, echo, ed, egrep, eject,
env, envdir, envuidgid, expand, expr, fakeidentd, false, fbset,
fbsplash, fdflush, fdformat, fdisk, fgrep, find, findfs, flash_lock,
flash_unlock, fold, free, freeramdisk, fsck, fsck.minix, fsync,
ftpd, ftpget, ftpput, fuser, getopt, getty, grep, gunzip, gzip, hd,
hdparm, head, hexdump, hostid, hostname, httpd, hush, hwclock, id,
ifconfig, ifdown, ifenslave, ifplugd, ifup, inetd, init, inotifyd,
insmod, install, ionice, ip, ipaddr, ipcalc, ipcrm, ipcs, iplink,
iproute, iprule, iptunnel, kbd_mode, kill, killall, killall5, klogd,
last, length, less, linux32, linux64, linuxrc, ln, loadfont,
loadkmap, logger, login, logname, logread, losetup, lpd, lpq, lpr,
ls, lsattr, lsmod, lzmacat, lzop, lzopcat, makemime, man, md5sum,
mdev, mesg, microcom, mkdir, mkdosfs, mkfifo, mkfs.minix, mkfs.vfat,
mknod, mkpasswd, mkswap, mktemp, modprobe, more, mount, mountpoint,
mt, mv, nameif, nc, netstat, nice, nmeter, nohup, nslookup, od,
openvt, passwd, patch, pgrep, pidof, ping, ping6, pipe_progress,
pivot_root, pkill, popmaildir, printenv, printf, ps, pscan, pwd,
raidautorun, rdate, rdev, readlink, readprofile, realpath,
reformime, renice, reset, resize, rm, rmdir, rmmod, route, rpm,
rpm2cpio, rtcwake, run-parts, runlevel, runsv, runsvdir, rx, script,
scriptreplay, sed, sendmail, seq, setarch, setconsole, setfont,
setkeycodes, setlogcons, setsid, setuidgid, sh, sha1sum, sha256sum,
sha512sum, showkey, slattach, sleep, softlimit, sort, split,
start-stop-daemon, stat, strings, stty, su, sulogin, sum, sv,
svlogd, swapoff, swapon, switch_root, sync, sysctl, syslogd, tac,
tail, tar, taskset, tcpsvd, tee, telnet, telnetd, test, tftp, tftpd,
time, timeout, top, touch, tr, traceroute, true, tty, ttysize,
udhcpc, udhcpd, udpsvd, umount, uname, uncompress, unexpand, uniq,
unix2dos, unlzma, unlzop, unzip, uptime, usleep, uudecode, uuencode,
vconfig, vi, vlock, volname, watch, watchdog, wc, wget, which, who,
whoami, xargs, yes, zcat, zcip----snip---

docduke
Posts: 11
Joined: 2008-09-22 00:54

Re: Probable bug in installer formatting (workaround found)

#11 Post by docduke »

bw123, debiman, p.H and Garry Ricketson,
Thanks very much for your time and help with my problem. This is as much time as I wish to devote to it. As I explained above, I have a workaround, using gparted from System Rescue CD.

As a final experiment, I tried installing Debian on another partition, got as far as the partitioner, went back to the menu and fired up BusyBox. I executed "mkfs.ext4 /dev/sda1" returned to the partitioner and found myself still in the same unbreakable loop. I returned to BusyBox and executed "blkid /dev/sda1" to verify that I had indeed formatted the partition as ext4.

I have no idea what is different between mkfs.ext4 formatting in BusyBox and gparted formatting in SystemRescueCD, but this is sufficiently far afield that I am terminating my part of the analysis.

Thanks again for your help!
Duke

p.H
Global Moderator
Global Moderator
Posts: 3049
Joined: 2017-09-17 07:12
Has thanked: 5 times
Been thanked: 132 times

Re: Probable bug in installer formatting (workaround found)

#12 Post by p.H »

docduke wrote:
The installer shell has everything needed to create and format partitions : fdisk, mkfs, parted if you selected it...
I assumed that the list provided by 'help' was exhaustive:
"help" only prints busybox built-in commands.
docduke wrote:Where can one find a list of the non-built-in ash commands?
I'm afraid there is no such list, as the available commands may vary depending on installation options, and maybe architectures.

Post Reply