Opened 8 years ago

Last modified 8 years ago

#13434 new bug

DriveSetup cannot see Linux partitions

Reported by: danboid Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: Partitioning Systems/Intel Version: R1/Development
Keywords: Linux partitions invisible Cc:
Blocked By: Blocking:
Platform: x86

Description

Haiku 51100 x86 GCC5 on a Dell Inspiron Mini 10 upgraded with a 60GB OCZ AGILITY 4

DriveSetup sees my 60gb SSD but it only ever shows 1 59GB partition. I can format the full drive as one BeFS partition and install Haiku to it OK but DriveSetup fails to see my (intel/MBR) Linux partitions when present - one 27GB XFS root partition and a 2GB swap partition. I created a BeFS partition after the Linux partitions using cfdisk under Linux but DriveSetup/Haiku fails to see that too - it only ever shows 1 partition regardless. At first I thought it might be because Haiku doesn't support XFS but I reformtted it as ext4 (using mkfs -t ext4 ...) but Haiku still failed to see it.

Due to this issue I am unable to dual-boot Haiku with Linux on my netbook because (I believe) BeFS partitions cannot be resized?

Attachments (4)

syslog (143.9 KB ) - added by danboid 8 years ago.
partition prob syslog
fdisk.txt (1.6 KB ) - added by danboid 8 years ago.
parted.txt (398 bytes ) - added by danboid 8 years ago.
syslog.2 (440.1 KB ) - added by danboid 8 years ago.
51115 SSD partition prob syslog

Download all attachments as: .zip

Change History (20)

comment:1 by danboid, 8 years ago

Someone in #haiku suggested I try reformatting the partition as ext2. I have tried that but it has made no difference - Haiku still fails to see any of my partitions.

Note that all the partitions I have created have been primary, MBR partitions.

comment:2 by danboid, 8 years ago

We could (should) change the title of this to "DriveSetup cannot see partitions" because it is not showing BeFS partitions (that are smaller than the full disk) too.

It is a SATA2 drive but I think the machine likely only has a SATA1 controller/interface. The drive works fine under Arch, partitions are visible under fdisk etc.

comment:3 by axeld, 8 years ago

It's probably caused by how the disk has been formatted under Linux. If you are using a MBR or GPT partition table, Haiku should be able to read them correctly. If it cannot read them in your case, we'll need more info to be able to investigate the issue. The least you should do is to attach a syslog from your system with system related bug reports.

Since those include quite a number of info about disk detection, this might already help to find the cause of this issue.

by danboid, 8 years ago

Attachment: syslog added

partition prob syslog

comment:4 by danboid, 8 years ago

patch: 01

by danboid, 8 years ago

Attachment: fdisk.txt added

by danboid, 8 years ago

Attachment: parted.txt added

comment:5 by danboid, 8 years ago

Hi axel

Sorry for not includng the logs!

I've attached the relevant fdisk -l and parted

parted /dev/sda 'unit s print'

output from Linux too.

Thanks

Version 0, edited 8 years ago by danboid (next)

comment:6 by axeld, 8 years ago

Okay, it's probably a duplicate of #12290 -- the disk is recognized as GPT disk. This means you probably have formatted the disk as GPT once which writes two headers: one in the beginning of the disk, and one in the end. You overwrote the first one with an MBR and Linux partition, but the other one is still there.

You can prove that theory by either zeroing out the last MB of the disk (for example using dd if=/dev/zero of=/dev/sb3, but that would delete the entire partition contents), or by copying the last MB to a file, and attaching it to this ticket. The first suggestion should already solve your issue.

comment:7 by danboid, 8 years ago

Hi axel

I have now lent the laptop in question to a friend for a week or so so it could be a few days before I get to try your suggestion.

It sounds like Linux knows to ignore the extraneous GPT headers but Haiku does not as they don't seem to cause probs for the linux partitioning tools. Is that the case? I would've expected DriveSetup to not show any partitions if it was confused between GPT and MBR, rather than one big one.

comment:8 by pulkomandy, 8 years ago

patch: 10

comment:9 by pulkomandy, 8 years ago

patch: 0

Please try with hrev51114.

comment:10 by danboid, 8 years ago

I've just tried 51115 GCC5 and things are worse now, IMO, as now DriveSetup doesn't even show the SSD at all - all I see is the USB drive I'm booting off.

Just about to upload syslog.

by danboid, 8 years ago

Attachment: syslog.2 added

51115 SSD partition prob syslog

comment:11 by danboid, 8 years ago

patch: 1

comment:12 by axeld, 8 years ago

The drive doesn't seem to be visible anymore, but that can't be caused by Adrien's changes. Have you moved the drive to another USB slot? If not, you could try with that. Have you tried rebooting to see if that changes anything?

comment:13 by danboid, 8 years ago

This netbook has 3 USB ports. I have now tried booting 51115 via a USB stick on all three ports but I got the same result under drivesetup each time. Drivesetup shows 2 USB drives - the USB drive I booted off and the SD card reader - but nothing else.

comment:14 by danboid, 8 years ago

How much testing has been done for Haiku with SSDs, especially older (SATA2) ones? I ask as I've noticed Haiku has a lot of room for improvement regarding boot times off SSD and that will apply to NVME too. Haiku boots as fast on a 5400RPM drve as it does a SATA3 SSD so it doesn't seem to be SSD optmized to me yet.

comment:15 by pulkomandy, 8 years ago

Haiku is quite small, it only needs to load a few hundred megabytes from disk and that will easily fit in the RAM cache. So, using an SSD does not make a huge change to boot time. Even with a slow HDD, we only need to read once from it and then we run mostly from RAM. The package system has both negative and positive impact:

  • Positive: because instead of many small files on disk, we only need to read a single large one (the haiku package)
  • Negative: because said package is zlib-compressed, so we spend more time decompressing it (CPU bound) than reading it from disk.

It does make a great difference in things that actually perform a lot of disk IOs: compiling large projects, or running checkfs. For booting, this is not the main bottleneck and there are a lot of other things we could optimize. If you have a serial port, maybe start by disabling serial log from the kernel, usually it is the first contributor to slowing down the boot process.

comment:16 by pulkomandy, 8 years ago

patch: 10
Note: See TracTickets for help on using tickets.