partman doc typo fixes
Hi, Please consider applying the following patch. Thanks, Feri. diff --git a/doc/devel/partman/partman-doc.sgml b/doc/devel/partman/partman-doc.sgml index 90ff44e..2bb4467 100644 --- a/doc/devel/partman/partman-doc.sgml +++ b/doc/devel/partman/partman-doc.sgml @@ -502,7 +502,7 @@ returned by parted_server. provide only the regular partitioning operations. However if the package partman-target is also unpacked then the user will be provided with options to choose file systems for the -partitions, specify wether they should be formatted and select mount +partitions, specify whether they should be formatted and select mount points. The package partman-target adds to the menu directory /lib/partman/active_partition the item `Usage method:'. If the user chooses this item the menu directory @@ -1227,7 +1227,7 @@ $meaningful_flags is a comma-separated list of the flags that are meaningful for the partition with id partition_id. - In order to check wether some particular flag xyz is meaningful + In order to check whether some particular flag xyz is meaningful you can use this code: cd device_directory -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehb9xdo7@lant.ki.iif.hu
Re: Wheezy release: CDs are not big enough any more...
"Thomas Schmitt" writes: > I am a bit scared by the catastrophic potential of > cat debian.iso > /dev/sdX > for X = valuable hard disk. What about recommending /dev/disk/by-id/usb-X instead? -- Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4ukwgk6@szonett.ki.iif.hu
Re: preseeding vs lvm
Patryk Ściborek writes: > But to my surprise it creates much bigger PV than I want: > [...] > And LV root takes all available space: Last time I checked it was impossible to preseed an LVM setup where not all the space was allocated. I had to resort to custom scripts invoked by custom partman menu items to achieve this. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ty3w565o@tac.ki.iif.hu
Re: About using static config with pxeboot/preseed
Julien Escario writes: > Hello, > I'm trying to configure full automated install. > The server is booting over pxe, get his dhcp lease and retrieve the preseed > file > over http. > > Preseeding is working well but not for the net config : ip address, hostname, > ... > > After reboot, dhcp is still used and hostname is 'debian'. > > Is this a normal behaviour ? No way to use DHCP to get the address for d-i and > install the server with a static address ? Probably not easily, but you can use preseed/late_command to overwrite /target/etc/network/interfaces if you wish. I use initrd preseeding with static network config during installation, and that works well. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ty7bu9e9@tac.ki.iif.hu
Bug#623273: netcfg: way to start web and ssh via preseed
Matt Taggart writes: > I am attempting to debug a preseed install on serial console and I > can't just switch to another VC to get the log or run a shell. If I > could access the built-in webserver to access the logs or ssh to run a > shell and poke around, that would help a lot. Here is what I put in my initrd preseed.cfg (after a static network preseed) to automatically get a network console (and ssh client): d-i anna/choose_modules string \ network-console: Continue installation remotely using SSH, \ openssh-client-udeb: Secure shell client for the Debian installer network-console network-console/password password network-console network-console/password-again password network-console network-console/start note Of course you may have to tweak the above for DHCP configs, but you get the idea. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4eqlg5x@tac.ki.iif.hu
Re: Squeeze DHCP autoconfiguration failed on BootPXE install
stephane travassac writes: > I have find the solution > I had netcfg/dhcp_timeout=60 in the kernel command line and it's work. Good. As far as I know, there's already a fix for this (allowing shorter timeouts) in the development version of netcfg, which didn't make it into 6.0.1, AFAIK. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87oc53jvmj@tac.ki.iif.hu
Bug#616315: cdebconf in d-i via serial hides the option to go back
Miguel Figueiredo writes: > New proposal for the messages. You still don't seem to handle the case when going back isn't supported. Is that entirely forbidden in the installer? -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ei6fxmtn@tac.ki.iif.hu
Bug#614504: Can't install debian 6.0 on a Dell optiplex gx110
Steve McIntyre writes: > On Tue, Feb 22, 2011 at 12:42:33AM +0100, Matthieu COUDERT wrote: > >> Neither the "install" nor the "graphical install" option works. >> When I choose one of these options, the bottom of the screen gets >> covered with multicolored snow, and nothing else happens. >> I burned another cd, and the problem persists. > > If even the text-mode installer is failing then that sounds > worrying. Forwarding for the installer team to take a look... Please press TAB on the "Install" item in the boot menu, and remove the "quiet" parameter from the kernel command line. Add instead "vga=ask" and try various modes by hand. If the screen corruption happens later in the process, "fb=false" may be worth a try as well. -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wrkfgnde@tac.ki.iif.hu
Re: Fw: Re: Starting Debian installer from Grub2 on Flash
Jean-Michel Pouré - GOOZE writes: > * On startup, only C and English are proposed. I suppose this is a > problem with language detection due to serial console. Right? How can I > unable all languages on startup? See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=301343: 'This [hang] was "fixed" by making only English be offered in serial console displays.' And indeed, if I force any other language, the installer hangs at the next question. I don't know why precisely. > * Now how can I tell the installer to use Endebian? I am a little bit > lost for that part. No idea, sorry. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aahbi2a3@tac.ki.iif.hu
Bug#615600: BOOTIF= kernel commandline option does not work
Marc Haber writes: > On Wed, Mar 02, 2011 at 04:44:07PM +0100, Ferenc Wagner wrote: > >> Maybe, I didn't try it on SMP. write_net_rules has some locking to >> prevent such issues, though. > > My rule hasn't, but it shouldn't do anything if the script is silent, > should it? Your rule shouldn't do anything than possibly importing a property into the event environment, and the bootif script only reads constant data, so it shouldn't need any locking either. >>>> Actually, your rule worked perfectly well, despite that you don't >>>> reserve the eth0 name, just try to assign it even if it's taken >>>> already. Unless I overlook something, this should be fixed. >>> >>> How do I reserve a name? >> >> By renaming eth0 to something else, unless it isn't the boot interface. > > So my script should print INTERFACE_NAME="foo0" to its standard output > if invoked for an interface that is eth0 and not the boot interface? > And who is responsible to rename it back into the ethx namespace? Nobody, I'm afraid. What you want isn't particularly simple, especially that ethX devices may be appearing concurrently, so you'll have to synchronize much like write_net_rules does. You can't even guarantee that there will be an eth0 at the end! I'd probably start by modifying write_net_rules, it already has some special code handling eth0. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4ghflzn@tac.ki.iif.hu
Bug#615600: BOOTIF= kernel commandline option does not work
Marc Haber writes:
> On Wed, Mar 02, 2011 at 01:41:58AM +0100, Ferenc Wagner wrote:
>
>> Marc Haber writes:
>>
>>> On Tue, Mar 01, 2011 at 04:28:16PM +0100, Marc Haber wrote:
>>>
>>>> I guess the following changes do kind of a job:
>>>> etc/udev/rules.d/69-bootif.rules (inside the installer's initrd)
>>>> ACTION=="add", SUBSYSTEM=="net", IMPORT{program}="bootif $attr{address}"
>>>>
>>>> Unfortunately, this seems to go a little too far. My test system comes
>>>> up with the second interface being the bootif, so it's eth1 without
>>>> these additions.
>>>
>>> This seems to be the fault of the additional rule which gives the
>>> impression that the rule is actually doing something. Even when I
>>> replace the bootif script with a call to true, I get multiple stanzas
>>> per interface in 70-persistent-net.rules.
>>
>> In my limited testing (with two Qemu interfaces) this didn't happen
>> after several
>>
>> # rm 70-persistent-net.rules
>> # udevadm trigger --verbose --action=add --subsystem-match=net
>>
>> cycles.
>
> Did you try with a multiprocessor VM? I guess that this is some
> threading/multiprocessing issue that multiple interfaces get processed
> at the same time, causing races.
Maybe, I didn't try it on SMP. write_net_rules has some locking to
prevent such issues, though.
>> Actually, your rule worked perfectly well, despite that you don't
>> reserve the eth0 name, just try to assign it even if it's taken
>> already. Unless I overlook something, this should be fixed.
>
> How do I reserve a name?
By renaming eth0 to something else, unless it isn't the boot interface.
>> But /lib/udev/write_net_rules activates set -x if udev logging is set
>> to debug level, and while the output in /var/log/syslog is less than
>> readable, it may prove some insight.
>>
>> # udevadm control --log-priority=debug
>
> I'll try that and report back. Thanks for helping.
Hey, thanks for maintaining Exim!
--
Regards,
Feri.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mxldh6ig@tac.ki.iif.hu
Re: Fw: Re: Starting Debian installer from Grub2 on Flash
Jean-Michel Pouré - GOOZE writes: > Le mardi 01 mars 2011 à 22:09 +0100, Ferenc Wagner a écrit : > >> Then you'll get the equivalent of a PXE installation, but started >> from flash. > > This is great. Do I also need the mini.iso, right? No, nothing is needed beyond linux and initrd.gz. Everything else is downloaded from the network. -- Good luck, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vd01vlud@tac.ki.iif.hu
Bug#615600: BOOTIF= kernel commandline option does not work
Marc Haber writes:
> On Tue, Mar 01, 2011 at 04:28:16PM +0100, Marc Haber wrote:
>> I guess the following changes do kind of a job:
>> etc/udev/rules.d/69-bootif.rules (inside the installer's initrd)
>> ACTION=="add", SUBSYSTEM=="net", IMPORT{program}="bootif $attr{address}"
>>
>> Unfortunately, this seems to go a little too far. My test system comes
>> up with the second interface being the bootif, so it's eth1 without
>> these additions.
>
> This seems to be the fault of the additional rule which gives the
> impression that the rule is actually doing something. Even when I
> replace the bootif script with a call to true, I get multiple stanzas
> per interface in 70-persistent-net.rules.
In my limited testing (with two Qemu interfaces) this didn't happen
after several
# rm 70-persistent-net.rules
# udevadm trigger --verbose --action=add --subsystem-match=net
cycles. Actually, your rule worked perfectly well, despite that you
don't reserve the eth0 name, just try to assign it even if it's taken
already. Unless I overlook something, this should be fixed.
I usually assign symbolic names instead of ethX ones, like wlan, utp,
private, gb1 (chassis label) or similar; they usually work just fine,
but sometimes break assumptions of some software (like Munin plugins).
Maybe keeping the domain and the range of the mapping would help
debugging this case as well.
> Do I need to say in the 69-bootif.rules that this should be treated as
> a no-op rule?
I don't think so. But /lib/udev/write_net_rules activates set -x if
udev logging is set to debug level, and while the output in
/var/log/syslog is less than readable, it may prove some insight.
# udevadm control --log-priority=debug
--
Regards,
Feri.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vd02ica1@tac.ki.iif.hu
Re: squeeze boot failure
Miguel Figueiredo writes: > A Quinta 24 Fevereiro 2011 15:29:41 Dieter Faulbaum você escreveu: > >> Miguel Figueiredo writes: >> >>> A Terça 22 Fevereiro 2011 17:27:47 Dieter Faulbaum você escreveu: >>> >>> Please take a look on the installer log at /var/log/installer/syslog or >>> if 'installer' doesn't exists, /var/log/syslog. >>> This should have more details on what is happening. >> >> I didn't find any suspicious in that file, what explains the non-booting. >> >>> Care to send it (gzipped) so we can take a look? >> >> Do you? > > I am not familiar with the HP Proliant DL 380 but i found this on your log > that might be relevant: > > Feb 22 12:55:30 kernel: [ 88.277525] qla2xxx :06:01.0: firmware: > requesting ql2300_fw.bin > Feb 22 12:55:30 kernel: [ 88.283698] qla2xxx :06:01.0: Firmware image > unavailable. > Feb 22 12:55:30 kernel: [ 88.283703] qla2xxx :06:01.0: Firmware images > can be retrieved from: ftp://ftp.qlogic.com/outgoing/linux/firmware/. > Feb 22 12:55:30 kernel: [ 88.283709] qla2xxx :06:01.0: Failed to > initialize adapter > > The adapter fails to initialize, seems to be due to missing firmware. > Did you add it later (i see the controller starts working later) ? > If not, the procedure is described in the installation manual [1]. > The firmware is available on non-free on the package: firmware-qlogic > Somehow (maybe the fw is not mandatory) the storage is detected. > > 1 - http://d-i.alioth.debian.org/manual/en.amd64/ch06s04.html > > > > Then there are some errors about duplicated PVs on LVM: > > Feb 22 13:03:43 partman-lvm: Found duplicate PV > HoUN7toMf0CJXuWQ0ZQKTY5Q9ynivkGh: using /dev/sdc not /dev/sdb > Feb 22 13:03:43 partman-lvm: Found duplicate PV > HoUN7toMf0CJXuWQ0ZQKTY5Q9ynivkGh: using /dev/sdd not /dev/sdc > Feb 22 13:03:43 partman-lvm: Found duplicate PV > HoUN7toMf0CJXuWQ0ZQKTY5Q9ynivkGh: using /dev/sde not /dev/sdd > Feb 22 13:03:43 partman-lvm: Found duplicate PV > HoUN7toMf0CJXuWQ0ZQKTY5Q9ynivkGh: using /dev/sdf not /dev/sde > Feb 22 13:03:43 partman-lvm: Found duplicate PV > HoUN7toMf0CJXuWQ0ZQKTY5Q9ynivkGh: using /dev/sdg not /dev/sdf > Feb 22 13:03:43 partman-lvm: Found duplicate PV > HoUN7toMf0CJXuWQ0ZQKTY5Q9ynivkGh: using /dev/sdh not /dev/sdg > Feb 22 13:03:43 partman-lvm: Found duplicate PV > HoUN7toMf0CJXuWQ0ZQKTY5Q9ynivkGh: using /dev/sdi not /dev/sdh These devices are probably 8 paths to the same disk accessed via the QLA2xxx host bus adapter(s), so this is fine. > Grub2 seems to be installed without errors. > Feb 22 13:14:29 grub-installer: info: Installing grub on '/dev/cciss/c0d0' > Feb 22 13:14:29 grub-installer: info: grub-install supports --no-floppy > Feb 22 13:14:29 grub-installer: info: Running chroot /target grub-install > --no-floppy --force "/dev/cciss/c0d0" > Feb 22 13:14:32 grub-installer: Installation finished. No error reported. > Feb 22 13:14:32 grub-installer: info: grub-install ran successfully Dieter, If the lenny version of grub-pc boots the machine, but the squeeze one does not, then this is a grub-pc regression, and its maintainers would probably be most interested to hear about this issue, so please reassing the bug appropriately. If you can't use the lenny (or any other working) version of grub-pc for some reason, then you might want to try another bootloader, like for example extlinux. Since you checked that Grub2 is indeed installed to the right device (it's usual place is the first sectors of the disk starting with the MBR, before the first partition), this bug probably does not belong to Debian Installer in the strict sense. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762s2jshg@tac.ki.iif.hu
Re: Fw: Re: Starting Debian installer from Grub2 on Flash
Wookey writes: > [Forwarded from Debian-arm list to somewherre where the answers might > be better known. ] Please forward this back if it's really arm-related. > From: Jean-Michel Pouré - GOOZE > Subject: Re: Starting Debian installer from Grub2 on Flash > To: debian-embed...@lists.debian.org > Date: Tue, 01 Mar 2011 03:12:39 +0100 > Reply-To: jmpo...@gooze.eu > > Le lundi 28 février 2011 à 23:02 +0100, Jean-Michel Pouré - GOOZE a > écrit : > >> Can Debian installer be started and installed on the same CF Flash? >> We would like users to be able to make their own installation using >> Debian installer and network. Therefore a minimal installer should >> reside on CF. A "bonus" would be the installer being recognized by >> Grub2 and proposed as a rescue boot. > > I followed instructions from the Debian installer hd-media. > This is an ALIX 2D13 board with serial console. > > So I modified sys.conf to boot from console (ok). > Then I modified the image bootloader with serial console support (ok). > > Now the CD net-install image boots but does not recognize the flash > drive. > > I am aware that PXE installation works. But we would like to offer users > and installer on FLASH to ease installation. I'd recommend trying the netboot (not netinst!) image: download its linux kernel and initrd.gz from eg. http://ftp.nl.debian.org/debian/dists/squeeze/main/installer-i386/current/images/netboot/debian-installer/i386/ (or alternatively download netboot.tar.gz from two levels higher and extract them from it), and configure Grub2 to load those. Then you'll get the equivalent of a PXE installation, but started from flash. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877hcik0nt@tac.ki.iif.hu
Bug#615599: debian-installer prefers usb Blockdevices over "real" harddrives
Marc Haber writes: > On Mon, Feb 28, 2011 at 06:33:55AM +0100, Christian PERRIER wrote: > >> Quoting Thomas Mieslinger (tho...@mieslinger.de): >> >>> Package: debian-installer >>> Version: 20110106+b1 >>> >>> Tried to autoinstall squeeze on dell poweredge hardware with drac5 >>> or idrac6 KVM. The installer always tried to use 40MB usb vflash >>> (/dev/sda) instead of the 1tb real harddrive (/dev/sdb). >> >> Hmmm, when there are several storage devices, you get, at some point, >> the choice of what drive the installation should be made to. > > Thomas is talking about unattended installation of an obscene number > of servers, so "getting a choice" is not the intended behavior. > >> So, what exactly makes you think that the installer "prefers" USB >> block devices? > > I guess that he would prefer to have USB block devices treated with > lower (lowest?) precedence over "real" storage devices, which > can/should avoid a prompt which may be undesireable during an unaended > install. I don't think any concept of "preference" is present in the partitioner. However, let me quote the preseeding documentation: # This command is run immediately before the partitioner starts. It may be # useful to apply dynamic partitioner preseeding that depends on the state # of the disks (which may not be visible when preseed/early_command runs). #d-i partman/early_command \ # string debconf-set partman-auto/disk "$(list-devices disk | head -n1)" Isn't this something you could use? -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4gkrvdw@tac.ki.iif.hu
Bug#615600: Bug#504753: Bug#615600: BOOTIF= kernel commandline option does not work
Marc Haber writes: > On Mon, Feb 28, 2011 at 06:39:48AM +0100, Christian PERRIER wrote: > >> Quoting Thomas Mieslinger (thomas.mieslin...@1und1.de): >> >>> To get my job done all those 5000 Machines must comply to some very >>> very basic guidelines. After the installation, the inner interface >>> is always eth0 if there is a public interface, it is eth1. If there >>> are crosslinks they are eth1 and onward. >>> >>> I need a simple and powerful mechanism to enforce this against the >>> quirks of udev and bioses. >> >> You may want to develop the needed support for such things in >> netcfg. > > Are there any docs for netcfg? After a cursory glance at the source > package, it looks like the docs are contained in those nice .c and .h > files with a little too little documentation about the interfaces. There's no docs for netcfg, AFAIK, but it isn't that complicated. However, Matt Palmer is currently reorganizing the code, so you'd better synchronize with him before you start fiddling with it. On the other hand, the issue at hand probably doesn't belong into netcfg. Naming network interfaces is a job for udev, and netcfg can simply use eth0 after that, if I read Thomas correctly. I routinely do this by putting /etc/udev/rules.d/60-manual-net.rules into the installer initramfs AND copying it into /target at the end of the installation. One could make this fully dynamic if needed, even without remastering the initramfs, by elaborate preseed/early_command specifications. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqqcrvko@tac.ki.iif.hu
Bug#615074: installation-reports: LVM partitions unusable during lenny->squeeze upgrade
Hilmar Preusse writes: > On 25.02.11 Ferenc Wagner (wf...@niif.hu) wrote: > >> Hilmar Preusse writes: >> >>> During the upgrade of lvm by calling "apt-get dist-upgrade" >>> everything has been fixed, but until then these file systems were >>> unavailable. >> >> Strange, LVM should scan all available block devices for PVs, unless >> forbidden by manual filter rules. > > I'm pretty sure there are none. I can provide the lvm config before > and after the upgrade if this is helpful. Only if you got a conffile conflict during the LVM upgrade. Otherwise you must be using the default filter, which allows hda and sda alike. >> I wonder why it didn't happen in your case... Wasn't this a >> problem with missing /dev/mapper/* nodes instead? > > However right after the first reboot all view commands (vgdisplay, > pvdisplay etc.) complained that some PVs having specific UUIDS could > not be accessed/listed(?). This suggests that *some* PVs must have been available, as the VG was recognized. Is it possible that after the first reboot you somehow temporarily lost some PVs (but not all)? -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r5audgwe@tac.ki.iif.hu
Bug#615074: installation-reports: LVM partitions unusable during lenny->squeeze upgrade
Hilmar Preusse writes: > During the lenny->squeeze upgrade I noticed that right after the first > reboot (item 4.4.5 in the squeeze release notes) my logical volumes were not > found any more. > I have the LVM set up on IDE disks. Before the reboot the PV's were on > /dev/hda11, /dev/hda14 etc. Right after the reboot the pv were "moved" to > /dev/sda11, /dev/sda14, etc. and hence were not found any more. Some file > systems could not be mounted. > During the upgrade of lvm by calling "apt-get dist-upgrade" everything has > been fixed, but until then these file systems were unavailable. Strange, LVM should scan all available block devices for PVs, unless forbidden by manual filter rules. I wonder why it didn't happen in your case... Wasn't this a problem with missing /dev/mapper/* nodes instead? -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y654qdpl@tac.ki.iif.hu
Re: Where to put the script to custom some environment in debian installer?
Magicloud Magiclouds writes: > When using debian installer cd, there are many options to set. And I > could modify some parts, for example localechooser, to make some > customizing. > What if I just want to make some options fixed, so the user do not > have to use localechooser at all? I cannot find where to put the > scripts to set something when the installer starts. Read about preseeding in appendix B of the installation manual: http://www.debian.org/releases/stable/i386/apb.html.en -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874o7t9z5s@tac.ki.iif.hu
Bug#613796: partman-partitioning: Put swap at begin of disk instead of at end
Olaf van der Spek writes: > On Thu, Feb 17, 2011 at 10:31 PM, Lennart Sorensen > wrote: > >> On Thu, Feb 17, 2011 at 10:18:33PM +0100, Olaf van der Spek wrote: >> >>> Is it? I thought it was the default. More doesn't make sense. >> >> If you have 8GB ram, 256MB swap is useless. 4 or 8GB might be useful. >> Some people work with datasets that large sometimes. If you have 32MB >> ram, 256MB swap is probably too much. > > I'm not sure swap size should be related to memory size like that. > It's more related to the amount of committed but not regularly used > memory and the performance of the swap device. Don't forget that swap is also used for storing the system image during hibernation. It's a pretty important use case on desktop systems at least. -- Cheers, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aahs4bq9@tac.ki.iif.hu
Re: Preparation of fixes to 6.0.1
Julien Cristau writes: > On Thu, Feb 17, 2011 at 21:52:53 +0100, Christian PERRIER wrote: > >> In short, I know that "volatile" is now named "squeeze-updates"...but >> how is it called more generically? > > 'Urgent bug fixes', or something to that effect? Timely updates, or (world-)tracking updates? -- Cheers, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762sg4b59@tac.ki.iif.hu
Re: differences in busybox configurations, part1 (longish)
Otavio Salvador writes: > On Mon, Feb 14, 2011 at 22:06, Michael Tokarev wrote: > >> FEATURE_SHADOWPASSWDS >> support for getspent() and friends. >> Current: deb n static y udeb n >> Proposed action: enable for deb >> Discussion: It is quite unexpected that busybox can't >> use shadow passwords. On the other hand, there's just >> a few applets which actually deals with passwords, and >> most of them are disabled for deb build. > > I'd say to enable it on deb since it can be an important applet for > embedded people to rely on. I have the gut feeling that static busybox was mostly used for testing cross-built system images under Qemu user-mode emulation. I can't serve with references now, but a web search would surely give you relevant hits. That's why the current static config is so much different from the other two: all three serve rather different purposes (deb: initramfs and rescue, udeb: d-i, static: full system testing). However, maybe the emulation use case isn't present anymore, since qemu-user gained the -L option... I hope embedded people can report on the current practices. >> NC_SERVER, NC_EXTRA >> (netcat options) >> Current: deb n static n udeb y >> Proposed action: enable for deb and static >> Discussion: actually useful for rescue system > > Agreed. > > I am not sure it ought to be enabled on udeb. Comments? I often find it easier to keep the server end on the machine being installed to avoid reconfiguration of the firewall on production machines (which block incoming connections to all unused ports). -- Cheers, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vxidsja@tac.ki.iif.hu
Bug#571958: could someone in the d-i team could at least acknowledge the existance of this bug?
Costin writes: > I can't believe this bug has gone one whole year unnoticed and > unfixed... and still counting. You certainly have a point. Anyway, xfs is automatically present in my tests, and I could get ntfs by downloading the ntfs-modules-2.6.32-5-686-bigmem-di installer component (you have to do an expert install or drop your debconf priority to medium to be offered a manual selection). I don't know a thing about hfs and hfsplus. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4hblrf3@tac.ki.iif.hu
Bug#611250: please support network bonding
Martin Zobel-Helas writes: > On Thu Jan 27, 2011 at 13:19:49 +0100, Ferenc Wagner wrote: > >> Martin Zobel-Helas writes: >> >>> it would be nice if the debian-installer could support network bonding >>> on several interfaces. >> >> Why do you think it's worth the effort? Installation isn't performance >> critical, nor does it require high availability. And you can easily >> configure bonding after installation. So I'm not sure it's worth the >> added complexity. (I'm saying this although I routinely write out >> bonding-enabled /etc/network/interfaces from a finish.d script... :) > > I installed Debian quite often recently in an existing environment, and > actually, using balancing mode, you everytime need to reconfigure the > switch to not route every second package to the interface not being > available in the installer. That is kind of boring, and my idea is, > Debian could do better. Fascinating. Why is the other interface up at all? Or does the switch simply not care? Anyway, I'm certainly not against this, but d-i has traditionally been rather wary about growing new features. That said, bonding doesn't require extra utilities (being fully configurable through sysfs), so this probably isn't a serious issue. -- Cheers, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wrlqsbsk@tac.ki.iif.hu
Bug#611250: please support network bonding
Martin Zobel-Helas writes: > it would be nice if the debian-installer could support network bonding > on several interfaces. Why do you think it's worth the effort? Installation isn't performance critical, nor does it require high availability. And you can easily configure bonding after installation. So I'm not sure it's worth the added complexity. (I'm saying this although I routinely write out bonding-enabled /etc/network/interfaces from a finish.d script... :) -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877hdqtu6y@tac.ki.iif.hu
Bug#591756: udeb size increase for vconfig support in busybox
Martin Zobel-Helas writes: > On Fri Jan 21, 2011 at 15:02:30 +0100, Ferenc Wagner wrote: > >> Matthew Palmer writes: >> >>> Just for the record, the difference between the size of the binary in >>> busybox-udeb 1.17.1-9 (as is currently in git) when built on i386 with and >>> without vconfig is 384 bytes. >> >> I wonder if you really need this after all. vconfig is deprecated, and >> even the current squueze RC1 busybox seems to understand >> >> # ip link add link eth0 name vlan10 type vlan id 10 >> >> although the operation itself fails. On my squeeze desktop, >> >> # modprobe dummy >> # ip link add link dummy0 name vlan type vlan id 10 >> >> works all right, and even >> >> # busybox ip link del vlan >> >> does its deed, but >> >> # busybox ip link add link dummy0 name vlan type vlan id 10 >> ip: RTNETLINK answers: Invalid argument >> >> So I guess the support is there in busybox right now, but unfortunately >> it's broken by some bug. > > Are you sure the vlan kernel modules are loaded? I think we might miss > the vlan modules (8021q garp stp) in d-i for that. That was my first thought as well. But then I tried on a squeeze desktop, where iproute had no difficulty adding the tagged interface, but busybox still failed (although it could delete it beforehand). -- Cheers, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lj2e5k2w@tac.ki.iif.hu
Bug#591756: udeb size increase for vconfig support in busybox
Matthew Palmer writes: > Just for the record, the difference between the size of the binary in > busybox-udeb 1.17.1-9 (as is currently in git) when built on i386 with and > without vconfig is 384 bytes. I wonder if you really need this after all. vconfig is deprecated, and even the current squueze RC1 busybox seems to understand # ip link add link eth0 name vlan10 type vlan id 10 although the operation itself fails. On my squeeze desktop, # modprobe dummy # ip link add link dummy0 name vlan type vlan id 10 works all right, and even # busybox ip link del vlan does its deed, but # busybox ip link add link dummy0 name vlan type vlan id 10 ip: RTNETLINK answers: Invalid argument So I guess the support is there in busybox right now, but unfortunately it's broken by some bug. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkqu5p8p@tac.ki.iif.hu
Bug#595733: #595733 [sparc] sym53c8xx is not autodetected
Hermann Lauer writes: > On Sun, Jan 16, 2011 at 08:47:40PM +, Miguel Figueiredo wrote: > >> sym53c8xx is included in the linux-kernel-di-sparc-2.6 so i guess it >> should be detected. >> Can you try with a recent image and give feedback? > > You are right, it is detected now (9699532 2010-12-15 17:09 boot_beta2.img). > But a symbol is missing, so sd_mod did not load - see below. > > [ 520.256605] sd_mod: Unknown symbol blk_queue_physical_block_size_fixed That's a signal of kernel/module mismatch which can happen sometimes in certain images (I'd welcome some clarification from somebody myself). Please check with the RC1 images, when you have time. -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ipxneswf@tac.ki.iif.hu
Bug#574683: marked as done (Kernel panic on install)
ow...@bugs.debian.org (Debian Bug Tracking System) writes: > The system can boot from CD but when I go ahead with "Install" at the > initial screen, kernel panics. The message I get is: > > [ 0.596893] Kernel panic - not syncing: VFS: Unable to mount root fs > on unknown-block(8,3) > > -- > > From: Miguel Figueiredo > To: 574683-d...@bugs.debian.org > Date: Mon, 10 Jan 2011 21:51:52 + > > The issue you reported is known for happening due to kernel/modules > mismatch. I doubt this, but maybe I miss something. This looks very much like a dupe of #606976, thus modules can't enter the picture. But even if I'm right, closing this was a good move. -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ipxwjpkm@tac.ki.iif.hu
Bug#607906: oops and panic after hardware detection
reassign 607906 linux-2.6 thanks I reproduced the panic with the daily installer (first attachment). By stopping before disk-detect and using a shell I could narrow this down to the "modprobe mptspi" command (second attachment). It takes quite some time to hit the BUG, which is then sooner or later followed by a kernel panic. However, I can't trigger the problem under "dmesg -n8": then the disks are detected all right (third attachment). All of this seems 100% reproducible. Thanks, Feri. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.32-5-486 (Debian 2.6.32-29) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 Fri Dec 10 15:32:53 UTC 2010 [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] NSC Geode by NSC [0.00] Cyrix CyrixInstead [0.00] Centaur CentaurHauls [0.00] Transmeta GenuineTMx86 [0.00] Transmeta TransmetaCPU [0.00] UMC UMC UMC UMC [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009d400 (usable) [0.00] BIOS-e820: 0009d400 - 000a (reserved) [0.00] BIOS-e820: 000e - 0010 (reserved) [0.00] BIOS-e820: 0010 - 5ffeb2c0 (usable) [0.00] BIOS-e820: 5ffeb2c0 - 5fff (ACPI data) [0.00] BIOS-e820: 5fff - 6000 (reserved) [0.00] BIOS-e820: fec0 - 0001 (reserved) [0.00] DMI 2.3 present. [0.00] last_pfn = 0x5ffeb max_arch_pfn = 0x10 [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] init_memory_mapping: -377fe000 [0.00] RAMDISK: 5f98b000 - 5ffda59c [0.00] Allocated new RAMDISK: 0010 - 0074f59c [0.00] Move RAMDISK from 5f98b000 - 5ffda59b to 0010 - 0074f59b [0.00] ACPI: RSDP 000fdfc0 00014 (v00 IBM ) [0.00] ACPI: RSDT 5ffeff80 00030 (v01 IBMSERONYXP 1000 IBM 45444F43) [0.00] ACPI: FACP 5ffeff00 00074 (v01 IBMSERONYXP 1000 IBM 45444F43) [0.00] ACPI: DSDT 5ffeb2c0 04A4E (v01 IBMSERGEODE 1000 MSFT 010B) [0.00] ACPI: FACS 5ffefe00 00040 [0.00] ACPI: APIC 5ffefe40 00092 (v01 IBMSERONYXP 1000 IBM 45444F43) [0.00] ACPI: ASF! 5ffefd80 0004B (v16 IBMSERONYXP 0001 IBM 45444F43) [0.00] 647MB HIGHMEM available. [0.00] 887MB LOWMEM available. [0.00] mapped low ram: 0 - 377fe000 [0.00] low ram: 0 - 377fe000 [0.00] node 0 low ram: - 377fe000 [0.00] node 0 bootmap 8000 - ef00 [0.00] (7 early reservations) ==> bootmem [00 - 00377fe000] [0.00] #0 [00 - 001000] BIOS data page ==> [00 - 001000] [0.00] #1 [000100 - 0001453a28]TEXT DATA BSS ==> [000100 - 0001453a28] [0.00] #2 [09d400 - 10]BIOS reserved ==> [09d400 - 10] [0.00] #3 [0001454000 - 000145a228] BRK ==> [0001454000 - 000145a228] [0.00] #4 [007000 - 008000] PGTABLE ==> [007000 - 008000] [0.00] #5 [10 - 74f59c] NEW RAMDISK ==> [10 - 74f59c] [0.00] #6 [008000 - 00f000] BOOTMAP ==> [008000 - 00f000] [0.00] found SMP MP-table at [c009d540] 9d540 [0.00] Zone PFN ranges: [0.00] DMA 0x -> 0x1000 [0.00] Normal 0x1000 -> 0x000377fe [0.00] HighMem 0x000377fe -> 0x0005ffeb [0.00] Movable zone start PFN for each node [0.00] early_node_map[2] active PFN ranges [0.00] 0: 0x -> 0x009d [0.00] 0: 0x0100 -> 0x0005ffeb [0.00] Using APIC driver default [0.00] ACPI: PM-Timer IO Port: 0x488 [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x06] enabled) [0.00] ACPI: NR_CPUS/possible_cpus limit of 1 reached. Processor 1/0x6 ignored. [0.00] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) [0.00] ACPI: NR_CPUS/possible_cpus limit of 1 reached. Processor 2/0x1 ignored. [0.00] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x07] enabled) [0.00] ACPI: NR_CPUS/possible_cpus limit of 1 reached. Processor 3/0x7 ignored. [0.00] ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x06] dfl dfl lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x07] dfl dfl lint[0x1]) [0.00] ACPI: IOAPIC (id[0x0e] address[0xfec0] gsi_base[0]) [
Bug#603441: #603441 cdrom: serial console on Belkin f5u103 unsupported in Lenny AMD64 netinst
Gregory Nowak writes: > reboot with the cd in the drive, and get the beep from the pc speaker. > I hit , , and get no serial output. Are you sure that your USB-serial driver and the USB core is compiled into the installer kernel? The standard 8250 serial stuff is... -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3o5m74m@tac.ki.iif.hu
Bug#606976: Kernel panic with Squeeze (AMD64) d-i beta 2
Taro Sato writes: > On Thu, Dec 16, 2010 at 12:27 PM, Ferenc Wagner wrote: > >> Taro Sato writes: >> >>> I've tried d-i beta 2 on Dell XPS 630i. I first tried creating a USB >>> memory stick with the installer .iso on it (following a standard >>> procedure); the install USB stick works on my other computer (Lenovo >>> T410s). However, on 630i it always fails at the beginning of the >>> install process. The message, when kernel panics, typically goes like >>> this: >>> >>> ... (no apparent error messages thru this point) ... >>> [0.597991] List of all partitions: >>> [0.600310] No filesystem could mount root, tried: >>> [0.602749] Kernel panic - not syncing: VFS: Unable to mount root fs on >>> unknown-block(8,3) >>> ... (call trace output after this) ... Could you please also type in the call trace output what you get if you remove the "quiet" parameter? If this machine has a serial port, you can also use that to capture the whole boot log, which would be interesting as well (with a console=ttyS0,115200n8r or similar boot parameter). Unfortunately, serial ports are getting rare... >> The above message indicates that no initramfs was loaded with the >> kernel, or maybe it was corrupt. If you didn't remove the "quiet" >> parameter from the kernel command line, you'd see the message >> >> Initramfs unpacking failed: junk in compressed archive >> >> in the latter case. > > I've never seen this message, though it might be possible that's > something scrolls out of the screen when the boot process spews out > the log message till the kernel panic. I don't know how to capture > it. No, that message is printed even with "quiet", so you would have seen it right above the panic line if it was present. >> You could also try writing the mini.iso [...] to a pendrive > > I just tried the mini.iso on a USB stick and I see exactly the same > kernel panic. > > (In order to get the system back up, I installed Lenny first, and then > installed Squeeze from a hard disk partition which ended up very > successful. Wonder what the difference is.) Do you mean that when you loaded the installer kernel and initrd by Grub from your hard disk, everything went OK? Most strange, again. Long shot: what if you add "edd=off" to your kernel command line (after "quiet")? I don't think it would change anything, but you may want to test some RC1-pre medium from http://cdimage.debian.org/cdimage/.squeeze_di_rc1/. -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqs521bx@tac.ki.iif.hu
Bug#609339: Unable to specify routes when installing
Christian PERRIER writes: > Quoting Philippe Villiers (kissif...@gmail.com): > >> I'm using Mac failovers on a virtual machine where i'm trying to >> install Debian Squeze. >> The problem is when I try to specify my IP adress and such, I have a >> gateway unreachable error. >> >> In fact I would like tu use the following configuration: >> Ip address of the virtual machine is named IPVM, the gateway is IPGT >> So the machine would have the following parameters: >> IP address: IPVM >> Broadcast address: IPVM >> Netmask: 255.255.25.255 >> Gateway: IPGT >> >> A /etc/network/interfaces would look like this: >> >> auto eth0 >> iface eth0 inet static >> address IPVM >> netmask 255.255.255.255 >> broadcast IPVM >> post-up route add IPGT dev eth0 >> post-up route add default gw IPGT >> post-down route del IPGT dev eth0 >> post-down route del default gw IPGT >> >> But I can't configure my network like this using the installer. > > Is this really something we want in the installer? I'm not entirely > convinced that each and every specific setup needs to be configurable > from scratch in D-I. I also feel like such a specialized network setup doesn't belong into the installer dialogs. The manual method should stay open, though. Not that doing a "Mac failover" would be useful when running the installer. -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739p3xa37@tac.ki.iif.hu
Re: installation manual patch for isohybrid
Christian PERRIER writes: > Quoting Joey Hess (jo...@debian.org): > >> I would like to apply this to the manual so that it does not fall out of >> sync with what is released. I hope translations will be maneagable; I >> tried to keep the new text small. > > > Seems fine to me. Late for translations, for sure, but the few > translators for i-g cazn probably cope with it. This is much needed good stuff! If you could fold in the remaining minor points of #604839 (mainly 8.3 file names and mbr.bin) that would be even greater and this bug could be closed by the change, even. :) -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877hefxaov@tac.ki.iif.hu
Re: [PATCH 3/3] Silence a compiler warning.
Julien Cristau writes:
> On Fri, Jan 7, 2011 at 00:31:07 +0100, Ferenc Wagner wrote:
>
>> Ferenc Wagner writes:
>>
>>> -execvp("udhcpc", arguments);
>>> +/* execvp doesn't like const strings for no reason, so we can
>>> + cast away the const to suppress the compiler warning */
>>> +execvp("udhcpc", (char **)arguments);
>>
>> Actually, I started to feel bad about this part. Maybe it would be
>> wiser to use non-const strings from the beginning? That would require a
>> larger patch, though... And ignoring the warning hasn't caused any
>> trouble yet. Does anybody know why execvp hates const strings?
>
> execvp takes 'char *const argv[]', not 'const char **argv'.
That's exactly why a cast is needed here (I could have written
char * const * just as well, the point is the constness of the char, not
that of the char*). I found out why this is so. Quoting
http://pubs.opengroup.org/onlinepubs/009695399/functions/execl.html:
The argv[] and envp[] arrays of pointers and the strings to which
those arrays point shall not be modified by a call to one of the exec
functions, except as a consequence of replacing the process image.
[...]
The statement about argv[] and envp[] being constants is included to
make explicit to future writers of language bindings that these
objects are completely constant. Due to a limitation of the ISO C
standard, it is not possible to state that idea in standard C.
Specifying two levels of const- qualification for the argv[] and
envp[] parameters for the exec functions may seem to be the natural
choice, given that these functions do not modify either the array of
pointers or the characters to which the function points, but this
would disallow existing correct code. Instead, only the array of
pointers is noted as constant. [...]
I found the answer at
http://stackoverflow.com/questions/190184/execv-and-const-ness
So the cast is actually safe after all, but some reference should
probably be put into the comment.
--
Regards,
Feri.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8739p43lzv@tac.ki.iif.hu
Re: [PATCH 2/3] Make udhcpc continuously retry getting a lease until dhcp_timeout.
Matthew Palmer writes: > On Thu, Jan 06, 2011 at 09:32:02PM +0100, Ferenc Wagner wrote: > >> Signed-off-by: Ferenc Wagner >> --- >> packages/netcfg/dhcp.c | 10 -- >> 1 files changed, 8 insertions(+), 2 deletions(-) >> >> diff --git a/packages/netcfg/dhcp.c b/packages/netcfg/dhcp.c >> index f706c5c..385799b 100644 > > I've reviewed and tested this patch, and it looks good. I tested it by > running a DHCP install with the DHCP server off, and then starting it when > the progress bar was at around 50%. Without the patch applied, DHCP failed > and I was asked to manually configure the network. With the patch applied, > udhcpc quickly found the DHCP server and we were away. Dumping the traffic > with tcpdump also showed a lot more DHCP requests flying around. Thanks for the review and the testing! > I'd recommend this patch be applied before the Squeeze release, as there are > a number of bugs related to DHCP timeouts, as Ferenc mentions. I'm not sure > that the other patches should be applied pre-Squeeze; the cleanups involved > are minor. Yes, they don't even influence the object code I suppose. I included the first only because the next part touched that line anyway, so it would feel silly to leave the mistake in place. > Otavio, any objection to me committing this patch to SVN? (I'm assuming > that Ferenc doesn't have SVN commit access...) Correct. :) -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwt52dpj@tac.ki.iif.hu
Re: [PATCH 3/3] Silence a compiler warning.
Ferenc Wagner writes:
> -execvp("udhcpc", arguments);
> +/* execvp doesn't like const strings for no reason, so we can
> + cast away the const to suppress the compiler warning */
> +execvp("udhcpc", (char **)arguments);
Actually, I started to feel bad about this part. Maybe it would be
wiser to use non-const strings from the beginning? That would require a
larger patch, though... And ignoring the warning hasn't caused any
trouble yet. Does anybody know why execvp hates const strings?
--
Thanks,
Feri.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lj2xd2ys@tac.ki.iif.hu
[PATCH 1/3] Fix the type of the option array element.
As long as all pointers are of the same size (as usual), this doesn't make a difference. Signed-off-by: Ferenc Wagner --- packages/netcfg/dhcp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/packages/netcfg/dhcp.c b/packages/netcfg/dhcp.c index f7ffa00..f706c5c 100644 --- a/packages/netcfg/dhcp.c +++ b/packages/netcfg/dhcp.c @@ -205,7 +205,7 @@ int start_dhcp_client (struct debconfclient *client, char* dhostname) params: 5 hostname: 2 NULL: 1 */ -arguments = malloc((options_count * 2 + 5 + 2 + 1) * sizeof(char **)); +arguments = malloc((options_count * 2 + 5 + 2 + 1) * sizeof(char *)); /* set the command options */ options_count = 0; -- 1.7.2.3 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e33afa581a85861e8758b11f9843da292f747557.129433.git.wf...@niif.hu
[PATCH 0/3] Make udhcpc continuously retry getting a lease until dhcp_timeout
Hi, Turns out my problem wasn't exactly network card specific, but somehow more deeply related to the surrounding network switch configurations. Anyhow, the concrete problem was that udhcpc sent out 3 DHCPDISCOVER packets only in the first couple of seconds, then spent its remaining time before netcfg/dhcp_timeout sleeping (doing nothing), as prescribed by its default timing parameters (-t 3 -T 3 -A 20). I modified it to keep sending DHCPDISCOVER packages in every second allowed by the timeout (or until it acquires a lease) by supplying -T 1 and a dynamic retry number (-t). The first patch fixes a typo only and has no effect whatsoever. The second patch is the main stuff. The third patch gets rid of a compiler warning (which should be safe as I understand it). I think this fix (besides curing automatic network configuration in slow-starting networks) helps sidestepping some of the slow link-up problems which recently emerged (at least when DHCP is used). Thanks, Feri. Ferenc Wagner (3): Fix the type of the option array element. Make udhcpc continuously retry getting a lease until dhcp_timeout. Silence a compiler warning. packages/netcfg/dhcp.c | 17 - 1 files changed, 12 insertions(+), 5 deletions(-) -- 1.7.2.3 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cover.129433.git.wf...@niif.hu
[PATCH 2/3] Make udhcpc continuously retry getting a lease until dhcp_timeout.
Signed-off-by: Ferenc Wagner
---
packages/netcfg/dhcp.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/packages/netcfg/dhcp.c b/packages/netcfg/dhcp.c
index f706c5c..385799b 100644
--- a/packages/netcfg/dhcp.c
+++ b/packages/netcfg/dhcp.c
@@ -138,6 +138,7 @@ int start_dhcp_client (struct debconfclient *client, char*
dhostname)
int options_count;
enum { DHCLIENT, PUMP, UDHCPC } dhcp_client;
int dhcp_seconds;
+char dhcp_seconds_str[16];
if (access("/sbin/dhclient", F_OK) == 0)
dhcp_client = DHCLIENT;
@@ -153,6 +154,7 @@ int start_dhcp_client (struct debconfclient *client, char*
dhostname)
debconf_get(client, "netcfg/dhcp_timeout");
dhcp_seconds = atoi(client->value);
+snprintf(dhcp_seconds_str, sizeof dhcp_seconds_str, "%d", dhcp_seconds-1);
if ((dhcp_pid = fork()) == 0) { /* child */
/* disassociate from debconf */
@@ -202,10 +204,10 @@ int start_dhcp_client (struct debconfclient *client,
char* dhostname)
/* Allow space for:
options: options_count * 2
- params: 5
+ params: 9
hostname: 2
NULL: 1 */
-arguments = malloc((options_count * 2 + 5 + 2 + 1) * sizeof(char
*));
+arguments = malloc((options_count * 2 + 9 + 2 + 1) * sizeof(char
*));
/* set the command options */
options_count = 0;
@@ -214,6 +216,10 @@ int start_dhcp_client (struct debconfclient *client, char*
dhostname)
arguments[options_count++] = interface;
arguments[options_count++] = "-V";
arguments[options_count++] = "d-i";
+arguments[options_count++] = "-T";
+arguments[options_count++] = "1";
+arguments[options_count++] = "-t";
+arguments[options_count++] = dhcp_seconds_str;
for (ptr = dhclient_request_options_udhcpc; *ptr; ptr++) {
arguments[options_count++] = "-O";
arguments[options_count++] = *ptr;
--
1.7.2.3
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/f130572ac518a3a277238742c6a7ce31f2d8f807.129433.git.wf...@niif.hu
[PATCH 3/3] Silence a compiler warning.
Signed-off-by: Ferenc Wagner
---
packages/netcfg/dhcp.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/packages/netcfg/dhcp.c b/packages/netcfg/dhcp.c
index 385799b..ce93b26 100644
--- a/packages/netcfg/dhcp.c
+++ b/packages/netcfg/dhcp.c
@@ -133,8 +133,7 @@ static void dhcp_client_sigchld(int sig __attribute__
((unused)))
int start_dhcp_client (struct debconfclient *client, char* dhostname)
{
FILE *dc = NULL;
-const char **ptr;
-char **arguments;
+const char **ptr, **arguments;
int options_count;
enum { DHCLIENT, PUMP, UDHCPC } dhcp_client;
int dhcp_seconds;
@@ -232,7 +231,9 @@ int start_dhcp_client (struct debconfclient *client, char*
dhostname)
arguments[options_count] = NULL;
-execvp("udhcpc", arguments);
+/* execvp doesn't like const strings for no reason, so we can
+ cast away the const to suppress the compiler warning */
+execvp("udhcpc", (char **)arguments);
free(arguments);
break;
}
--
1.7.2.3
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/494d12e656ca3be61fda81d31ee75ea5ee363634.129433.git.wf...@niif.hu
Bug#362029: Patch to attach
Matthew Palmer writes:
> Index: netcfg/dhcp.c
> ===
> --- netcfg/dhcp.c (revision 66154)
> +++ netcfg/dhcp.c (working copy)
> @@ -521,6 +521,7 @@ (after udhcpc exited with a lease)
> }
>
> netcfg_nameservers_to_array (nameservers,
> nameserver_array);
> +netcfg_write_resolv (domain, nameserver_array);
> }
>
> state = HOSTNAME;
> @@ -602,6 +603,16 @@ (in case DOMAIN:)
> else {
> netcfg_write_common(ipaddress, hostname, domain);
> netcfg_write_dhcp(interface, dhostname);
> +/* If the resolv.conf was written by udhcpc, then
> nameserver_array
> + * will be empty and we'll need to populate it. If we asked
> for
> + * the nameservers, then it'll be full, but nobody will care
> if we
> + * refill it.
> + */
> +if (read_resolv_conf_nameservers(nameserver_array))
> +netcfg_write_resolv(domain, nameserver_array);
> +else
> +printf("Error reading resolv.conf for nameservers\n");
> +
> return 0;
> }
> break;
Hi,
This seems to do the job, but the control flow in netcfg is already
convoluted enough, isn't there a better alternative? I mean, for a
static configuration, netcfg_write_resolv is called from
netcfg_write_static, can't we follow suit in netcfg_write_dhcp? If
netcfg always removed resolv.conf before calling the DHCP client, then
we could modify resolv_conf_entries to also populate nameserver_array,
and then unconditionally write out resolv.conf in netcfg_write_dhcp,
couldn't we? Just thinking out loud
> @@ -646,3 +657,41 @@
>
> return count;
> }
> +
> +/* Read the nameserver entries out of resolv.conf and stick them into
> + * nameservers_array, so we can write out a newer, shinier resolv.conf
> + */
> +int read_resolv_conf_nameservers(struct in_addr array[])
> +{
> +FILE *f;
> +int i = 0;
> +
> +if ((f = fopen(RESOLV_FILE, "r")) != NULL) {
> +char buf[256];
> +
> +while (fgets(buf, 256, f) != NULL) {
> +char *ptr;
> +
> +if (strncmp(buf, "nameserver ", strlen("nameserver ")) == 0) {
> +/* Chop off trailing \n */
> +while (buf[strlen(buf)-1] == '\n')
> +buf[strlen(buf)-1] = '\0';
Why is this "while" instead of "if"?
> +ptr = buf + strlen("nameserver ");
> +inet_pton(AF_INET, ptr, &array[i++]);
> +if (i == 3) {
We really should use a global constant here (and in netcfg.h and in
netcfg_nameservers_to_array at least) instead of the magic number 3...
> +/* We can only hold so many nameservers, and we've
> reached
> + * our limit. Sorry.
> + */
--
Regards,
Feri.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sjxf2eih@tac.ki.iif.hu
Bug#603960: Same problem occurs with amd64 iso image
unmerge 603960 retitle 603960 Linux 2.6.32 EDD probe takes 30 seconds when booted from CD-ROM thanks Eric Wayman writes: > I just tested the original beta2 squeeze installer. Selecting > "Install" from the splash screen menu exhibited the same behavior as > with the special ISO you had linked me to: a 30-second or so wait, and > then the installer process began and the language menu showed up. Hi Eric, Great, thank for the testing! > Replacing the closing "-- quiet" with "edd=off" as you instructed, the > installer still worked. In this case however, there was no wait at all > for the language menu to show up. So the pause is definitely EDD-related, and it doesn't happen when you boot the squeeze kernel from your hard disk, right? If so, then this looks much like a BIOS oddity. To everybody: I wonder why edd=off isn't the default in the installer, does d-i load the edd module and use the info it provides? Apart from this the issue seems unrelated to the Debian Installer. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tyi1sqmr@tac.ki.iif.hu
Bug#603960: Same problem occurs with amd64 iso image
Eric Wayman writes: > I just tested the ISO you linked me to; sorry for the long delay in my > response. Hi Eric, No problem, thanks for testing! > Basically, everything works. [...] > I think I see what the issue is. When I entered "test" and "test-788", > it took about 30 seconds to complete the "Probing EDD (edd-off to > disable)..." step. At that time, I thought it might have jammed as > before. However, after waiting 30 seconds, everything worked properly. > > Selecting "Install" from the splash screen menu, I also had to wait > about 30 seconds before the splash screen disappeared and I was taken > into the installer process. > > I believe that this wait is probably the "bug" I was experiencing with > the beta2 installer. So it is likely that the "bug" is just the long > wait time which led me to believe the installer had jammed. This > problem did not exist on Debian Lenny. > > I hope this is helpful! If you would like me to submit this > information somewhere, please tell me how so that they know that I > used a different install version. This is immensely useful. I Cc-d the bug report, so you needn't submit this separately anymore. However, I'd like to ask you test two more things if possible: please try the original beta2 squeeze installer again, giving the EDD probe some more time to time out. Then, whatever happens, boot again, press TAB on the Install menu item, and replace the closing "-- quiet" with "edd=off" on the command line. Please report back your findings with keeping the bug address on Cc. -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87oc8btteg@tac.ki.iif.hu
Bug#607906: debian-installer: oops and panic after hardware detection
Package: debian-installer Version: squeeze beta2 netinst started from HDD by grub Severity: normal Hi, On an IBM x345 I reliably get a longish hang during "Detecting disks and all other hardware", then a BUG and a resulting panic. The BUG isn't always the same, as the two attached console logs show (made with the text frontend and full preseed -- but it also happens without the latter). I'll try to find out exactly what provokes the kernel Oops, but comments are much welcome anyway. Thanks, Feri. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.32-5-486 (Debian 2.6.32-27) (m...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 Sat Oct 30 22:14:18 UTC 2010 [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] NSC Geode by NSC [0.00] Cyrix CyrixInstead [0.00] Centaur CentaurHauls [0.00] Transmeta GenuineTMx86 [0.00] Transmeta TransmetaCPU [0.00] UMC UMC UMC UMC [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009d400 (usable) [0.00] BIOS-e820: 0009d400 - 000a (reserved) [0.00] BIOS-e820: 000e - 0010 (reserved) [0.00] BIOS-e820: 0010 - 5ffeb2c0 (usable) [0.00] BIOS-e820: 5ffeb2c0 - 5fff (ACPI data) [0.00] BIOS-e820: 5fff - 6000 (reserved) [0.00] BIOS-e820: fec0 - 0001 (reserved) [0.00] DMI 2.3 present. [0.00] last_pfn = 0x5ffeb max_arch_pfn = 0x10 [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] init_memory_mapping: -377fe000 [0.00] RAMDISK: 5f997000 - 5ffdae21 [0.00] Allocated new RAMDISK: 0010 - 00743e21 [0.00] Move RAMDISK from 5f997000 - 5ffdae20 to 0010 - 00743e20 [0.00] ACPI: RSDP 000fdfc0 00014 (v00 IBM ) [0.00] ACPI: RSDT 5ffeff80 00030 (v01 IBMSERONYXP 1000 IBM 45444F43) [0.00] ACPI: FACP 5ffeff00 00074 (v01 IBMSERONYXP 1000 IBM 45444F43) [0.00] ACPI: DSDT 5ffeb2c0 04A4E (v01 IBMSERGEODE 1000 MSFT 010B) [0.00] ACPI: FACS 5ffefe00 00040 [0.00] ACPI: APIC 5ffefe40 00092 (v01 IBMSERONYXP 1000 IBM 45444F43) [0.00] ACPI: ASF! 5ffefd80 0004B (v16 IBMSERONYXP 0001 IBM 45444F43) [0.00] 647MB HIGHMEM available. [0.00] 887MB LOWMEM available. [0.00] mapped low ram: 0 - 377fe000 [0.00] low ram: 0 - 377fe000 [0.00] node 0 low ram: - 377fe000 [0.00] node 0 bootmap 8000 - ef00 [0.00] (7 early reservations) ==> bootmem [00 - 00377fe000] [0.00] #0 [00 - 001000] BIOS data page ==> [00 - 001000] [0.00] #1 [000100 - 0001450a28]TEXT DATA BSS ==> [000100 - 0001450a28] [0.00] #2 [09d400 - 10]BIOS reserved ==> [09d400 - 10] [0.00] #3 [0001451000 - 0001457228] BRK ==> [0001451000 - 0001457228] [0.00] #4 [007000 - 008000] PGTABLE ==> [007000 - 008000] [0.00] #5 [10 - 743e21] NEW RAMDISK ==> [10 - 743e21] [0.00] #6 [008000 - 00f000] BOOTMAP ==> [008000 - 00f000] [0.00] found SMP MP-table at [c009d540] 9d540 [0.00] Zone PFN ranges: [0.00] DMA 0x -> 0x1000 [0.00] Normal 0x1000 -> 0x000377fe [0.00] HighMem 0x000377fe -> 0x0005ffeb [0.00] Movable zone start PFN for each node [0.00] early_node_map[2] active PFN ranges [0.00] 0: 0x -> 0x009d [0.00] 0: 0x0100 -> 0x0005ffeb [0.00] Using APIC driver default [0.00] ACPI: PM-Timer IO Port: 0x488 [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x06] enabled) [0.00] ACPI: NR_CPUS/possible_cpus limit of 1 reached. Processor 1/0x6 ignored. [0.00] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) [0.00] ACPI: NR_CPUS/possible_cpus limit of 1 reached. Processor 2/0x1 ignored. [0.00] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x07] enabled) [0.00] ACPI: NR_CPUS/possible_cpus limit of 1 reached. Processor 3/0x7 ignored. [0.00] ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x06] dfl dfl lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x07] dfl dfl lint[0x1]) [0.00] ACPI: IOAPIC (id[0x0e] address[0xfec0] gsi_base[0]) [0.00] IOA
Re: How to build a cdrom debian-installer with preseed.cfg
Jose Luis Zabalza writes: > Is there a smart way to build a d-i initrd with pressed.cfg inside? > Now I uncompress, copy preseed.cfg and compress again the initrd.gz file. > is this the only one way to get a initrd.gz with preseed? No, but this is the most general way. The other is using multiple initrds, if your boot method supports it. The Syslinux family does, you can supply multiple files separated by commas. Probably you could also emulate this by concatenating initrd images with appropriate padding, but I never tried this myself. > Note: I have not found any clear information about this on Debian > GNU/Linux Installation Guide or Internals manual. The principle is there: you have to get a file called preseed.cfg into the root directory. You choose the way... -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxnx1jzc@tac.ki.iif.hu
Re: GTK
Michal Filka writes: > how can I remove GTK support from debian-installer? By removing the appropriate initrd file. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y67iujto@tac.ki.iif.hu
Bug#605759: [s390/hercules] disk partitioning failed: no /dev/dsda1
Niko Tyni writes: > On Thu, Dec 16, 2010 at 05:37:55PM +0100, Ferenc Wagner wrote: > >> Niko Tyni writes: >> >>> Hercules s390 emulator installation failed at disk partitioning; >>> new partitions don't seem to show up in /dev. >> >> Thanks for the detailed but to-the-point report. This may be a kernel, >> a udev or a partman issue. Could you please try backing out of the >> partitioning menu to the main menu, start a shell in the installer >> environment with the appropriate menu item and do the partitioning >> yourself by fdasd or whatever's needed? Then please check if the new >> partitions show up in /proc/partitions and under /dev. This would help >> us narrowing down the case. > > It works fine if I create the partition manually with fdasd. Thanks, that's good info. Now the question is why parted_server failed to refresh the DASD partitions. It's a pity you didn't attach /var/log/partman. Could you please attach it to the bug report, preferably together with /var/log/syslog? You could get them by selecting "Save debug logs" from the installer main menu. Wait, see below. > Furthermore, if I try to create a partition first with the d-i interface > (getting the error) and then invoke fdasd and write out a trivial no-op > such as change the volume serial from LIN120 to LIN120, /dev/dasda1 > appears. So libparted commits the partition, only fails to notify the kernel. > It looks to me like the problem is that d-i does not manage to reread > the partition table. Agreed. > I'm not sure if I understand the architecture correctly here, but > maybe the problem is this change in parted 2.3 ? > > libparted: remove now-worse-than-useless _kernel_reread_part_table > Now that we're using BLKPG properly, there's no point in using the > less-functional BLKRRPART ioctl to make the kernel reread the > partition > table. > More importantly, this function would fail when any partition is in > use, in spite of our having carefully vetted them via BLKPG ioctls. > > I see fdasd (as of s390-tools 1.8.3-3) uses BLKRRPART and not BLKPG. > > The timeline would also fit the successful reports #569209 and #575682. This looks a fairly plausible theory, and the outcome is even more interesting, search for DASD in git log libparted/arch/linux.c. As I understand it, 9fa0e180 may even fix this problem. > I suppose I can try to hack parted to use BLKRRPART again and see if > that helps, but it's probably going to take a few days as I need to > get the emulator up and running first so I can rebuild the udeb. Probably you'd be better off backporting the relevant changes to 2.3-4 and testing that. -- Good luck, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r5dgmda0@tac.ki.iif.hu
Bug#605562: installation-report: Installation from usb stick lead to unbootable system (und unbootable usb stick)
Alexander Reichle-Schmehl writes: > Am 02.12.2010 11:36, schrieb Alexander Reichle-Schmehl: > >> I saved the contents of /var/log/installer after the installation, but >> need to recover mu original system for now to do some work. > > Ähh... Sorry. It seems it wasn't a good idea to tar /var/log/installer > to /tmp. So I don't have the logs from my attempt with the daily > installer, but I still have the ones from the installation with beta-1. > > I think I can also try to reproduce it on a similar machine whenever you > want me to test something without much delay. Hi Alexander, Could you please retest with a beta-2 image, just to make sure that the issue is still present? And please keep the logs this time! :) -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zks4mk57@tac.ki.iif.hu
Bug#605759: [s390/hercules] disk partitioning failed: no /dev/dsda1
tag 605759 +moreinfo thanks Niko Tyni writes: > Hercules s390 emulator installation failed at disk partitioning; > new partitions don't seem to show up in /dev. Hi, Thanks for the detailed but to-the-point report. This may be a kernel, a udev or a partman issue. Could you please try backing out of the partitioning menu to the main menu, start a shell in the installer environment with the appropriate menu item and do the partitioning yourself by fdasd or whatever's needed? Then please check if the new partitions show up in /proc/partitions and under /dev. This would help us narrowing down the case. -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wrn9hdwc@tac.ki.iif.hu
Bug#606976: Kernel panic with Squeeze (AMD64) d-i beta 2
tag 606976 +moreinfo thanks Taro Sato writes: > I've tried d-i beta 2 on Dell XPS 630i. I first tried creating a USB > memory stick with the installer .iso on it (following a standard > procedure); the install USB stick works on my other computer (Lenovo > T410s). However, on 630i it always fails at the beginning of the > install process. The message, when kernel panics, typically goes like > this: > > ... (no apparent error messages thru this point) ... > [0.597991] List of all partitions: > [0.600310] No filesystem could mount root, tried: > [0.602749] Kernel panic - not syncing: VFS: Unable to mount root fs on > unknown-block(8,3) > ... (call trace output after this) ... > > (This output is from an attempt to use CD install medium.) Hi, I have to say that all of this looks very much out of place. First of all, the boot menu should start the kernel with the "quiet" parameter, so you should see no messages before the kernel panic. 1. Did you edit the command line in the boot loader or by any other means? 2. What was your exact sequence of actions after powering on your computer with the CD in the drive? The above message indicates that no initramfs was loaded with the kernel, or maybe it was corrupt. If you didn't remove the "quiet" parameter from the kernel command line, you'd see the message Initramfs unpacking failed: junk in compressed archive in the latter case. 3. What messages do you get with the "quiet" parameter? You could also try writing the mini.iso downloaded from http://ftp.nl.debian.org/debian/dists/testing/main/installer-amd64/current/images/netboot/mini.iso to a pendrive and test that. If you pendrive (the full device) is /dev/sdb, then just do cat mini.iso >/dev/sdb and try to boot from the pendrive. This is very similar to the method used for HD media, except that boot.img.gz is compressed. > Is there any way to get Squeeze d-i to work on this machine? There should be. Please do the above tests and report back to help us find out how. -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877hf9isyp@tac.ki.iif.hu
Bug#603960: Same problem occurs with amd64 iso image
tag 603960 +moreinfo thanks Eric Wayman writes: > This bug also occurs when using the amd64 iso image > (http://cdimage.debian.org/cdimage/squeeze_di_beta2/amd64/iso-cd/debian-squeeze-di-beta2-amd64-netinst.iso), > downloaded 2010-12-10. Exactly the same behavior is exhibited: I get > to the splash screen, and hit Enter. Then it reads from the CD drive, > and then stops reading, and nothing happens. The splash screen is > still displayed. Then if I start pressing keys, after several presses, > beeping starts. Hi Eric, Please try the image at http://apt.niif.hu/debian-squeeze-di-beta2-amd64-netinst_4.04-pre3.iso This is a remastered installer built with the debugging version of the newest upstream Isolinux and a modified config which makes it easy to skip the graphical menu for getting more progress output. After the isolinux banner appears, it should inform you that you can type text and text-788 at the boot prompt. You've got 10 seconds to start typing, please test both options. -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762uwyse9@tac.ki.iif.hu
Bug#606636: Reverse DNS takes precedence over netcfg/get_hostname
Floris Bos writes: > On Friday, December 10, 2010 05:17:15 pm Ferenc Wagner wrote: > >> Floris Bos writes: >> >>> The value specified using "netcfg/get_hostname" seems to be ignored, if a >>> reverse DNS entry is present for the IP-address of the server being >>> installed. [...] >>> I think netcfg/get_hostname should take precendence over everything else. >> >> Half of the current behaviour is documented in >> http://d-i.alioth.debian.org/manual/en.i386/apbs04.html#preseed-network >> Maybe the idea was to enable skipping the question without specifying a >> fixed name. > > Well, if you think people rely on the current behavior because it's partial > documented I certainly do... Maybe that's my problem, though. :) > then treat my bug report as a feature request for a preseed option to > override this behavior. Fair enough. But I doubt its feasibility before squeeze... > Not everyone has the power to change their own reverse DNS entries, or it > might take time to process (send a request to the upstream provider that is > responsible for the IP block, wait for them to process it, and reload the > nameserver zonefile). > And people like to be able to choose their own hostname. Yeah. Currently they can either 1. not preseed it but type in during installation, or 2. set it in the DNS records. Looks like it worked good enough till now. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bp4tic2x@tac.ki.iif.hu
Bug#606654: Busybox should include arping applet
Floris Bos writes: > On Friday, December 10, 2010 05:12:39 pm Ferenc Wagner wrote: > >> Floris Bos writes: >> >>> I think the arping applet should be enabled in the Busybox build. >>> It helps a great deal in debugging general network issues and could be >>> helpful to create a solution for some other bugs like: >>> >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537271 (network may not >>> be usable as soon as link is up) >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606515 (Preseed >>> installation does not wait for network to be ready) >> >> Please read >> http://wiki.debian.org/DebianInstaller/FAQ#Q.3AWhyispingnotavailableinthede >> bugshell >> >> Roughly the same applies to arping. After all, you can cat /proc/net/arp >> to check whether the gateway has a complete entry. > > But wouldn't you need to initiate network communication before an entry in > /proc/net/arp for the gateway appears? Yes, sure. > Right now PXE preseed installations are broken, making Debian unsuitable for > use by dedicated server providers. > The Debian installer does not wait for the network link to come up (can take > about 3 seconds on some NICs connected to a standard Gigabit switch), > nor does it take into account that it can take 30 seconds before network > activity is possible in spanning tree configurations. I agree that this is a problem, I've been bitten by this recently. > A simply 1-line fix if we had arping might be executing between netcfg and > network-preseed: > > arping -f -c 35 $GATEWAY_IP > > (wait until you get an ARP reply from the gateway, timeout after 35 > seconds/tries). Something like that should go *into* netcfg, between configuring the network statically and querying the DNS for the name of the configured IP address. For DHCP, udhcpc should be invoked with -t 20 or similar, so that it doesn't just sleep most of the time but actually tries to get a license during the time allowed by the dialog timeout. > I don't think calling wget 35 times, and grepping /proc/net/arp is a clean > alternative, just to save 4 KB of space. wget isn't pretty, but one could do something like while [ "$i" -lt 30 ] && ! nc -w 1 GATEWAY 80 -e /bin/true; do i=$(($i + 1)); done grep "^GATEWAY .* 00:00:00:00:00:00 " /proc/net/arp && echo fail for example. But netcfg is written in C, and this stuff belongs to there, where one could do even better. -- Cheers, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lj3xie5h@tac.ki.iif.hu
Re: boot parameter interface=auto can't adaptation the correct NIC
lsore...@csclub.uwaterloo.ca (Lennart Sorensen) writes: > On Fri, Dec 10, 2010 at 05:45:30PM +0800, Qin Bo wrote: >> Dec 10 10:49:14 netcfg[3916]: INFO: eth0 is disconnected. (MII) >> Dec 10 10:49:14 netcfg[3916]: INFO: eth0 is not a wireless interface. >> Continuing. >> Dec 10 10:49:14 netcfg[3916]: INFO: eth1 is disconnected. (MII) >> Dec 10 10:49:14 netcfg[3916]: INFO: eth1 is not a wireless interface. >> Continuing. >> Dec 10 10:49:14 kernel: [ 93.801715] ADDRCONF(NETDEV_UP): eth1: link is >> not ready >> Dec 10 10:49:14 kernel: [ 93.804385] e1000: eth1 NIC Link is Up 1000 Mbps >> Full Duplex, Flow Control: RX/TX >> Dec 10 10:49:15 netcfg[3916]: INFO: eth2 is disconnected. (MII) >> Dec 10 10:49:15 netcfg[3916]: INFO: eth2 is not a wireless interface. >> Continuing. >> Dec 10 10:49:15 kernel: [ 93.867068] ADDRCONF(NETDEV_UP): eth2: link is >> not ready >> Dec 10 10:49:15 main-menu[358]: (process:3915): udhcpc (v1.17.1) started >> Dec 10 10:49:15 main-menu[358]: (process:3915): Sending discover... >> Dec 10 10:49:15 main-menu[358]: (process:3915): Sending discover... >> Dec 10 10:49:15 main-menu[358]: (process:3915): Sending discover... >> Dec 10 10:49:15 main-menu[358]: (process:3915): udhcpc: has been called with >> an unknown param: leasefail >> Dec 10 10:49:15 main-menu[358]: (process:3915): Received SIGTERM >> Dec 10 10:49:15 main-menu[358]: INFO: Menu item 'netcfg' succeeded but > > Is this another case of a driver/NIC taking longer to get link up after > being enabled than the installer is willing to wait? I seem to recall > a bnx2 user a few days ago reporting a similar problem. Intersting timing above: udhcpc lives less than a second? I've also got a problem with link states, but that's more an unfortunate interleaving of events, see 'udhcpc timeout with tg3' from Dec. 6. Or maybe these timestamps are wrong for some reason? -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762v1jxh7@tac.ki.iif.hu
Bug#606636: Reverse DNS takes precedence over netcfg/get_hostname
Floris Bos writes: > The value specified using "netcfg/get_hostname" seems to be ignored, if a > reverse DNS entry is present for the IP-address of the server being installed. > [...] > I think netcfg/get_hostname should take precendence over everything else. Half of the current behaviour is documented in http://d-i.alioth.debian.org/manual/en.i386/apbs04.html#preseed-network Maybe the idea was to enable skipping the question without specifying a fixed name. -- Cheers, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjy5k3g4@tac.ki.iif.hu
Bug#606654: Busybox should include arping applet
Floris Bos writes: > I think the arping applet should be enabled in the Busybox build. > It helps a great deal in debugging general network issues and could be > helpful to create a solution for some other bugs like: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537271 (network may not be > usable as soon as link is up) > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606515 (Preseed installation > does not wait for network to be ready) Hi, Please read http://wiki.debian.org/DebianInstaller/FAQ#Q.3AWhyispingnotavailableinthedebugshell Roughly the same applies to arping. After all, you can cat /proc/net/arp to check whether the gateway has a complete entry. -- Cheers, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wrnhk3ns@tac.ki.iif.hu
Bug#606496: debian squeeze installer halts at boot menu
Dimitri Timofeev writes: > Installer displays boot menu, beeps and halts. Another laptop (Dell > Vostro 1310) boots ok and starts installer when using the same USB > stick. This may be the same as #604245 and #604560. Could you please try the workaround detailed in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604560#19? -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxoer1ob@tac.ki.iif.hu
udhcpc timeout with tg3
Hi, Testing the squuze beta1 installer I ran into a networking problem. Primary network interface: 1. eth0: Broadcom Corporation NetXtreme BCM5701 Gigabit Ethernet [*] 2. eth1: Broadcom Corporation NetXtreme BCM5701 Gigabit Ethernet Prompt: '?' for help, default=1> Configuring the network with DHCP ..13%..20%..33%..40%..53%..60%..73%..80%..93%..100% Network autoconfiguration failed Your network is probably not using the DHCP protocol. Alternatively, the DHCP server may be slow or some network hardware is not working properly. [Press enter to continue] Up to this, my DHCP server doesn't receive a single request. But a couple of seconds after this, a request comes and an IP gets leased to the installer. If I back out and execute a shell from the installer main menu, I can see the IP address assigned to eth0, although no udhcpc process is running by this time and eth0 is down. Running udhcpc eth0 manually confirms that it fails to get a request out during its first round of three packets, then it waits for too long before trying again: ~ # ip addr 1: lo: mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo 2: eth0: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 00:06:5b:8e:71:d5 brd ff:ff:ff:ff:ff:ff 3: eth1: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 00:06:5b:8e:71:d6 brd ff:ff:ff:ff:ff:ff ~ # dmesg -n8 ~ # udhcpc eth0 0.00 udhcpc (v1.17.1) started [ 1512.784911] ADDRCONF(NETDEV_UP): eth0: link is not ready 1.14 Sending discover... [ 1515.784728] tg3: eth0: Link is up at 1000 Mbps, full duplex. [ 1515.796034] tg3: eth0: Flow control is off for TX and off for RX. [ 1515.808388] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready 3.83 Sending discover... 6.69 Sending discover... 9.81 udhcpc: has been called with an unknown param: leasefail 29.85 Sending discover... Sending select for 10.253.2.7... Lease of 10.253.2.7 obtained, lease time 43200 (The first column contains my stopwatch readings). Uping the interface takes 3 seconds to complete, so the switch doesn't reach forwarding state (albeit portfast is set) before the first three packets are sent. Then netcfg times out before udhcpc would even try again 20 seconds later. It looks like the distribution of DHCPDISCOVER packets is less than ideal. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tyiqn3ps@tac.ki.iif.hu
Bug#605983: installation-report: PXE installation of HP Mini fails in partman step because network setup is lost
Joey Hess writes: > Ferenc Wagner wrote: > >> I've got access to Dell PE2650 machines with Tigon3 cards, which also >> work without the TSO firmware. I could probably seize one for testing >> if needed. > > I'd appreciate that. Ping me if you need a boot image for testing. Looks like I was wrong, my Tigon doesn't even ask for the firmware file, so hw-detect doesn't try to reload it. Sorry, I'm not in the position to test your patch, after all. I was misguided by update-initramfs warning me about "possibly missing firmware"... -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3peoo5q@tac.ki.iif.hu
Bug#605983: installation-report: PXE installation of HP Mini fails in partman step because network setup is lost
Petter Reinholdtsen writes: > [Joey Hess] > >> Attached patch implements that. Please test. > > I am unable to test. The Debian Edu developer gathering is over, and > the test machines have been placed back into their storage boxes. :( I've got access to Dell PE2650 machines with Tigon3 cards, which also work without the TSO firmware. I could probably seize one for testing if needed. -- Cheers, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ei9vp6cm@tac.ki.iif.hu
Bug#604245: [syslinux] Debian bug#604245: Syslinux fails (does not receive key presses on Sony vaio Z12C5E)
Gyorgy Jeney writes: > On 24 November 2010 21:54, Ferenc Wagner wrote: > >> Gyorgy Jeney writes: >> >>> On 24 November 2010 20:25, Ferenc Wagner wrote: >>> >>>> # sed -i '/^timeout/s/0/50/' /mnt/syslinux.cfg >>>> # umount /mnt >>>> >>>> and then try to boot the installer from the pendrive. Now it should >>>> automatically choose the default item in the boot menu after 5 seconds >>>> (unless syslinux is actually frozen by this time). >>> >>> I tried that. When the menu appears, at the bottom, it counts down 5, >>> 4, 3, 2, 1 and then reads something from the USB key for some time >>> (the activity light flashes on the key) and then just hangs at the >>> menu with the count being 1. I waited about a minute before rebooting >>> at this point. >> >> Looks like it actually tries to load the kernel. Could you please fully >> rewrite syslinux.cfg to contain only the following four lines and retest? >> >> default linux >> append initrd=initrd.gz >> prompt 1 >> timeout 50 >> >> This should skip the menu and also make the kernel more verbose. > > This results in the following output: > > SYSLINUX 4.02 debian-20101014 EDD Copyright (C) 1994-2010 H. Peter Anvin et al > Loading linux. > Loading initrd.gz...ready. > > And then hangs. Thanks. Looks like when installed this way, Syslinux can't pass execution to the loaded kernel on your machine. #604560 looks rather similar, so yours may not be the only problematic machine. Unfortunately I can't reproduce this in Qemu, so further debugging isn't easy, unless hpa or another developer comes forward with a clever idea. I'm pretty much at the end of my wits... Will try to repro this on some real hardware, though. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxoxo0ns@tac.ki.iif.hu
Bug#604560: Isn't this the same as #604245?
Hi, Please try the following: instead of extracting boot.img.gz straight into your pendrive (zcat boot.img.gz >/dev/sdX), create a DOS partition table on the pendrive with an at least 250MB large first partition, make the partition active (bootable), and extract boot.img.gz into that partition (zcat boot.img.gz >/dev/sdX1). Also put some boot code into the MBR (cat /usr/lib/syslinux/mbr.bin >/dev/sdX after installing the syslinux package), then try booting from it again. -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762vlsll0@tac.ki.iif.hu
Bug#604245: [syslinux] Debian bug#604245: Syslinux fails (does not receive key presses on Sony vaio Z12C5E)
Gyorgy Jeney writes: > On 24 November 2010 20:25, Ferenc Wagner wrote: > >> György, could you please make sure that it's a keyboard issue only, for >> example by introducing a short timeout by replacing "timeout 0" with >> "timeout 50" in syslinux.cfg? If your pendrive is /dev/sde, then do >> >> # zcat boot.img.gz >/dev/sde >> (just as you did originally, resulting in this bug report) >> # mount /dev/sde /mnt -oloop > > Just curious, is there a reason to use a loopback device here? That's the typo I left in accidentally to make your life harder. Sorry for that. (I was testing the above on a loop mount.) >> # sed -i '/^timeout/s/0/50/' /mnt/syslinux.cfg >> # umount /mnt >> >> and then try to boot the installer from the pendrive. Now it should >> automatically choose the default item in the boot menu after 5 seconds >> (unless syslinux is actually frozen by this time). > > I tried that. When the menu appears, at the bottom, it counts down 5, > 4, 3, 2, 1 and then reads something from the USB key for some time > (the activity light flashes on the key) and then just hangs at the > menu with the count being 1. I waited about a minute before rebooting > at this point. Looks like it actually tries to load the kernel. Could you please fully rewrite syslinux.cfg to contain only the following four lines and retest? default linux append initrd=initrd.gz prompt 1 timeout 50 This should skip the menu and also make the kernel more verbose. >> I wonder what the SYSLINUX banner says [...] > > SYSLINUX 4.02 debian-20101014 EDD Copyright (C) 1994-2010 H. Peter Anvin et al > > In both the partitionless and partitioned version. Thanks. So it uses the same disk access method (EDD) in both cases. -- Cheers, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y68i1lz1@tac.ki.iif.hu
Bug#604245: [syslinux] Debian bug#604245: Syslinux fails (does not receive key presses on Sony vaio Z12C5E)
"H. Peter Anvin" writes: > On 11/24/2010 07:34 AM, Ferenc Wagner wrote: > >> Syslinux certainly used to work partitionless. Maybe this feature was >> inadvertently lost during the major version change... Peter? > > It's possible... it's also possible there is something in memory which > looks like a partition handover table. But would that have a fighting chance to break keyboard interaction only, after displaying a correct menu? György, could you please make sure that it's a keyboard issue only, for example by introducing a short timeout by replacing "timeout 0" with "timeout 50" in syslinux.cfg? If your pendrive is /dev/sde, then do # zcat boot.img.gz >/dev/sde (just as you did originally, resulting in this bug report) # mount /dev/sde /mnt -oloop # sed -i '/^timeout/s/0/50/' /mnt/syslinux.cfg # umount /mnt and then try to boot the installer from the pendrive. Now it should automatically choose the default item in the boot menu after 5 seconds (unless syslinux is actually frozen by this time). Independently of the above, I wonder what the SYSLINUX banner says if it's started partitionless (like above) or from a partition (like when you dumped it into /dev/sde1). In the working case it's easy to find out by quitting the menu via ESC then pressing Ctrl-V. It will probably print "SYSLINUX 4.02 debian-20101014 EDD Copyright ...". In the first, non-working case it's easiest to get this by renaming syslinux.cfg, so that it isn't found, thus the banner isn't overwritten by the menu. Maybe this unbreaks your keyboard, even... :) -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3pu34no.fsf...@tac.ki.iif.hu
Bug#604839: installation-guide: USB booting/Syslinux info outdated
Package: installation-guide Severity: normal Tags: d-i Hi, With the rising popularity of such devices, booting from USB memory sticks is probably becoming the most common method of running the Debian Installer. At the same time, introduction of isohybrid images made HD images mostly obsolete, I think. Still, section 4.3. (Preparing Files for USB Memory Stick Booting) does not even mention this. Speaking about HD images: to my surprise they don't contain a partition table, so they are more partition images instead. Regardless, they usually work as full disk images, because the Syslinux boot sector works well in the MBR as well. But not always, cf. #604245 (still under investigation). But anyway, why is this so? This is inconsistent with the "flexible way" and also with the isohybrid ISOs. This also takes away the possibility of repartitioning the image (after writing it) to make room for firmware or whatever... For squeeze, this sentence should be deleted from 4.3.2.2.: If you want to rename the files, please note that syslinux can only process DOS (8.3) file names. It's complicated business, cf. http://syslinux.zytor.com/wiki/index.php/Common_Problems#What.27s_the_real_name_of_that_file.3F for further details. In practice, long filenames work all right. One more addition: the syslinux package contains MBR code as well, there's no need to install the mbr package, as 4.3.3. suggests. One can simply cat /usr/lib/syslinux/mbr.bin >/dev/sdX and make the boot partition the only active one. Finally, as #509938 points out, Syslinux isn't restricted to FAT since 4.00. This may be worth mentioning at least; I guess everybody with an EXT[234] formatted USB stick would be able to install Syslinux on it (via the extlinux command et al.) In summary I think a moderate overhaul of this section is needed, and I'm willing to help out. But I'm not sure about the status of the isohybrid images vs. boot.img.gz-s, for example... -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101124184636.19132.74632.report...@tac.ki.iif.hu
Bug#604245: [syslinux] Debian bug#604245: Syslinux fails (does not receive key presses on Sony vaio Z12C5E)
Gyorgy Jeney writes: > On 22 November 2010 22:46, Ferenc Wagner wrote: > >> "H. Peter Anvin" writes: >> >>> For a regression... I really need it narrowed down... 3.71 to 4.02 is a >>> huge change. >> >> That's of course true. György, are you willing to test some >> intermediate syslinux versions on this machine? > > I checked out the git version of syslinux and tried to do a bisection, > but there where so many un-testable points (uncompilable, fails due to > something else) between syslinux-3.86 (last known working) and > syslinux-4.00 (first known non-working) that I gave up on the > bisection. > > But then I noticed that I wasn't following the (debian) instructions > properly and I was writing the image to /dev/sde, instead of > /dev/sde1. As soon as a partition was created, an appropriate MBR > installed, the image in question worked on the Sony. > > Is such partition-less configurations supported? Hi all, First of all: I confused myself, isohybrid is totally out of the picture, your didn't use an ISO but an HD image. Now the really confusing this is that the documentation of the HD image http://ftp.nl.debian.org/debian/dists/squeeze/main/installer-amd64/current/images/hd-media/boot.img.gz *really* says it should be extracted straight into a full disk device, but the image does not contain a partition table, so actually it's a big, irregular floppy image. The same is true for the lenny image, btw. So I'd summarize the issue as: Syslinux 3.71 works when booted partitionless (with the Syslinux boot sector in the place of the MBR) from a USB drive on your machine, but 4.02 does not. Now, as I understand, your manual testing followed the partitionless scheme as well, and shows that even 3.86 works in this way, and 4.00 already fails. Right? On the other hand, if you created a partition on your USB drive and extracted the squeeze HD image into the partition, it started to work, right? Syslinux certainly used to work partitionless. Maybe this feature was inadvertently lost during the major version change... Peter? On the other hand, I don't understand why Debian uses partitionless HD images for the installer. -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871v6a4txm@tac.ki.iif.hu
Bug#604245: [syslinux] Debian bug#604245: Syslinux fails (does not receive key presses on Sony vaio Z12C5E)
"H. Peter Anvin" writes: > For a regression... I really need it narrowed down... 3.71 to 4.02 is a > huge change. That's of course true. György, are you willing to test some intermediate syslinux versions on this machine? They are distributed precompiled at http://www.kernel.org/pub/linux/utils/boot/syslinux/. 3.86 was the latest 3.xx release, so it isn't that bad. First of all, it would be important to know whether the issue is also present in the upstream 4.02 and the newest 4.03. Also, the squeeze installer is an isohybrid image, but it may be easier to test with simplest syslinux installations (after checking that isohybrid isn't the problem -- the lenny installer didn't use it). You can find current documentation on http://syslinux.zytor.com/wiki/index.php/SYSLINUX, but note that older versions can gradually deviate from that (though the bundled docs should be correct). -- Cheers, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wro5xc97@tac.ki.iif.hu
Bug#604245: [syslinux] Debian bug#604245: Syslinux fails (does not receive key presses on Sony vaio Z12C5E)
"H. Peter Anvin" writes: > On 11/21/2010 12:31 PM, Ferenc Wagner wrote: > >> Does this report ring a bell here? I didn't check, but the image should >> carry an isohybridized 4.02 version of isolinux. The working (lenny) >> version is 3.71. > > This often happens when the BIOS doesn't have "USB legacy" enabled to do > USB keyboard support from the boot environment; another possibility is > that the USB keyboard driver and the USB storage driver in the BIOS > conflict with each other. But earlier isolinux works on the very same hardware, that is, it's a regression, which is hard to explain with BIOS issues... Or do I miss something? -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tyj9s24c@tac.ki.iif.hu
Bug#604245: Debian bug#604245: Syslinux fails (does not receive key presses on Sony vaio Z12C5E)
Hi, Does this report ring a bell here? I didn't check, but the image should carry an isohybridized 4.02 version of isolinux. The working (lenny) version is 3.71. Thanks, Feri. Start of forwarded message Subject: Bug#604245: Syslinux fails Date: Sun, 21 Nov 2010 14:13:41 +0100 From: Gyorgy Jeney To: sub...@bugs.debian.org Boot method: USB key Image version: http://ftp.nl.debian.org/debian/dists/testing/main/installer-amd64/current/images/hd-media/boot.img.gz Date: Nov 21. 2010, 13:40 Machine: Sony vaio Z12C5E Processor: Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz Memory: 8Gb Output of lspci -knn (or lspci -nn): [see http://bugs.debian.org/604245] During boot, the syslinux menu appears (install, Graphical install, etc.), but doesn't respond to any key press, hence can not even boot the install kernel. Copying the initrd.gz and linux files from the above image to a lenny image (http://ftp.nl.debian.org/debian/dists/lenny/main/installer-amd64/current/images/hd-media/boot.img.gz) allows the install kernel to boot and complete the installation of squeeze. End of forwarded message -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877hg6a05l@tac.ki.iif.hu
Bug#604101: installation-reports: Broken textmode installer display on EEE PC 701SD
Samuel Thibault writes: > Christian PERRIER, le Sat 20 Nov 2010 08:19:31 +0100, a écrit : > >> Jeff, le Fri 19 Nov 2010 20:22:40 -0500, a écrit : >> >>> Later, I tried pressing TAB to change boot options and discovered that a >>> "vga=" option was being added by default. Removing this option allowed the >>> installer to proceed. >>> >>> Strangely enough, once the installation completed, the default options allow >>> the system to boot with no display probems AND the console font changes >>> successfully (although I still have an 80x25 console.) Therefore, it >>> appears that the installer's default options are more aggressive than the >>> default options of the installed system. This seems backwards, because >>> someone choosing the textmode installer wants the most conservative display >>> settings to maximize the probability of success. > > The boot menu item does not say "textmode installer". To really get text > mode installation, see the F8 help screen: vga=normal (to avoid the > vga=788 parameter), and fb=false to really have a textmode installer > (but then not be presented languages like chinese). > >> Reassigning to debian-installer as this is about boot options passed >> to the kernel. >> >> Dunno if we should drop the vga= setting or not > > I think that at best we just need to document that "Installer" is not a > pure textmode installer choice, possibly by adding a "Textmode install" > item in the boot menu (using fb=false vga=normal) Something like that would work for grub, which has no graphical splash screen but too late for isolinux on the optical installer media: cf. #509662 for example. -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87eiaf9e8j@tac.ki.iif.hu
Re: initrd is too fast for md
Michal Ludvig writes: > In my case scsi_wait_scan.ko didn't wait for all SCSI disks to be > discovered, debian initramfs moved on prematurely and failed > miserably. Recompiling the kernel without CONFIG_SCSI_SCAN_ASYNC fixed > the problem for me. Actually, you don't need to recompile the kernel for this, just add scsi_mod.scan=sync to your kernel command line. Or mention options scsi_mod scan=sync somewhere under /etc/modprobe.d and regenerate the initramfs. This attacks the problem from a different angle that rootdelay. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aalfsciy@tac.ki.iif.hu
Re: initrd is too fast for md
Ivan Jager writes: > The problem is that /scripts/local-top is running and trynig to set up > md before the hard drives are detected and show up in /dev. Add rootdelay=5 or similar to your kernel command line. This is documented in the installation guide. Yes, this is a workaround. Usually the scsi_wait_scan magic in scripts/init-premount/udev is good enough. > An earlier problem I had was that I had created md0 with / > mounted ro, so /etc/mdadm/mdadm.conf wasn't updated and when > generating the initrd, /conf/conf.d/md had MD_MODULES=''. That > took me a while to figure out, because I only needed to load > md-mod to get raid to work. It seems like it might be a good idea > to just modprobe md-mod near the top of /scripts/local-top/mdadm. That script explicitly loads all MD modules already. > Last of all, I seem to remember some plan to have things like md > and lvm started by udev which seems like it would have avoided > this problem. Unfortunately, that didn't take off. > Also, since when does initrd use udev? It seems like a static /dev > might avoid this probblem, at least if something caused mdadm to wait > for /dev/sda to be ready rather than giving up because the device file > didn't even exist. Well, mdadm does not wait, although it has an incremental mode nowadays. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3qd8rex@tac.ki.iif.hu
Re: is lilo ever installed by default anymore?
posion bit writes: > On Tue, Sep 21, 2010 at 9:38 AM, Christian Perrier wrote: > So, I would say that LILO is no longer the default installer for some installations of lenny. >>> >>> Do you mean Squeeze? >> >> Yes, Squeeze >> >>> What if /boot is on LVM (can happen with manual partitioning)? Grub2 >>> can (at least in principle) handle this, but I've never seen that in >>> action. >> >> Probably needs to be checked..:) > > I don't know If this may help, but I can say that the thinkpad where I > tested squeeze, all the disk is a single partition defined as LVM > volume group, and my logical volume /boot is into. D-I choosed grub2 > (and worked). > > Time ago, when you choosed /boot into LVM, lilo was choosed by d-i I think. This pretty much nails it. Thanks for the info! -- Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aanaf9y3@tac.ki.iif.hu
Re: is lilo ever installed by default anymore?
Christian PERRIER writes: > Quoting Steve Langasek (vor...@debian.org): > >> I'm working on cleaning up the release notes for the squeeze release, and in >> the section on post-upgrade lilo handling, we have this note, which is >> carried over from lenny (where it referred to etch): >> >> If you are using lilo as your bootloader (it is the default bootloader for >> some installations of lenny) it is strongly recommended that you rerun lilo >> after the upgrade. >> >> Can anyone confirm that it's actually the case in lenny that lilo is used by >> default is some situations? I'm not sure where in d-i to look for this. > > > Looking around in D-I SVN, I see no code under "packages/" that says > "don't install grub-installer and use lilo-installer instead". > > So, only the packages' priorities and the Menu-Item number can give > precedence of one over the other > > Packages are "Priority: standard" and grub-installer has a lower menu > entry number. > > So, in short, I don't see any default install path where users would > end up with lilo-installer being executed in place of grub-installer. > > The only path seems to be an expert install and explicitly choosing to > install LILO instead of GRUB. > > So, I would say that LILO is no longer the default installer for some > installations of lenny. Do you mean Squeeze? What if /boot is on LVM (can happen with manual partitioning)? Grub2 can (at least in principle) handle this, but I've never seen that in action. -- Cheers, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lj6v1rcs@tac.ki.iif.hu
Bug#597087: debian-installer: Swap space is too big when created by the guided partitioner
"Nelson A. de Oliveira" writes:
> On Fri, Sep 17, 2010 at 2:54 PM, Christian PERRIER wrote:
>
>> Indeed, 3 times the memory size seems too big, particularly with large
>> amounts of RAM ("large" varies over time!).
>
> I was reading the recipes in partman-auto and while it seems that it's
> not possible with the infrastructure that we have now, something like
> an inverse exponential function would fit, I think.
> For example, with a small amount of RAM a swap space of 300% the RAM
> size would be created.
> Then the higher the RAM size available, the smaller the swap space created.
> On a system with 8GB, instead creating a swap space of 24GB (300%), we
> could have 4GB only (50%, or even less).
>
> Just a suggestion (that needs to be thought better).
Suspend to disk can easily require 100% swap space (assuming you run
some big application in your big memory). The main problem is that it
isn't easy to modify the automatic swap allocation. Nowadays I'd
recommend going with LVM and leaving some space unused for future
allocation (which again require manual partitioning).
Regarding the LVM recipes in general, they suck up all available space,
negating a strong point of LVM: flexible future allocation. (In
principle one could shrink some filesystems and reallocate space, but
that's often impractical even when possible.) Just some thoughts.
--
Regards,
Feri.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ocbs1piu@tac.ki.iif.hu
Bug#589672: installation-reports: remote console netboot install
"j.konrad" writes: > I selected german as language at the start. > The network console ignores that and continues in english. Network console also ignores frontend selection (DEBIAN_FRONTEND=text). I wonder if it's by design... -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878w573z5x@tac.ki.iif.hu
Bug#587150: #587150: d-i netinst cd doesn't boot, isolinux error: further investigation
This particular bug is fixed in Syslinux 4.00 final, which is already in unstable. Other two very similar bugs were only fixed in 4.01-pre1, which isn't packaged yet. -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874ogikyu9@tac.ki.iif.hu
Re: Multi-arch netinst getting too big
Ian Campbell writes: > On Sat, 2010-06-26 at 21:49 +0200, Ferenc Wagner wrote: > >> Ian Campbell writes: >> >>> On Sat, 2010-06-26 at 21:12 +0200, Ferenc Wagner wrote: >>> >>>> Ian Campbell writes: >>>> >>>>> Another option might be to combine gtk/initrd.gz and xen/initrd.gz so >>>>> that the overhead is only the kernel udebs and not duplicating all the >>>>> other stuff. >>>> >>>> I probably mentioned this already, but you aren't constrained to a >>>> single initrd.gz: you can use several ones separated by commas. >>> >>> Where can I use several? In a Xen domain config file or in some >>> bootloader config or something? Is it actually supported of does it just >>> happen to work by some coincidence? >> >> Unfortunately not in a Xen domain config, AFAIK. But isolinux supports >> it, as per syslinux.txt: >> >> It supports multiple filenames separated by commas. >> This is mostly useful for initramfs, which can be composed of >> multiple separate cpio or cpio.gz archives. > > OK, Thanks. > >> It's actually an overlay, so it may be possible to work around the Xen >> limitation by making the Xen initrd the base one and overwriting its >> arch dependent parts as needed. > > Although it probably could be made to work I'm not that keen on making > the regular case more complicated/strange (even if supported by the > bootloader) in order to support Xen and I suspect nobody else is either. > I'd prefer to drop GTK from the Xen images. By all means go ahead. The multi-initrd feature would be most useful for reusing the normal initrds (mostly kernel modules) in the graphical installer I guess. But then again that may not be worth it. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4pjh8wv@tac.ki.iif.hu
Bug#587150: [syslinux] Bug#587150: #587150: d-i netinst cd doesn't boot, isolinux error: further investigation
"Helmut Hullen" writes: > The simpliest way for me might be some download addresses for several > *.iso images which I can test. > > Thinkpad T22, T23, T40 The image which fails to boot on the submitter's T23 is http://cdimage.debian.org/cdimage/daily-builds/unstable/20100626-3/i386/iso-cd/debian-testing-i386-netinst.iso having the following md5sum: 7f9b92a8f41da4ef60054aacb83845a6 debian-testing-i386-netinst.iso It will hopefully stay available for some more days. > I've just tried compiling syslinux-4.00-pre63 for slackware using the > Build script from 3.84: it finished with the error message I see this is solved already. > Am I right that I don't need to compile syslinux-4.00? The package seems > to contain all the files a compiling run would make too. You are right. -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ocevh9aa@tac.ki.iif.hu
Bug#587150: [syslinux] Bug#587150: #587150: d-i netinst cd doesn't boot, isolinux error: further investigation
"Helmut Hullen" writes: > Du meintest am 27.06.10: > >>> It would obviously be useful to know which exact image this was, so >>> that I have a hope of knowing if I can reproduce the bug. > >> Uhh, I see, this is somewhat difficult. >> Today, i downloaded an iso, and it booted fine. But that is Isolinux >> ver. 3.86 (according to that, what I see at the top of the screen >> during boot). Yesterday I had 4.00. > > Which *.iso did you use? No stable link has been posted yet, but Holger and hpa both have the problematic image. > I can test it on my two T23. That would be very useful indeed. Do they boot any isolinux 4.00 CDs? > By the way: I can't find your initial posting - does it contain other > hints? > > Or had I to investigate "bugs.debian.org"? This is a Debian bug report, which I forwarded here in the hope of some help, cf. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587150 Please keep 587...@bugs.debian.org and Holger Wansing on Cc, they don't subscribe to the syslinux list. -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874ogocjhg@tac.ki.iif.hu
Bug#587150: #587150: d-i netinst cd doesn't boot, isolinux error: further investigation
Holger Wansing writes: > I found, that this not only a problem of the netinst cd, but > also hardware dependent. > I can boot my old 486 Toshiba Satellite laptop with this cd, > but on my IBM Thinkpad T23 the cd produces the isolinux error: > > Error: no configuration file found. > > (The T23 does not contain the original optical drive, I changed the drive > myself years ago to an NEC ND-7551A. I had no problems in the past years > with this drive). > > I checked the md5sum of the downloaded iso, it was correct. > I burned the iso to three different discs (from different vendors), > all showed the same problem. So this should not be a problem of a > bad disc. > I have a netinst iso lying around here from 13.06.2010, it boots > fine on my T23. It contains Isolinux 3.86 > > Is there some regression brought in by the Isolinux 4.0 version? That's possible, 4.0 isn't released just yet. I'm Cc-ing the Syslinux developer list to make them aware of this issue. I guess the CD image you tested had isolinux 4.00pre58 or pre59 on it; now pre60 was also uploaded to unstable, so newer dailies will switch to that at least. Fixes are continuously getting into these prereleases, so it would be very useful if you could test the newest possible in your T23 and report back success or failure. Stable links to tested images under http://cdimage.debian.org/cdimage/daily-builds/daily.old/ may also prove useful. -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4pld0ao@tac.ki.iif.hu
Re: Multi-arch netinst getting too big
Ian Campbell writes: > On Sat, 2010-06-26 at 21:12 +0200, Ferenc Wagner wrote: > >> Ian Campbell writes: >> >>> Another option might be to combine gtk/initrd.gz and xen/initrd.gz so >>> that the overhead is only the kernel udebs and not duplicating all the >>> other stuff. >> >> I probably mentioned this already, but you aren't constrained to a >> single initrd.gz: you can use several ones separated by commas. > > Where can I use several? In a Xen domain config file or in some > bootloader config or something? Is it actually supported of does it just > happen to work by some coincidence? Unfortunately not in a Xen domain config, AFAIK. But isolinux supports it, as per syslinux.txt: It supports multiple filenames separated by commas. This is mostly useful for initramfs, which can be composed of multiple separate cpio or cpio.gz archives. It's actually an overlay, so it may be possible to work around the Xen limitation by making the Xen initrd the base one and overwriting its arch dependent parts as needed. Hopefully this can be done without wasting much memory, maybe by adding empty files/directories to the overlay initrd. But I don't know a thing about the powerpc bootloader. If that does not support this, the possible gains are somewhat lower. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ocexd15l@tac.ki.iif.hu
Re: Multi-arch netinst getting too big
Ian Campbell writes: > Another option might be to combine gtk/initrd.gz and xen/initrd.gz so > that the overhead is only the kernel udebs and not duplicating all the > other stuff. I probably mentioned this already, but you aren't constrained to a single initrd.gz: you can use several ones separated by commas. On the other hand I've got no idea how much of the initrd contents is arch independent. And I surely wouldn't miss the graphical part of the Xen installer. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vd95d2vi@tac.ki.iif.hu
Bug#509662: graphical splash screen not iLO compatible
Frans Pop writes: > On Friday 26 December 2008, Daniel Pocock wrote: > When someone is accessing a server remotely using a HP iLO, they may not have the iLO licensed for graphical modes (extra license fees have to be paid to HP) Alternatively, someone may be using a serial port for remote access (e.g. through a Cisco 2511 with multiple async ports) >>> >>> This issue is covered in the Installation Guide >>> http://www.debian.org/releases/lenny/i386/ch05s01.html.en#boot-screen >> >> Thanks for pointing that out - the page correctly describes the issues. >> However, the instructions given there don't work for an iLO - blindly >> pressing keystrokes doesn't seem to work. > > Strange. It was tested by someone with access to iLO boxes. > Dann: could you retest this please? This is the same with Dell Remote Access Cards: at least some versions only support text mode, and what is worse, they don't even forward keystrokes while "waiting for video text mode". So up to the ISOLinux banner everything is fine, then you get a blank screen and no interaction at all. This is indeed very easy to work around when using netboot, but extremely annoying when booting from CD. And the solution is only and ESC away... One possible solution I can think of is having a couple of seconds timeout before loading vesamenu.c32, which an alert user could use to load menu.c32 instead, like this: $ cd debian-installer/i386/boot-screens $ mv syslinux.cfg graphical.cfg $ cat >syslinux.cfg prompt 1 timeout 30 default graphical say --- say Enter 'text' or wait 3 seconds for a graphical menu label graphical config debian-installer/i386/boot-screens/graphical.cfg label text config debian-installer/i386/boot-screens/text.cfg $ sed s/vesa// graphical.cfg >text.cfg The exithelp.cfg is pretty much mistaken (kernel and config exclude each other), but that's a minor point. I lightly tested the above with git syslinux components put into the netboot image of the Alpha1 Squeeze installer, and liked the result. What do you think? -- Cheers, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hbl11ri5@tac.ki.iif.hu
Re: lilo removal in squeeze (or, "please test grub2")
Samuel Thibault writes: > Paul Vojta, le Thu 27 May 2010 00:47:14 +, a écrit : >> In article , >> Ferenc Wagner wrote: >> >>> Sorry, I don't trust in the future of LILO myself. If there's anything >>> which only LILO can do, I recommend you start complaining on the >>> Syslinux and the Grub mailing lists. I suppose it will be heard. >> >> Does either grub2 or syslinux allow for single-key booting? > > It is available in the experimental branch of grub2. To quote upstream: hpa: It's trivial to add support for it (just another MENU directive) So if you really need it, it'll be in the next version. And I assume that's why you asked, right? :) -- Cheers, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vda9tnrx@tac.ki.iif.hu
Re: lilo removal in squeeze (or, "please test grub2")
Stephen Powell writes: > Ferenc Wagner wrote: > >> Stephen Powell writes: >>> >>> Both grub-legacy and grub-pc use sectors on the hard disk outside of >>> the master boot record and outside of a partition ... >> >> You may want to try extlinux, it works much like LILO in this respect. > > It does not use the master boot record. It relies on a master boot > record program to chain load it from the partition boot sector. (I > use the mbr package for that.) The extlinux package itself also contains an mbr.bin, which you can use (it's strong point is probably EBIOS support). > Speaking of documentation, that seems to be its main weakness. > Documentation is sketchy and spread out over a number of different files. /usr/share/doc/extlinux.txt.gz references syslinux.txt, which is fairly comprehensive according to my standards, at least as far as the core is concerned. What did you miss? Some modules may be less well documented. > It installs hook scripts that I don't want (and that have bugs). I hope we can fix them soon (they are Debian specific additions). -- Cheers, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874ohwt3td@tac.ki.iif.hu
Re: lilo removal in squeeze (or, "please test grub2")
Daniel Baumann writes: > On 05/24/2010 11:29 AM, Ferenc Wagner wrote: > >> You may want to try extlinux, it works much like LILO in this respect. >> It lacks a convenient configuration system, but that of grub-legacy >> would be easy to adapt, and I actually plan to work on this. > > sometime ago i've added extliux-install and update-extlinux. if fits my > setups well, however, any other/better ideas how to improve it are very > welcome, see #573042 for more information. Heh, yes, that's me again. :) I got distracted, but didn't give up work on this. Now I'm nosing around the current Grub2 method for ideas. Meanwhile, the unconditional destroying of extlinux.conf on update gave me the grief again. :-/ -- Cheers, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3wlyt1a@tac.ki.iif.hu
Re: lilo removal in squeeze (or, "please test grub2")
Stephen Powell writes: > On Mon, 24 May 2010 13:38:55 -0400 (EDT), Ferenc Wagner wrote: >> Stephen Powell writes: >>> On Mon, 24 May 2010 05:29:56 -0400 (EDT), Ferenc Wagner wrote: >>>> Stephen Powell writes: >>>>> Both grub-legacy and grub-pc use sectors on the hard disk outside of >>>>> the master boot record [...] >>>> >>>> You may want to try extlinux, it works much like LILO in this respect. >>> >>> Thanks for the tip. That may be an option. I looked at the documentation >>> online, and there does not appear to be an option equivalent to lilo's >>> vga option, though, which I use a lot, especially since svgatextmode >>> has already been pulled from squeeze. >> >> I'm not sure what you're after, I haven't used LILO for ages. But >> typing vmlinuz-2.6.32 vga=0xf07 at the pxelinux boot prompt gives me a >> 80x60 console. The other variants use the same code. > > Interesting. At one point, the kernel itself had de-supported the > vga boot option, relying on the boot loader to set the video mode > before transferring control to the kernel. And now you're saying > it's back. Hmm. According to Documentation/svga.txt in the kernel > source tree: > >This small document describes the "Video Mode Selection" feature which >allows the use of various special video modes supported by the video BIOS. >Due to usage of the BIOS, the selection is limited to boot time (before >the kernel decompression starts) and works only on 80X86 machines. > > Note the wording "before the kernel decompression starts". That to me > implies "done by the bootloader", because the bootloader decompresses > the kernel (if it is compressed) before transferring control to it, > does it not? It does not, the kernel is sort of a self-decompressing binary. However, the vga= parameter is indeed parsed by the bootloader and passed to the kernel by a special protocol. It's then used before the kernel parses its command line. > I'm going to have to try installing Squeeze using extlinux as the boot > loader. (No doubt I'll have to change bootloaders after installation, > as the Debian Installer won't offer that option.) Yes, you'll have to back out of Grub installation, start a shell, chroot into /target, and install exlinux. Take care to have /boot on an ext2 partition. -- Good luck! Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iq6dytpl@tac.ki.iif.hu
Re: lilo removal in squeeze (or, "please test grub2")
Stephen Powell writes: > On Mon, 24 May 2010 05:29:56 -0400 (EDT), Ferenc Wagner wrote: > >> Stephen Powell writes: >>> >>> Both grub-legacy and grub-pc use sectors on the hard disk outside of >>> the master boot record [...] >> >> You may want to try extlinux, it works much like LILO in this respect. > > Thanks for the tip. That may be an option. I looked at the documentation > online, and there does not appear to be an option equivalent to lilo's > vga option, though, which I use a lot, especially since svgatextmode > has already been pulled from squeeze. I'm not sure what you're after, I haven't used LILO for ages. But typing vmlinuz-2.6.32 vga=0xf07 at the pxelinux boot prompt gives me a 80x60 console. The other variants use the same code. >> It lacks a convenient configuration system, but that of grub-legacy >> would be easy to adapt, and I actually plan to work on this. > > if you have the requisite skills to become the equivalent of lilo > upstream, I think there's a lot of people who would rather that you do > that, myself included. Sorry, I don't trust in the future of LILO myself. If there's anything which only LILO can do, I recommend you start complaining on the Syslinux and the Grub mailing lists. I suppose it will be heard. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87typxyzbk@tac.ki.iif.hu
Re: lilo removal in squeeze (or, "please test grub2")
Stephen Powell writes: > On Mon, 24 May 2010 05:36:32 -0400 (EDT), Ferenc Wagner wrote: >> Kurt Roeckx wrote: >>> On Sun, May 23, 2010 at 01:11:48PM +0200, Cyril Brulebois wrote: >>>> William Pitcock (22/05/2010): >>>>> This means that users should *test grub2 extensively* before Squeeze >>>>> is released so that any issues can be resolved now. >>>> >>>> There should also be some folks fixing the discovered issues. >>> >>> grub2 currently seems to be having 18 RC bugs, plus a whole bunch >>> of merged bugs, while lilo only has 1 RC bug. >> >> I chatted about this with the grub upstream a couple of days ago. >> According to Vladimir, most of those bugs are already fixed, but there's >> nobody around to do a new upload. Both grub maintainers (Felix Zielke >> and Robert Millan) unexpectedly disappeared some time ago. > > What about Jordi Mallach and Colin Watson? I really don't know, I just echoed what I heard on the #grub IRC channel. I saw articles from Colin Watson recently, so he's around, but I don't know how he feels about Grub maintenance. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y6f9z0il@tac.ki.iif.hu
Re: lilo removal in squeeze (or, "please test grub2")
Stephen Powell writes: > Both grub-legacy and grub-pc use sectors on the hard disk outside of > the master boot record [...] This breaks the design of the backup > software that my employer uses. This backup software backs up the > master boot record and all partitions; but since the extra sectors > used by grub-legacy and grub-pc are outside the master boot record and > are not part of any partition, they don't get backed up. > Consequently, if we have a hard drive failure and restore from a > backup, we have an unbootable machine. Lilo uses only the master boot > record. A lilo-booted machine can be backed up and restored with our > existing backup software just fine. You may want to try extlinux, it works much like LILO in this respect. It lacks a convenient configuration system, but that of grub-legacy would be easy to adapt, and I actually plan to work on this. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3wl1wbv@tac.ki.iif.hu
Re: lilo removal in squeeze (or, "please test grub2")
Kurt Roeckx writes: > On Sun, May 23, 2010 at 01:11:48PM +0200, Cyril Brulebois wrote: >> William Pitcock (22/05/2010): >>> This means that users should *test grub2 extensively* before Squeeze >>> is released so that any issues can be resolved now. >> >> There should also be some folks fixing the discovered issues. > > grub2 currently seems to be having 18 RC bugs, plus a whole bunch > of merged bugs, while lilo only has 1 RC bug. I chatted about this with the grub upstream a couple of days ago. According to Vladimir, most of those bugs are already fixed, but there's nobody around to do a new upload. Both grub maintainers (Felix Zielke and Robert Millan) unexpectedly disappeared some time ago. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878w791w0v@tac.ki.iif.hu
Re: Debian installer with RAID of 6TB
Chris Moules writes: > It seems to me that, maybe, libparted, partman or something related in > the d-i does not work with more than 4TB. All 6TB are shown but cannot > be used. As nothing seems to have a 4TB limit I am not sure what it > could be. A year ago there was a limit in parted, at least on 32 bit, see the final notes in #510544. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lje99jgb@tac.ki.iif.hu
Re: Switching g-i from DirectFB to X11 -- image size; library reduction
Frans Pop writes: > On Wednesday 24 February 2010, Ferenc Wagner wrote: > >> While I'm in Syslinux mood: version 3.85 has a full-featured gPXELinux >> component, boasting HTTP support (among others). Image loading over >> HTTP is *much* faster than over TFTP. On the other hand, it requires an >> additional HTTP server, and thus probably not worth the hassle for >> single shot installations. It could be useful for testing, though. > > Would any changes be needed in D-I images to use that? I can see it as an > option, but not as a default. Only in the netboot infrastructure: you have to configure your DHCP server to pass gpxelinux.0 as boot file name instead of pxelinux.0, and further that requires URLs for the kernel and initrd location. Once those are loaded into memory, everything is all the same. > IMO it's mostly useful if we were to offer to install Debian directly from > the Internet, and IIUC that's what it was developed for. Yes, why not. We could even ask the boot.kernel.org people to include D-I images in their bootable set. Debian Live is already there... -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zl2wrsd7@tac.ki.iif.hu
Bug#571136: please remove useless devices from devices.tar.gz
Marco d'Itri writes: > FYI, the only devices needed by udev to start are null and console. Aren't those created by devtmpfs? Or will Debian not use that? -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/873a0qgbn2@tac.ki.iif.hu
Re: Switching g-i from DirectFB to X11 -- image size; library reduction
Frans Pop writes: > Why image size is important > [...] > 2) makes loading the image for netboot installs slower While I'm in Syslinux mood: version 3.85 has a full-featured gPXELinux component, boasting HTTP support (among others). Image loading over HTTP is *much* faster than over TFTP. On the other hand, it requires an additional HTTP server, and thus probably not worth the hassle for single shot installations. It could be useful for testing, though. -- Cheers, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877hq3eyla@tac.ki.iif.hu
Bug#570273: debian-installer: netboot stops after loading pxelinux.cfg/default
"Mario 'BitKoenig' Holbe" writes: > On Thu, Feb 18, 2010 at 01:18:01AM +0100, Frans Pop wrote: >> Problem is: it works perfectly here for me using the daily image you linked >> to on two systems: in VirtualBox and my (oldish) Toshiba laptop. > > All right, I think I got it... syslinux/pxelinux.txt states, that: > > PXELINUX currently requires that the boot server has a TFTP server > which supports the "tsize" TFTP option (RFC 1784/RFC 2349). But if you look in the NEWS file of Syslinux, which is packaged as /usr/share/doc/syslinux/changelog.gz (why?) you'll find: Changes in 3.70: [...] * PXELINUX: We no longer require a TFTP server which supports the tsize option for all transfers. which sounds ambiguous, but if you also consider http://git.zytor.com/?p=syslinux/syslinux.git;a=commitdiff;h=86e68b689ce2dd228278ef08510c6532f429501f it becomes clear that this issue shouldn't affect the Lenny version. If it does, that definitely is a Syslinux bug. > However, although tftpd-hpa generally works, it is horribly slow in > inetd as well as in standalone mode, i.e. it takes ages until some > menu is displayed (having a look at the network traffic going on in > the meantime shows why :/). I never had such a problem with tftpd-hpa. Could you please elaborate? -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87eikbf015@tac.ki.iif.hu
Bug#433568: VLANs during install are important
Robert LeBlanc writes: > I too have been bitten by this. For as flexible as the Debian Installer is > and everything you can do, it's pretty disappointing that it can't do VLANs. > A lot of enterprises use VLANs, and it seems it would be important to have > VLAN support to install Debian. It's no fun to reconfigure the network just > to install/reinstall. I hacked VLAN support into the Sarge installer once upon a time. It wasn't a big deal, like adding the vconfig binary and extending netcfg here and there a little bit. The problem is that you can't just download it like the other optional components, so it would waste memory in the vast majority of installations. Which wouldn't be a problem but in the more memory constrained situations... I can't judge this. It would be less of a problem if d-i used the Busybox ip applet *and* if that supported VLANs. Until then, I'd work around this by adding the vconfig binary to the installer medium or loading it as "additional firmware". :) -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
