Bug#762399: console-setup: WARNING: Unknown X keysym "permille"
> > If you're going to throw excuses at my face, you may want to have the > > decency of trying to articulate some sentence along with it. If you > > can't be bothered to do so, feel free to avoid adding noise. > > That's a rather pathetic statement, coming from someone who cannot be > bothered with articulating any meaningful message beyond a link to a > changelog news. Wearing my translator's hat: Monsieur Racine: any news? Kibi: yes, a package cleaned from the mess generated by my comaintainers is waiting in unstable M. Racine: so it needs an unblock Kibi: yes, which is part of my duties as D-I release management tasks, which I'll do as I'm always doing when D-I is released. Please let me do my job. (hopefully) M. Racine: OK, then, I'll nag other maintainers until they're also too annoyed by me (dropping out people explicitly CC'ed as all really concerned people are already susbcribed to -boot, being maintainers of console-setup) signature.asc Description: Digital signature
Re: Preseed partman recipe not allocating free lvm space properly
On Sat, Dec 20, 2014 at 08:46:01PM +, ryan wrote:
> On Sat, Dec 20, 2014 at 09:45:32AM +0100, Geert Stappers wrote:
>
> >
> > In other words: I don't understand
> > Subject: Preseed partman recipe not allocating free lvm space properly
>
> Probably could have chosen a better subject.
>
> I read on a blog somewhere that the priorities were actually from low
> numbers to high. First I had read that, but adjusted preseed to the
> following.
>
Well that didn't work, so I thought I'd post some results from the
priorities from high to low. Again only minimum size lvm volumes get
created except for the dummy volume. Which has the lowest priority.
d-i partman-auto/expert_recipe string \
raid-lvm :: \
512 10 512 raid\
$primary{ } $lvmignore{ } $bootable{ } \
method{ raid } \
. \
155000 5 -1 raid \
$primary{ } $lvmignore{ }\
method{ raid } \
. \
1 300 2 ext4 \
$defaultignore $lvmok{ } lv_name{ lv00 } \
method{ format } format{ } \
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ / } \
. \
2 100 10 ext4\
$defaultignore $lvmok{ } lv_name{ lv01 } \
method{ format } format{ } \
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ /home } \
. \
1 200 2 ext4 \
$defaultignore $lvmok{ } lv_name{ lv02 } \
method{ format } format{ } \
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ /var } \
. \
1 200 2 ext4 \
$defaultignore $lvmok{ } lv_name{ lv03 } \
method{ format } format{ } \
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ /usr } \
. \
1 100 1 ext4 \
$defaultignore $lvmok{ } lv_name{ lv04 } \
method{ format } format{ } \
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ /tmp } \
. \
16000 25 32000 linux-swap \
$defaultignore $lvmok{ } lv_name{ lv05 } \
method{ swap } format{ } \
. \
25000 30 5 ext4 \
$defaultignore $lvmok{ } lv_name{ lv06 } \
method{ format } format{ } \
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ /opt } \
. \
5 10 50 ext4 \
$defaultignore $lvmok{ } lv_name{ lv07 } \
method{ format } format{ } \
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ /var/opt } \
. \
512 1 -1 ext4 \
$defaultignore $lvmok{ } lv_name{ deleteme } \
method{ lvm }\
.
Results in
root@test:~# df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 9.2G 292M 8.5G 4% /
udev10M 0 10M 0% /dev
tmpfs 202M 316K 201M 1% /run
/dev/mapper/vg00-lv00 9.2G 292M 8.5G 4% /
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 403M 0 403M 0% /run/shm
/dev/md0 472M 29M 419M 7% /boot
/dev/mapper/vg00-lv01 19G 172M 18G 1% /home
/dev/mapper/vg00-lv06 23G 172M 22G 1% /opt
/dev/mapper/vg00-lv04 9.2G 149M 8.6G 2% /tmp
/dev/mapper/vg00-lv03 9.2G 1.4G 7.4G 16% /usr
/dev/mapper/vg00-lv02 9.2G 298M 8.5G 4% /var
/dev/mapper/vg0
Re: which HSM for secure boot keys
On Sat, Dec 20, 2014 at 10:39:55PM +0100, Cyril Brulebois wrote: >Aaron McSorley (2014-12-19): >> I remember some discussion about how to store the shim keys at >> debconf, and some hardware security module being passed around. I'm >> looking for a recommendation for a HSM for my own shim keys. Was >> there ever a conclusion on how to store the keys for debian, and does >> anyone remember what that little usb HSM was? > >I think you want to contact the DSA team (likely the people knowing >about this): debian-ad...@lists.debian.org Yeah, Tollef was the guy talking about doing this side. Yubikey, maybe? -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141220231638.gn14...@einval.com
Re: Document syntax for X-Debbugs-CC with more than one mail address [ Re: Bug#771607: unblock: brltty/5.2~20141018-2 ]
Hi, Holger Wansing wrote: > Hi, > > Holger Levsen wrote: > > On Montag, 1. Dezember 2014, Samuel Thibault wrote: > > > X-Debbugs-Cc: debian-boot@lists.debian.org > > > X-Debbugs-Cc: debian-accessibil...@lists.debian.org > > > > > > I then guess bts only keep the last one. > > > > seperating them with commas on the same line works. > > Maybe it should be documented on > https://www.debian.org/Bugs/Reporting, how to insert more than one > mail address to a X-Debbugs-Cc: line? > > I have prepared a patch, attached. > > > debian-www in CC. There was a typo in that patch (missing word, "to more than one address"), ^^^ here's a new one: Index: english/Bugs/Reporting.wml === RCS file: /cvs/webwml/webwml/english/Bugs/Reporting.wml,v retrieving revision 1.79 diff -u -r1.79 Reporting.wml --- english/Bugs/Reporting.wml 30 Apr 2014 06:29:26 - 1.79 +++ english/Bugs/Reporting.wml 20 Dec 2014 22:16:09 - @@ -216,6 +216,9 @@ to the address(es) in the X-Debbugs-CC line as well as to debian-bugs-dist. +If you want to sent copies to more than one address, add them +comma-separated in only one X-Debbugs-CC line. + Avoid sending such copies to the addresses of other bug reports, as they will be caught by the checks that prevent mail loops. There is relatively little point in using X-Debbugs-CC for this -- Created with Sylpheed 3.2.0 under D E B I A N L I N U X 7 . 0 W H E E Z Y ! Registered Linux User #311290 - https://linuxcounter.net/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141220232631.3d1aa788b40c52434cbba...@wansing-online.de
Bug#762399: console-setup: WARNING: Unknown X keysym "permille"
2014-12-20 23:58 GMT+02:00 Cyril Brulebois : > Martin-Éric Racine (2014-12-20): >> 2014-12-20 23:41 GMT+02:00 Cyril Brulebois : >> > Martin-Éric Racine (2014-12-17): >> >> Are we anywhere close to a definitive fix on this one? >> > >> > Do you mean this? >> > https://packages.qa.debian.org/c/console-setup/news/20141125T170419Z.html >> >> console-setup (1.114 to 1.116) >> Maintainer: Debian Install System Team >> 24 days old (needed 5 days) >> Not touching package due to block-udeb request by freeze (check >> https://release.debian.org/jessie/freeze_policy.html if update is >> needed) >> Not touching package due to block request by freeze (check >> https://release.debian.org/jessie/freeze_policy.html if update is >> needed) > > If you're going to throw excuses at my face, you may want to have the > decency of trying to articulate some sentence along with it. If you > can't be bothered to do so, feel free to avoid adding noise. That's a rather pathetic statement, coming from someone who cannot be bothered with articulating any meaningful message beyond a link to a changelog news. Martin-Éric -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/debian-boot
Bug#762399: console-setup: WARNING: Unknown X keysym "permille"
Martin-Éric Racine (2014-12-20): > 2014-12-20 23:41 GMT+02:00 Cyril Brulebois : > > Martin-Éric Racine (2014-12-17): > >> Are we anywhere close to a definitive fix on this one? > > > > Do you mean this? > > https://packages.qa.debian.org/c/console-setup/news/20141125T170419Z.html > > console-setup (1.114 to 1.116) > Maintainer: Debian Install System Team > 24 days old (needed 5 days) > Not touching package due to block-udeb request by freeze (check > https://release.debian.org/jessie/freeze_policy.html if update is > needed) > Not touching package due to block request by freeze (check > https://release.debian.org/jessie/freeze_policy.html if update is > needed) If you're going to throw excuses at my face, you may want to have the decency of trying to articulate some sentence along with it. If you can't be bothered to do so, feel free to avoid adding noise. KiBi. signature.asc Description: Digital signature
Bug#762399: console-setup: WARNING: Unknown X keysym "permille"
2014-12-20 23:41 GMT+02:00 Cyril Brulebois : > Martin-Éric Racine (2014-12-17): >> Are we anywhere close to a definitive fix on this one? > > Do you mean this? > https://packages.qa.debian.org/c/console-setup/news/20141125T170419Z.html console-setup (1.114 to 1.116) Maintainer: Debian Install System Team 24 days old (needed 5 days) Not touching package due to block-udeb request by freeze (check https://release.debian.org/jessie/freeze_policy.html if update is needed) Not touching package due to block request by freeze (check https://release.debian.org/jessie/freeze_policy.html if update is needed) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/debian-boot
Bug#712246: tasksel: Only standard Standard System Utilities task is displayed while having the main repo
Andreas (2014-12-18): > I had the same effect. It was because the mirror i have chosen was > commented out because it could not be verified. What was the reason for the verification failure? > This is a bug but not within tasksel. The installer should warn when > such a mirror is chosen and if it is commented out. Can we see a syslog? Mraw, KiBi. signature.asc Description: Digital signature
Bug#768188: Jessie Installer hangs after processing DHCPv6 stateful addressing
Thanks for the details. Adding Philipp to the loop: Peter Valdemar Mørch (2014-12-18): > I'm also seeing that d-i hangs after DHCP setup. > > But only in Jessie Beta 2 - debian-jessie-DI-b2-amd64-netinst.iso. Not > with Beta 1. The OP also used debian-jessie-DI-b2-amd64-netinst.iso. > > While it hangs, if I go to another terminal with ALT-F2, and issue: > > > kill-all-dhcp > > Then d-i continues past the hang. > > This occurs in in our work environment in VMware Workstation and > Proxmox when using bridged eth0, but not when using NAT. In my home > network, the exact same procedure goes through without any hangs for > both bridged and NAT. > > I've put a wireshark capture of everything from the virtual machine's > MAC address and /var/log/syslog from the installation up until after > running kill-all-dhcp at http://ge.tt/7b1wK872?c and also attached. > > It seems that in our network, IPv6 reverse DNS lookups fail. It is a > likely suspect to why it hangs, but I can't be sure. Misconfigured > IPv6 networks are probably not uncommon! ;-) > > The release announcement: "Debian Installer Jessie Beta 2 release" at > https://www.debian.org/devel/debian-installer/News/2014/20141005 > says: > > netcfg: Do not kill_dhcp_client after setting the hostname and domain, > otherwise Linux udhcpc will stop renewing its lease, and on other > platforms dhclient will de-configure the network interface (#757711, > #757988). > > This comes from a fix to: > > #757711 - netcfg: promptly kills dhclient, deconfigures interface - > Debian Bug report logs > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757711 > > which is: > > Don't kill_dhcp_client without reason (Closes: #757711, #757988) > http://anonscm.debian.org/cgit/d-i/netcfg.git/commit/?id=48f1de7076f8d17a9bf4d11cb05968cb9d8987f7 > > that essentially is this diff: > > diff --git a/dhcp.c b/dhcp.c > index aa37bd0..5ef0dbc 100644 > --- a/dhcp.c > +++ b/dhcp.c > @@ -614,7 +614,6 @@ int netcfg_activate_dhcp (struct debconfclient > *client, struct netcfg_interface > netcfg_write_loopback(); > netcfg_write_interface(interface); > netcfg_write_resolv(domain, interface); > -kill_dhcp_client(); > stop_rdnssd(); > > return 0; > > > Since killing the dhcp client makes it continue for me, I'm pretty > sure the introduction of this fix for #757711 introduced in Jessie > Beta2 is the reason we're now seeing this. > > Sincerely, > > Peter Mraw, KiBi. signature.asc Description: Digital signature
Bug#773400: installation-reports: Partial success: BeagleBone Black [armhf]
Vagrant Cascadian (2014-12-17): > Package: installation-reports > Severity: normal > > Install worked with serial console, though failed to bring up a serial > console on first boot. USB doesn't work, probably due to DMA issues > with MUSB on multiplatform kernels. > > > -- Package-specific info: > > Boot method: netboot > Image version: > http://d-i.debian.org/daily-images/armhf/20141217-05:33/netboot/ > Date: 20141217 > > Machine: BeagleBone Black > > Base System Installation Checklist: > [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it > > Initial boot: [O] > Detect network card:[O] > Configure network: [O] > Detect CD: [ ] > Load installer modules: [O] > Clock/timezone setup: [O] > User/password setup:[O] > Detect hard drives: [O] > Partition hard drives: [O] > Install base system:[O] > Install tasks: [O] > Install boot loader:[ ] > Overall install:[O] > > Comments/Problems: > > USB is mostly broken. HDMI video works. On-board eMMC (2GB) used for > install, and inserted microSD card was detected correctly. Ethernet > works. > > Serial console works, with a caveat: > > The boot.scr generated by flash-kernel scripts for the beagleboneblack > didn't include the console= argument, so on first boot, systemd did > not start a getty on the serial console. I had to manually add > console=ttyO0,115200n8 to "bootargs" from the u-boot shell before > booting. And then added to /etc/default/flash-kernel to ensure it > would work on subsequent boots. Likely the -- vs. --- thing striking again? Mraw, KiBi. signature.asc Description: Digital signature
Bug#762399: console-setup: WARNING: Unknown X keysym "permille"
Martin-Éric Racine (2014-12-17): > Are we anywhere close to a definitive fix on this one? Do you mean this? https://packages.qa.debian.org/c/console-setup/news/20141125T170419Z.html Mraw, KiBi. signature.asc Description: Digital signature
Re: which HSM for secure boot keys
Aaron McSorley (2014-12-19): > I remember some discussion about how to store the shim keys at > debconf, and some hardware security module being passed around. I'm > looking for a recommendation for a HSM for my own shim keys. Was > there ever a conclusion on how to store the keys for debian, and does > anyone remember what that little usb HSM was? I think you want to contact the DSA team (likely the people knowing about this): debian-ad...@lists.debian.org Mraw, KiBi. signature.asc Description: Digital signature
Re: Preseed partman recipe not allocating free lvm space properly
On Sat, Dec 20, 2014 at 09:45:32AM +0100, Geert Stappers wrote:
> On Thu, Dec 18, 2014 at 09:37:44PM +, ryan wrote:
> > Hey list, I'm trying to get my rematastered debian 7.7 iso to install
> > properly on several different classes of workstation we have. Same basic
> > hardware, all machines have 2 disks and the size is anywhere from 160GB
> > up to 1T.
> >
> > I created a recipe in my preseed file, that seems to _almost_ work. I can
> > get the remastered iso to install on both 160GB machines, and 1TB machines
> > with the same recipe, but in the 1TB machines, partman still uses the
> > minimum values for the partitions, then throws all the extra space left
> > in the lvm array into a dummy lv (for later removal). Both software raid
> > arrays appear to get created properly. At least md1 does seem to get the
> > remainder of the disk after md0 is created.
> >
>
> Euh, "Error: Missing information".
> * RAID0 or RAID1?
Raid 1
> * If you care about LVM, why bother about mdX ( md0, md1) ?
I was trying to get the whole lvm array on md0, but was having issues.
Got this working and really aren't worried about 2 software raid devices.
> * What is wrong with "throws extra space on the 1TB machine in dummy LV" ?
Perhaps I wasn't as clear as I could have been. But in my preseed, the
defined partitions are always getting created using the minimum allowable
space. The remainder of space ends up getting added to the dummy lvm
volume. I thought the remainder of space would get distributed between the
defined partitions based on their priorities, with any remaining going to
the dummy partition.
> And what result did you get?
The partitions created were sized at their minimum values, and the dummy
lvm volume was many hundreds of GB.
> What is the expected result?
Max sized defined partitions with whatever is left over in the dummy lvm
volume
>
>
> In other words: I don't understand
> Subject: Preseed partman recipe not allocating free lvm space properly
Probably could have chosen a better subject.
I read on a blog somewhere that the priorities were actually from low
numbers to high. First I had read that, but adjusted preseed to the
following.
d-i partman-auto/expert_recipe string \
raid-lvm :: \
512 10 512 raid\
$primary{ } $lvmignore{ } $bootable{ } \
method{ raid } \
. \
155000 5 -1 raid \
$primary{ } $lvmignore{ }\
method{ raid } \
. \
1 10 2 ext4 \
$defaultignore $lvmok{ } lv_name{ lv00 } \
method{ format } format{ } \
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ / } \
. \
2 100 10 ext4\
$defaultignore $lvmok{ } lv_name{ lv01 } \
method{ format } format{ } \
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ /home } \
. \
1 20 2 ext4 \
$defaultignore $lvmok{ } lv_name{ lv02 } \
method{ format } format{ } \
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ /var } \
. \
1 20 2 ext4 \
$defaultignore $lvmok{ } lv_name{ lv03 } \
method{ format } format{ } \
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ /usr } \
. \
1 1 1 ext4 \
$defaultignore $lvmok{ } lv_name{ lv04 } \
method{ format } format{ } \
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ /tmp } \
. \
16000 50 32000 linux-swap \
$defaultignore $lvmok{ } lv_name{ lv05 } \
method{ swap } format{ } \
. \
25000 30 5 ext4 \
$defau
Processed: 768897 probably affects testing as well
Processing commands for cont...@bugs.debian.org: > # the diff between 98 and 99 is only translations > found 768897 98 Bug #768897 [partman-lvm] quietly very aggressive WRT existing LVM-typed partitions Marked as found in versions partman-lvm/98. > thanks Stopping processing here. Please contact me if you need assistance. -- 768897: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768897 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.c.141908411014315.transcr...@bugs.debian.org
Re: Grub EFI fallback - patches for review
Hi, one option that doesn't seem to have been considered would be to create a separate package (let's call it UEFIx) that installs an UEFI binary to EFI/boot/bootx64.efi. That binary could then do what the UEFI BIOS should've done (i.e. look at the EFI vars for bootorder, bootnext, etc and then go on to load the right bootloader). That way you'll have a solution that'll work across the different bootloaders (grub-efi, gummiboot, etc), requires no changes to existing bootloaders and which will only have an effect if explicitly installed (adding d-i rescue code to optionally install the package should be pretty straightforward as well). It also means that efibootmgr will work as expected on both buggy and non-buggy machines. I realize you're alredy pretty well ahead on a different solution and that it's late in the Jessie game, but I thought I should at least throw this idea into the ring (it's basically what Matthew originally suggested in http://mjg59.dreamwidth.org/4125.html). -- David Härdeman -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141220084530.ga26...@hardeman.nu
Re: Preseed partman recipe not allocating free lvm space properly
On Thu, Dec 18, 2014 at 09:37:44PM +, ryan wrote:
> Hey list, I'm trying to get my rematastered debian 7.7 iso to install
> properly on several different classes of workstation we have. Same basic
> hardware, all machines have 2 disks and the size is anywhere from 160GB
> up to 1T.
>
> I created a recipe in my preseed file, that seems to _almost_ work. I can
> get the remastered iso to install on both 160GB machines, and 1TB machines
> with the same recipe, but in the 1TB machines, partman still uses the
> minimum values for the partitions, then throws all the extra space left
> in the lvm array into a dummy lv (for later removal). Both software raid
> arrays appear to get created properly. At least md1 does seem to get the
> remainder of the disk after md0 is created.
>
Euh, "Error: Missing information".
* RAID0 or RAID1?
* If you care about LVM, why bother about mdX ( md0, md1) ?
* What is wrong with "throws extra space on the 1TB machine in dummy LV" ?
> I thought I had setup the priorities correctly, but I guess not. Cranked
> up priority for md1 creation, and turned down priority for the dummy lvm
> partition. Everything else in the middle.
>
> Here is the partman section of my preseed
>
> d-i partman-lvm/device_remove_lvm boolean true
> d-i partman-md/device_remove_md boolean true
> d-i partman-auto/purge_lvm_from_device boolean true
>
> d-i partman-auto/disk string /dev/sda /dev/sdb
> d-i partman-auto/method string raid
>
> d-i partman-auto-lvm/new_vg_name string vg00
> d-i partman-auto-lvm/guided_size string max
>
> d-i partman-auto/expert_recipe string \
> raid-lvm :: \
> 512 10 512 raid\
> $primary{ } $lvmignore{ } $bootable{ } \
> method{ raid } \
> . \
> 155000 5 -1 raid \
> $primary{ } $lvmignore{ }\
> method{ raid } \
> . \
> 1 5000 2 ext4 \
> $defaultignore $lvmok{ } lv_name{ lv00 } \
> method{ format } format{ } \
> use_filesystem{ } filesystem{ ext4 } \
> mountpoint{ / } \
> . \
> 2 5000 10 ext4\
> $defaultignore $lvmok{ } lv_name{ lv01 } \
> method{ format } format{ } \
> use_filesystem{ } filesystem{ ext4 } \
> mountpoint{ /home } \
> . \
> 1 5000 2 ext4 \
> $defaultignore $lvmok{ } lv_name{ lv02 } \
> method{ format } format{ } \
> use_filesystem{ } filesystem{ ext4 } \
> mountpoint{ /var } \
> . \
> 1 5000 2 ext4 \
> $defaultignore $lvmok{ } lv_name{ lv03 } \
> method{ format } format{ } \
> use_filesystem{ } filesystem{ ext4 } \
> mountpoint{ /usr } \
> . \
> 1 1 1 ext4 \
> $defaultignore $lvmok{ } lv_name{ lv04 } \
> method{ format } format{ } \
> use_filesystem{ } filesystem{ ext4 } \
> mountpoint{ /tmp } \
> . \
> 16000 4000 32000 linux-swap \
> $defaultignore $lvmok{ } lv_name{ lv05 } \
> method{ swap } format{ } \
> . \
> 25000 5000 5 ext4 \
> $defaultignore $lvmok{ } lv_name{ lv06 } \
> method{ format } format{ } \
> use_filesystem{ } filesystem{ ext4 } \
> mountpoint{ /opt } \
> . \
> 5 3000 50 ext4 \
> $defaultignore $lvmok{ } lv_name{ lv07 } \
> method{ format } format{ } \
> use_filesystem{ } filesystem{ ext4 }
