Re: rebuildfstab question
Dear Klaus,
Wow! That was fast. It looks like all udev add/change/remove events are
now being handled by the more efficient (and much faster) "mode A."
However, "mode A" doesn't ignore extended partitions. Two suggestions:
The original test (scanpartitions: Does /proc/partitions report #blocks <
2?) might be inserted into mode A. I also note that udev sets the
variable:
UDISKS_PARTITION_TYPE=0x05
(I would have expected udev to tell us that the partition has a partition
table, but it does not.)
Now, to my original problem with the new script: I used to be able to
make manual entries to fstab; knoppix would leave those devices alone and
still autoconfigure everything else. Knoppix still won't delete my lines,
but now it appends its own _second_ line for the same device. Which is
the correct behavior?
Best regards,
Andrew
> Hello Andrew,
>
> On Fri, Jul 22, 2011 at 04:33:08AM -0400, Andrew wrote:
>> Dear Klaus et al,
>>
>> This pertains to /usr/sbin/rebuildfstab "Jul 2010" as in v6.4.4.
>>
>> Until recently, Knoppix only added lines to fstab for devices that were
>> not already listed. This behavior seemed intentional and I was making
>> good use of it.
>
> Before the most recent versions, rebuildfstab was rebuilding fstab
> adding _all_ detected block devices on each run, every time a partition
> on a newly inserted device was detected. This was somewhat inefficient,
> because it would re-detect everyting each time a single partition was
> reported via udev.
>
> I changed this behavior so that the environment variables which udev
> provides were evaluated, so only the newly detected or changed partition
> would trigger a one-line change in /etc/fstab (well, two lines including
> the comment).
>
> Since udev also provides file system information using the blkid plugin,
> I was also using that in favor of my own filesystem detection script.
> At least, that was the idea behind the change. ;-)
>
>> I am studying this script because, unfortunately, this is no longer the
>> case. My question pertains to the test which determines the mode of
>> operation:
>>
>> ### We now have two operation modes:
>> ### A) do what udev tells us (add/remove partition entries) if DEVNAME
>> and
>> ACTION is set
>> ### B) scan and add entries automatically
>
> Yes. If called manually (i.e. without udevs environment variables), the
> script works as before, scanning all block devices.
>
>> For my empty cdrom drive, udev calls rebuildfstab with
>> DEVNAME='/dev/sr0'
>> ACTION='change'
>>
>> DEVNAME and ACTION are set, so I expect mode "A", but, the actual test
>> is:
>>
>> if [ -n "$DEVNAME" -a -n "$ID_FS_USAGE" -a -n "$ACTION" ]; then
>>
>> Therefore, because ID_FS_USAGE is not set, it's mode "B" for the cdrom
>> drive. This does not seem correct.
>>
>> When I insert a disk, udev calls rebuildfstab again; this time with
>> ID_FS_USAGE set, and the drive gets mode "A". When I remove the disk,
>> the
>> udev event is handled mode "B".
>>
>> I tried eliminating ID_FS_USAGE from the test, so that it agrees with
>> the
>> description in your comment. It seems to work (See fstab entries
>> below.).
>
> Your proposal is good. My original intention here was to only add
> partitions that contain a detectable/mountable file system, but since
> the old scheme is still being used if the variable is unset, and there
> may be cases where you want to add an entry without knowing the file
> system in advance, there is no gain in checking for ID_FS_USAGE being
> set at that point.
>
>> So, which is the case: (a) detection of blank/absent media/media removal
>> is a udev event and is supposed to be handled mode "A" and this is an
>> error in the script, (b) should be mode "A", but ID_FS_USAGE should be
>> set, so this is an error with udev or my drive, (c) this hybrid behavior
>> is intended?
>
> It's (a), a logical error in the script in case of blank/absent/non-fs
> partitions. I just uploaded a fixed version to
> debian-knoppix.alioth.debian.org. However, the fact that rebuildfstab
> adds lines for blank media (which are not mountable) may still be wrong,
> though in some cases, partitions with filesystems that just require
> additional mount options for being mounted, may be OK to be listed in
> /etc/fstab.
>
> Regards
> -Klaus
>
>
> --
> To UNSUBSCRIBE, email to debian-knoppix-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
> Archive: [🔎] 20110723010942.GL3135@knopper.net">http://lists.debian.org/[🔎] 20110723010942.GL3135@knopper.net
>
>
Reply to: