[SOLVED] Confused with partition completely crazy

Nick-us · 09-03-2019, 12:43 PM

I would like to understand why this information is so wrong and confusing

I use Slackware64-Current.
It is installed on sda6
sda1 is completely empty

But the command below reports everything wrong, showing that sda1 is mounted

Code:

bash-4.4# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 931.5G  0 disk 
├─sda1   8:1    0    40G  0 part /
├─sda2   8:2    0    10G  0 part [SWAP]
├─sda3   8:3    0   100G  0 part 
├─sda4   8:4    0     1K  0 part 
├─sda5   8:5    0 761.5G  0 part /mnt/dados
└─sda6   8:6    0    20G  0 part 
sr0     11:0    1  1024M  0 rom  
bash-4.4#

Even gparted reports it wrong

I'm not crazy! And I know exactly what I'm saying! sda1 is completely empty! And my system is on sda6

And to be absolutely sure of that I run a LiveCD to check the partitions

Can anyone help me explain what is going on? Because this completely wrong and crazy information creates confusion.

Below my lilo that may serve to clarify

Code:

append=" vt.default_utf8=1"

boot = /dev/sda

compact
lba32

bitmap = /boot/image.bmp
bmp-colors = 0,171,0,0,171,0
bmp-table = 1,2,1,16
bmp-timer = none

prompt

change-rules
  reset

vga=0x37F

image = /boot/vmlinuz
  root = /dev/sda6
  label = Linux
  read-only

other = /dev/sda3
  label = Win10
  table = /dev/sda

Labinnah · 09-03-2019, 12:53 PM

Show output of this commands:

Code:

sfdisk -d /dev/sda
mount
cat /etc/fstab

Alien Bob · 09-03-2019, 02:04 PM

Looks like perhaps there is an earlier installation of Slackware on that computer and you booted into that one.

If you re-installed to /dev/sda6 and forgot to run the command "lilo" then the lilo which is installed into the MBR may still be booting your older installation of Slackware from /dev/sda1 .

Nick-us · 09-03-2019, 03:00 PM

Quote:

Originally Posted by Labinnah

Show output of this commands:

Code:

sfdisk -d /dev/sda
mount
cat /etc/fstab

Code:

bash-4.4# sfdisk -d /dev/sda
label: dos
label-id: 0xcb83e875
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=    83886080, type=83
/dev/sda2 : start=    83888128, size=    20971520, type=82
/dev/sda3 : start=   104859648, size=   209715200, type=7, bootable
/dev/sda4 : start=   314574848, size=  1638944768, type=5
/dev/sda5 : start=   314576896, size=  1596999680, type=83
/dev/sda6 : start=  1911578624, size=    41940992, type=83
bash-4.4#

Code:

bash-4.4# mount
/dev/sda1 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sda5 on /mnt/dados type ext4 (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
vmware-vmblock on /var/run/vmblock-fuse type fuse.vmware-vmblock (rw,nosuid,nodev,default_permissions,allow_other)
gvfsd-fuse on /home/hcs/.gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,user=hcs)
bash-4.4#

Code:

bash-4.4# cat /etc/fstab
#device-spec     mount-point      fs-type     options        dump pass

#LABEL=swap      swap             swap        defaults         0   0
/dev/sda2        swap             swap        defaults         0   0

/dev/sda1        /                ext4        defaults         0   1
#LABEL=sda1      /                ext4        defaults         0   1
#LABEL=Old       /                ext4        defaults         0   1

LABEL=dados      /mnt/dados       ext4        defaults         0   1

#LABEL=C3        /mnt/C3          ext4        defaults         0   2
#LABEL=280G      /mnt/280Gb       ext4        defaults         0   2
#LABEL=Seagate   /mnt/Seagate     ntfs-3g     defaults         0   2
#LABEL=Win10     /mnt/Win10       ntfs-3g     defaults         0   2

devpts           /dev/pts         devpts      gid=5,mode=620   0   0
proc             /proc            proc        defaults         0   0
tmpfs            /dev/shm         tmpfs       defaults         0   0
bash-4.4#

Looking at my fstab, I wondered if this could be his fault?
Understand that sda1 is completely empty. There is no other system installed, or file rest on sda1.

Nick-us · 09-03-2019, 03:04 PM

Quote:

Originally Posted by Alien Bob

Looks like perhaps there is an earlier installation of Slackware on that computer and you booted into that one.

If you re-installed to /dev/sda6 and forgot to run the command "lilo" then the lilo which is installed into the MBR may still be booting your older installation of Slackware from /dev/sda1 .

sda1 is 100% empty. There is no rest of installation.
I really saw that fstab is kind of wrong. That's because I completely moved the installation from sda1 to sda6. Erasing sda1 completely.

And of course, I had to run lilo to make it work on sda6.
Curious is that fstab was spelled wrong and I didn't get any error messages for it, and the system still loads.

I did not understand why the lack of error message, and why it works!

Nick-us · 09-03-2019, 03:08 PM

What I could understand with the idea of Labinnah

Although lilo was registered in sda6 and the system is in sda6
fstab is mounting the / on sda1
I think creating a link in sda1 to sda6
Well crazy what happened

Labinnah · 09-03-2019, 03:13 PM

I suspect you can have wrong entry in /etc/fstab. Root partition entry, in fact, ins't used to mount it. It is done on boot from "root" kernel parameter. Run "df" and compare sizes of "/" mount point and partitions. sda1 and sda6 differs in size so you can have clean answer.

Didier Spaier · 09-03-2019, 03:20 PM

Maybe for some reason the partitions got renamed after lilo was run, but the boot sector in the MBR was not affected, and the root partition that was name sda6 when you ran lilo is now named sda1.

I don't think that /dev/sda1 be empty as else your system wouldn't work at all.

Ads suggested by Labinnah please tell us what says (typed from the running system)

Code:

df -h

Nick-us · 09-03-2019, 03:21 PM

Quote:

Originally Posted by Labinnah

I suspect you can have wrong entry in /etc/fstab. Root partition entry, in fact, ins't used to mount it. It is done on boot from "root" kernel parameter. Run "df" and compare sizes of "/" mount point and partitions. sda1 and sda6 differs in size so you can have clean answer.

Yes, when you asked to see fstab, it was the first thing I noticed. Because on fstab I reported the mount point on sda1.
I fixed this (for sda6) and it was obviously normal.

I just didn't understand how the system worked normally without errors. Because I only discovered the problem when I wanted to mount sda1 and saw that it was mounted strangely

Nick-us · 09-03-2019, 03:26 PM

Quote:

Originally Posted by Didier Spaier

Maybe for some reason the partitions got renamed after lilo was run, but the boot sector in the MBR was not affected, and the root partition that was name sda6 when you ran lilo is now named sda1.

I don't think that /dev/sda1 be empty as else your system wouldn't work at all.

Ads suggested by Labinnah please tell us what says (typed from the running system)

Code:

df -h

Code:

bash-4.4# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        20G   15G  3.8G  80% /
devtmpfs        3.9G     0  3.9G   0% /dev
tmpfs            32M  1.3M   31M   5% /run
tmpfs           3.9G   40K  3.9G   1% /dev/shm
cgroup_root     8.0M     0  8.0M   0% /sys/fs/cgroup
/dev/sda5       749G  582G  129G  82% /mnt/dados
bash-4.4#

This is what shows in the wrong fstab state. That is when I asked the question here. Remembering that there is nothing, no file in sda1

In his command, I also noticed that the information he gives of size and etc is from sda6 and not from sda1.
sda1 is 40Gb and not 20Gb

Nick-us · 09-03-2019, 03:30 PM

Quote:

Originally Posted by Didier Spaier

Maybe for some reason the partitions got renamed after lilo was run, but the boot sector in the MBR was not affected, and the root partition that was name sda6 when you ran lilo is now named sda1.

When I run lilo in this case, I always run the partition that will be used, and in this case it was from sda6. He did not report any errors.

Quote:

I don't think that /dev/sda1 be empty as else your system wouldn't work at all.

I thought so too. For me it should not work the system, and precisely because it worked without presenting any error msg I did not realize.

The only explanation I believe it to be is that fstab just created a link. I don't know exactly how it worked! The fact is that fstab being wrong should not usually work

Labinnah · 09-03-2019, 03:35 PM

Quote:

Originally Posted by Nick-us

I just didn't understand how the system worked normally without errors.

As this entry ins't used for "real mounting" is no matter what you put there. System starts normal, but some tools may show garbage output as they expect correct value. If rc.S wasn't expect to found this entry, system will be start even without it (I've test lately both cases, by accident

).

Nick-us · 09-03-2019, 03:36 PM

With all the above information.
Could anyone explain how what happened was possible?
Did fstab really link from sda1 to sda6?
I know we solved the problem by finding the error in fstab. But I just would like to understand what happened.

Firerat · 09-03-2019, 04:16 PM

Quote:

Originally Posted by Nick-us

With all the above information.
Could anyone explain how what happened was possible?
Did fstab really link from sda1 to sda6?
I know we solved the problem by finding the error in fstab. But I just would like to understand what happened.

When did you gen. the initrd?
is that mounting / ?

Edit: ah, no initrd

enorbet · 09-03-2019, 04:19 PM

I wonder if this is the cause (emboldened)...

Code:

boot = /dev/sda

compact
lba32

bitmap = /boot/image.bmp
bmp-colors = 0,171,0,0,171,0
bmp-table = 1,2,1,16
bmp-timer = none

prompt

change-rules
  reset

vga=0x37F

image = /boot/vmlinuz
  root = /dev/sda6
  label = Linux
  read-only

other = /dev/sda3
  label = Win10
  table = /dev/sda