Hi,

I would like to specify to linux kernel (within booting process) NOT to try to mount some specific partition , identified by PARTUUID.

I am trygin to figure out how to avoid of errors like the following:
>>>WARNING<<< Wrong ufstype may corrupt your filesystem, default is ufstype=old

Thank You,
Kind Regards,
Martin

P.S. I have been trying to do it as well in /etc/fstab but NO success.
"PARTUUID=362fe8a3-dd4c-416c-94e5-5d521f23d48a none none none 0 0"

The kernel tries to mount only the root partition afaik whatever partition is given as argument root=..., automatic mounting of other partition must be defined elsewhere

OK , So, if I see the following in the "syslog" reporting by kernel:

Sep 22 23:10:30 ARIVUBU kernel: [75857.796879] scsi 27:0:0:0: Direct-Access WD 3200JB External 0112 PQ: 0 ANSI: 0
Sep 22 23:10:30 ARIVUBU kernel: [75857.797264] sd 27:0:0:0: Attached scsi generic sg12 type 0
Sep 22 23:10:30 ARIVUBU kernel: [75857.797436] sd 27:0:0:0: [sdj] 625142448 512-byte logical blocks: (320 GB/298 GiB)
Sep 22 23:10:30 ARIVUBU kernel: [75857.800386] sd 27:0:0:0: [sdj] Write Protect is off
Sep 22 23:10:30 ARIVUBU kernel: [75857.803326] sd 27:0:0:0: [sdj] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Sep 22 23:10:30 ARIVUBU kernel: [75857.813042] sdj: sdj1
Sep 22 23:10:30 ARIVUBU kernel: [75857.839114] sd 27:0:0:0: [sdj] Attached SCSI disk
Sep 23 00:21:16 ARIVUBU kernel: [80103.383887] FAT-fs (sdf1): Can't find a valid FAT filesystem
Sep 23 00:21:16 ARIVUBU kernel: [80103.387512] XFS (sdf1): Invalid superblock magic number
Sep 23 00:21:16 ARIVUBU kernel: [80103.389371] FAT-fs (sdf1): Can't find a valid FAT filesystem
Sep 23 00:21:16 ARIVUBU kernel: [80103.391811] VFS: Can't find a Minix filesystem V1 | V2 | V3 on device sdf1.
Sep 23 00:21:16 ARIVUBU kernel: [80103.392922] hfsplus: unable to find HFS+ superblock
Sep 23 00:21:16 ARIVUBU kernel: [80103.394737] You didn't specify the type of your ufs filesystem
Sep 23 00:21:16 ARIVUBU kernel: [80103.394737]
Sep 23 00:21:16 ARIVUBU kernel: [80103.394737] mount -t ufs -o ufstype=sun|sunx86|44bsd|ufs2|5xbsd|old|hp|nextstep|nextstep-cd|openstep ...
Sep 23 00:21:16 ARIVUBU kernel: [80103.394737]
Sep 23 00:21:16 ARIVUBU kernel: [80103.394737] >>>WARNING<<< Wrong ufstype may corrupt your filesystem, default is ufstype=old
Sep 23 00:21:16 ARIVUBU kernel: [80103.395006] ufs_read_super: bad magic number
Sep 23 00:21:16 ARIVUBU kernel: [80103.396146] hfs: can't find a HFS filesystem on dev sdf1
Sep 23 00:21:16 ARIVUBU kernel: [80103.983732] FAT-fs (sdg1): Can't find a valid FAT filesystem
Sep 23 00:21:16 ARIVUBU kernel: [80103.990540] XFS (sdg1): Invalid superblock magic number
Sep 23 00:21:16 ARIVUBU kernel: [80103.994680] FAT-fs (sdg1): Can't find a valid FAT filesystem
Sep 23 00:21:16 ARIVUBU kernel: [80103.998991] VFS: Can't find a Minix filesystem V1 | V2 | V3 on device sdg1.
Sep 23 00:21:16 ARIVUBU kernel: [80104.000680] hfsplus: unable to find HFS+ superblock
Sep 23 00:21:16 ARIVUBU kernel: [80104.003510] You didn't specify the type of your ufs filesystem
Sep 23 00:21:16 ARIVUBU kernel: [80104.003510]
Sep 23 00:21:16 ARIVUBU kernel: [80104.003510] mount -t ufs -o ufstype=sun|sunx86|44bsd|ufs2|5xbsd|old|hp|nextstep|nextstep-cd|openstep ...
Sep 23 00:21:16 ARIVUBU kernel: [80104.003510]
Sep 23 00:21:16 ARIVUBU kernel: [80104.003510] >>>WARNING<<< Wrong ufstype may corrupt your filesystem, default is ufstype=old
Sep 23 00:21:16 ARIVUBU kernel: [80104.003840] ufs_read_super: bad magic number
Sep 23 00:21:16 ARIVUBU kernel: [80104.005520] hfs: can't find a HFS filesystem on dev sdg1
Sep 23 00:21:17 ARIVUBU kernel: [80104.282864] FAT-fs (sdi1): Can't find a valid FAT filesystem
Sep 23 00:21:17 ARIVUBU kernel: [80104.288341] XFS (sdi1): Invalid superblock magic number
Sep 23 00:21:17 ARIVUBU kernel: [80104.290282] FAT-fs (sdi1): Can't find a valid FAT filesystem
Sep 23 00:21:17 ARIVUBU kernel: [80104.293674] VFS: Can't find a Minix filesystem V1 | V2 | V3 on device sdi1.
Sep 23 00:21:17 ARIVUBU kernel: [80104.294927] hfsplus: unable to find HFS+ superblock
Sep 23 00:21:17 ARIVUBU kernel: [80104.296703] You didn't specify the type of your ufs filesystem
Sep 23 00:21:17 ARIVUBU kernel: [80104.296703]


HOW to tell to the kernel NOT to try to mount those specific partitions (in /etc/fstab) ?

--- I would like to have something like this in /etc/fstab ... IF it helps me ??? (which I did not try it yet)
PARTUUID=5bc5b355-ba9c-41d4-9d4a-d050d5850783 none /dev/null nobootwait,noauto 0 0 # LABEL=7
PARTUUID=362fe8a3-dd4c-416c-94e5-5d521f23d48a none /dev/null nobootwait,noauto 0 0
PARTUUID=5a780875-01 none /dev/null nobootwait,noauto 0 0
PARTUUID=02366c55-01 none /dev/null nobootwait,noauto 0 0
PARTUUID=362fe8a3-dd4c-416c-94e5-5d521f23d48a none /dev/null nobootwait,noauto 0 0

I don't see any relevant option in kernel parameters...
https://www.kernel.org/doc/Documenta...parameters.txt

Did you try to remove the unwanted partions lines from /etc/fstab?

Well, I did not find any relevant kernel parameter/s either. (That's why I put the question here :-))
I did not have to remove thouse partitions from /etc/fstab - they were not there. (I put it there today so when I restart the OS instance - will see what is going to happened ?)
(Those partition/s are mostly encrypted by truecrypt or are grub-bios or are unformatted. Well, Those partitions encrypted by truecrypt I am scared of the most. If something bad happened to those partitions/disks ... .)
Do not know why those partitions kernel has tried to mount (by filesystem type guessing) ... if appearently there is no filesystem (and won't be :-))
I have always thought that if partition is not in /etc/fstab it stayed untouched [except what is defined in "linux /vmlinuz root="]. And even that it must be defined in /etc/fstab / otherwise it is going to boot into initramfs.

Maybe investigate some udev rules is the way to go. I don't have experience with this but maybe there are some rules that can be used to blacklist some partitions numbers

Well, After computer restarted today I did not find those errors again. I went through all any potential log files and did not find any sign of it. Tried to mount some partition by truecrypt and seems it is ok. So, maybe /etc/fstab is sufficient to manage it. But I am not going to mark this thread as solved until I will be more sure /etc/fstab helped.
I have read some udev manual as well but there is info that kernel is passing its disks findings to udev - not vice versa. So, I am little bit in a doubt that udev would helped. But maybe ... .

Well udev is responsible to create devices files on the fly in /dev (sdj, sdf, sdg...), if there is no device file, there is nothing to try to mount

Well, I have to look into udev because those errors appeared again even quite after couple of hours of running OS instance. So, I am back in track I guess.

I installed 8 amd64 in a virtual machine with just /(sda1) and swap (sda5). Have not changed anything and no indication that it is trying to mount sda2. Have you changed anything from the initial installation?

Hu... original installation was with squeeze or lenny... a few years ago. So many things have changed since that.
I found this behaviour when I looked at the logs in order to fix some other trouble with the last upgrade.