#ubuntu-boot 2006-01-16
<makx> hmm initramfs-tools doesn't like separate lvm /boot when root is not on lvm
<makx> probably needs to check mount for separate /boot and check if that one is on lvm
* ..[topic/#ubuntu-boot:Keybuk] : known: few network pluggings (ask infinity), alsa rules not reloaded
<fabbione> Keybuk: fix initscripts. kthxbye!
<fabbione> Keybuk:
<fabbione> 0 lrwxrwxrwx   1 root root   24 2005-09-17 14:21 S18ifupdown-clean -> ../init.d/ifupdown-clean
<fabbione> 0 lrwxrwxrwx   1 root root   22 2006-01-10 07:22 S20checkroot.sh -> ../init.d/checkroot.sh
<fabbione> spot the error
<Keybuk> fabbione: ifupdown is known broken
<Keybuk> that init script is going away anyway
<fabbione> Keybuk: yes but please do it soon
<Keybuk> ifupdown has been broken for nearly 2 months ;)
<fabbione> as it is now if there is a bad crash
<fabbione> ifstate is not removed
<fabbione> and network doesn't come up
<Keybuk> right
<Keybuk> network doesn't come up anyway
<fabbione> i don't think it was for that long
<Keybuk> unless you've changed your configuration from the defaults
<fabbione> if you remove ifstate yes
<Keybuk> no, in general ;)
<fabbione> i use default dhcp
<Keybuk> do you have "auto" in your interfaces file?
<Nafallo> I'm starting to think network-manager only works for me :-P
<Keybuk> Nafallo: don't login to gdm
<Keybuk> then try and use the network from the console
<Keybuk> <g>
<Nafallo> baah
#ubuntu-boot 2006-01-17
<Keybuk> Mithrandir: yo
<Mithrandir> dude!
<Keybuk> right, so yes
<Keybuk> readahead
<Mithrandir> so, what's your plans for readahead?
<Keybuk> mdz gave me this to overhaul as part of streamlined-boot
<Keybuk> so my general problems with it were
<Mithrandir> (and what does  mean?)
<Keybuk> 1) wayyy out of date lists
<Keybuk> 2) insufficient runs
<Keybuk> 3) doesn't block-order its lists at the right time
<Keybuk> (shutdown is not a point to do important things)
<Keybuk> etc.
<Keybuk> so my basic design for it was
<Keybuk> - each package that includes an init.d script includes a file in /var/lib/readahead or similar listing the files it reads from
<Keybuk> - readahead includes an audit tool that you can drop into a script to generate these files (using strace-parent, maps, etc. magic)
<Keybuk> - each package also runs update-readahead in postinst
<Keybuk> - that looks at rcS.d/rc2.d, picks the files from /var/lib/readahead, joins them together, and orders by block number
<Mithrandir> I was thinking just having something in initramfs which uses inotify to record everything which is opened.  List is saved at the end of the boot (or after five minutes) and reused next time.
<Keybuk> inotify can't record when files are opened, and how they're opened?
<Keybuk> and can only monitor one filesystem at a time
<Mithrandir> #define IN_OPEN			0x00000020	/* File was opened */
<Mithrandir> huh?  You can monitor as many file systems as you want?
<Keybuk> Mithrandir: doesn't say whether it's for reading, writing, etc.
<Keybuk> Mithrandir: yes, but then you need to monitor each filesystem as it's mounted
<Keybuk> and there's no "filesystem mounted" event
<Mithrandir> true, but that's possible to work around.
<Mithrandir> the readahead might need to do multiple passes anyway.
<Keybuk> yeah, I want to do a "very early" readahead pass
<Keybuk> one after /usr is probably mounted
<Keybuk> and maybe a final "gdm is up, now what?" push
<Keybuk> and it's harder to split results of a single monitor if you do that
<Keybuk> also on LiveCD where would you save the lists? :p
<Keybuk> and where would you get the initial list?
<Mithrandir> boot initially, upload it somewhere and we'd use a sample to decide what to put into the list.
<Keybuk> but they won't be in anything like the right order for a real install
<Mithrandir> not really, if you have a list of files to be readahead, do readahead on the ones which exist, then wait for some more to come into existence, then readahead those, repeat until all files have been read.
<Kamion> I think I prefer Keybuk's approach - less likely to drift over time
<Keybuk> which means the first boot (only boot for reviewers) is evily slow
<Kamion> stuff that requires us to kick it every so often has a history of bitrotting (e.g., er, readahead)
<Mithrandir> you'll end up readahead-ing the entirely wrong files in a lot of cases, though.  Like, if you change your language, the localised files should be read ahead, not the english ones.
<Kamion> for init scripts?
<Mithrandir> huh?
<Kamion> they aren't localised at the moment
<Kamion> and what remains sounds like a relatively small number of files
<Kamion> if need be, just readahead all the alternatives?
<Mithrandir> well, I was going to reuse my hack for faster gnome startup.
<Mithrandir> so you just say "record" at the start of the session, then "stop, give me the list of files" at the end
<Mithrandir> and then use that list next time aroud.
<Mithrandir> around, even
<Keybuk> that's what we did to get the current useless lists though
<Keybuk> they need more filtering than inotify provides
<Keybuk> readinf /var/log/Xorg.0.log is kinda pointless, for example
<Keybuk> as with things like the font caches, etc.
<Mithrandir> you can see if the file was opened rw or not on close, though..
<Keybuk> it's also a bitch to find out _what_ opened it ;)
<Mithrandir> why do we care, really?
<Mithrandir> about who opened something
<Keybuk> if we have multiple readahead phases
<Mithrandir> well, I would advocate not having that
<Keybuk> why not?
<Keybuk> during the boot, we have three useful points where there's no disk I/P
<Keybuk> uh, I/O
<Keybuk> those seem the best bits to do readahead blips
<Mithrandir> if we do readahead right, we should end up with about zero I/O outside readahead anyway, shouldn't we?
<Keybuk> not necessarily
<Keybuk> e.g. fsck ;)
<Mithrandir> true, but that's a no-op in the usual case today.
<Mithrandir> (in the usual case that you don't run a full fsck, which you usually don't)
<Keybuk> depends on the fs
<Keybuk> ext3 seems to use a lot of io to check its journal, for example
<Mithrandir> isn't readahead prioritised below other I/O ops anyway?  If not, can we make it?
<Keybuk> I still don't like your solution though ;)
<Keybuk> it doesn't do anything for LiveCD
<Keybuk> because by its very definition, you have nowhere to write the updated lists
<Keybuk> and I think it'll actually slow up the ordinary system boot by reading files that aren't necessary
<Mithrandir> because it'll readahead Xorg.log?
<Keybuk> because it'll readahead things at the wrong times
<Keybuk> you can very easily over-readahead
<Keybuk> so it takes longer to do that, then it would to read them normally
<Mithrandir> I just think maintaining those lists by hand is going to suck and be based on a bunch of guesses more than anything else.
<Keybuk> ie. if the time to do the readahead is greater than the benefit of doing so, then you lose
<Keybuk> thom and I find when first doing it that you had to write them by hand
<Keybuk> because the automatic ones didn't give you much benefit
<Keybuk> they just shifted the I/O about
<Mithrandir> well, it really is about shifting the I/O about. :-)  You'll always end up reading at least the same amount as before.
<Keybuk> another problem I can forsee with your idea is failed boots
<Keybuk> the next boot, you'll end up readaheading all the things you used to fix the last boot
<Keybuk> etc.
<Mithrandir> possibly, yes.
<Keybuk> or switching between kernels will have similar issues
<Mithrandir> it reduces the stability of the boot lenght.
<Mithrandir> length, even
<Keybuk> to me, this really does cry out to be a package-level thing ;)
<Keybuk> here's my (automatically generated and manually weeded) list of things I cause to be read in each package
<Keybuk> lang packs would include those too
<Mithrandir> Keybuk: we can try with your method, I guess.  When will you have it ready? :-)
<Keybuk> Mithrandir: been playing all afternoon so far <g>
<Keybuk> I like yours now, much easier to code than mine
<Keybuk> in fact, I have a cunning idea for a "profile" command-line option that enables both readahead profiling and boot charting
<Keybuk> so we could ship bootchart by default <g>
<Mithrandir> you do know that bootchart doesn't do anything by default now?
<Keybuk> this might explain something
<Keybuk> you know we have a mailing list?  ubuntu-devel-announce
<Keybuk> for when you change that kind of thing <g>
<Keybuk> users have been complaining at me for the last few days that bootchart stopped working, haven't got around to investigating yet
<Keybuk> you could've had a small nuke thrown at you :p
<Mithrandir> you know, it's in the bloody changelog.
<Keybuk> who reads those?! :p
<Mithrandir> I, at least.
<Mithrandir> especially if I wonder why something changes.
<Keybuk> meh, any particular reason you disabled it?
<Mithrandir> yes, it's on the live cd.
<Keybuk> why always?
<Mithrandir> because there's no way to know you're on a live cd when bootchart runs.
<Mithrandir> it's just adding a small bootchart=enable to run it.
<Keybuk> oh, of course, you can't add it to the live cd
<Keybuk> lol
<Mithrandir> or bootchart=upload to upload the graph.
<Keybuk> upload the graph where? :p
<Mithrandir> bootchart.err.no
<Mithrandir> _that_ on the other hand, should probably have gone to u-d-a. :-P
<Keybuk> heh, given the amount of stuff I'm doing with boot charting right now ....
<Keybuk> it would've been nice if you'd at least told _me_ about that :p
<Keybuk> but yes, that should go to u-d-a
<Keybuk> could you mail it? :p
<Mithrandir> I did this change a month or so ago.
<Mithrandir> sure
<Keybuk> I guess they can't be tagged distro/not-distro ?
<Keybuk> err
<Keybuk> live/real
<Mithrandir> sure
<Keybuk> otherwise it's hard to keep track
<Mithrandir> bootchart=enable,$tag
<Mithrandir> iirc
<Mithrandir> sorry, upload,$tag
<Keybuk> :)
<Keybuk> now, send that mail, bitch :D
<Mithrandir> bootchart (0.9-0ubuntu5) dapper; urgency=low
<Mithrandir>   * Add bootchart=disabled and bootchart=upload,$type arguments which will
<Mithrandir>     respectively disable bootcharting and upload charts to
<Mithrandir>     bootchart.err.no.
<Mithrandir>  -- Tollef Fog Heen <tfheen@ubuntu.com>  Mon, 19 Dec 2005 13:52:35 +0100
<Mithrandir> so, about a month ago wasn't that bad.
<Mithrandir> you haven't touched bootchart since Nov 30th. :-P
<Mithrandir> but sure, I'll send da mail
<Keybuk> I haven't updated my laptop properly since before xmas, no
<Keybuk> so hadn't picked up that new version yet
<Keybuk> is it enabled or disabled by default?
<Mithrandir> hmm
<Mithrandir> it's enabled by default
<Mithrandir> grep -q "bootchart=disable" /proc/cmdline && exit 0
<Mithrandir> so it's not my fault. :-P
<Mithrandir> doko's probably broken gcj or something
<Keybuk> you're so going in the dry dock <g>
<Mithrandir> I can't remember random changes I did a month ago
<Mithrandir> (without looking at changelogs, etc)
<Keybuk> I do, perhaps, think that holding a distro team sprint in an area with amble bodies of still water is a *bad* idea
<Mithrandir> why? :-)
<Keybuk> amble opportunity for solving grudges <g>
<Keybuk> you did *what* to initramfs?! *splash*
<Mithrandir> well, I did suggest paintball.
<Mithrandir> I'm sure there are shops in London renting out gear.
<Keybuk> that'd rock
<mc76> hi, I am trying to install breezy in a Dell Dimension 3100 and the installer hangs right after launching syslogd kdlogd. Has anyone seen this before or know how to get pass this? I already tried all the boot options in the disk and searched google for it (other people report the same issue but none report a fix) any suggestions where I can look for more info?
#ubuntu-boot 2006-01-19
<ppd> hello, I have a small question: Is there some information about fastening the boot process after dapper? (launchd and so on) or: what necessary processes in ubuntu bootup perform slower than e.g their winxp equivalents?
<ppd> and I have header about 10-15 seconds faster dapper bootup. where are these seconds from?
#ubuntu-boot 2006-01-20
<user_> greetings
#ubuntu-boot 2006-01-22
<Abecedarian> Hello.  By any chance could somebody here answer a few questions on booting and the linux kernel, particularly as it relates to having a linux kernel loads modules and executse the linuxrc?
<Mithrandir> possibly, if you ask your question
<Abecedarian> Thanks!
<Abecedarian> I'm in the process of building a boot disk that will allow be to boot a USB external Ubuntu on computers unable to boot via USB.
<Mithrandir> as in, boot off an USB enclosure or something?
<Abecedarian> Basically, from articles taht I've read (http://www-128.ibm.com/developerworks/linux/library/l-fireboot.html and http://www.neowin.net/forum/lofiversion/index.php/t269145.html) it *can* be done.
<Abecedarian> Yeah.
<Mithrandir> where are you going to get the initramfs and kernel off?  (And bootloader)
<Abecedarian> The method seems to be to have a copy of the kernel on the boot cd which will then run a linuxrc script which scans for the USB device after loading the proper drivers/modules, after which (if it detects) it will relocate root to the proper device.
<Mithrandir> you might want to look at casper
<Keybuk> aye, we've solved much of these problems in Ubuntu already
<Abecedarian> Two ways.  I have a modified script from the neowin article (via a friend) that generates a boot image.  Also, it is possible to just download their complete image and edit the contents.
<Mithrandir> Abecedarian: also, have you seen https://wiki.ubuntu.com/BootingFromUS ?
<Mithrandir> uhm
<Mithrandir> https://wiki.ubuntu.com/BootingFromUSB
<Abecedarian> No, I hadn't had a chance to look over https://wiki.ubuntu.com/BootingFromUS ...  But from a glance I'd have to say that I'm uncertain it would apply to computers that lack a BIOS capable of detecting or booting to USB devices.
<Abecedarian> Which is a major issue for "Portable Ubuntu" on an external.
<robotgeek> it would be nice to grab a bootable cd and boot from it.
<Abecedarian> That and the article seems a bit...  short.  Or vague.  No offense to whomever wrote it, but it still looks like they're working on it.
<Abecedarian> Working on a similar project, I mean.
<robotgeek> Abecedarian: it seems more like comments on a spec, the BootingFromUSB page
<Keybuk> Abecedarian: *shrug* that kind of thing is easy, especially in dapper
<Keybuk> you stick the kernel and initramfs on something the bios can boot
<Keybuk> and then the rest of the system on a USB devic
<Mithrandir> it's a spec, it's not an article.
<Abecedarian> Exactly!
<Abecedarian> And, as I understand from the articles, it must execute something called "linuxrc" in "initrd".  At least, that is one method.
<Abecedarian> I've found bootable images and toyed with modifying them a bit, but it always runs into a kernel panic somewhere down the road.
<Abecedarian> I think when it tries to relocate root since it does manage to boot and does manage to load thekernel.
<Abecedarian> And since I have template images, a copy of my kernel, and a possibly superior template linuxrc script, I was hoping you might be able to enlighten me on how the initrd and linuxrc scrip on the boot disk "work".
<robotgeek> Keybuk: i have a dapper flight cd 3. i'll play around with it
<Keybuk> that stuff's out of date now
<Keybuk> we don't use either initrd or linuxrc
<Keybuk> robotgeek: use root=/dev/disk/by-label/VOLLABEL and it _should_ just work
<robotgeek> Keybuk: do i put grub on the external hdd?
<Mithrandir> it might even work to boot off a live cd with approximately that command
<Keybuk> robotgeek: if grub is on the external HDD, your bios would need to be able to boot from that HDD
<Keybuk> if the bios can, the installer will just let you do it
<Keybuk> if the bios can't, the installer won't
<Kamion> Abecedarian: the initramfs on the boot disk is a gzipped cpio archive; the kernel unpacks it and executes /init in early userspace; that program is then responsible for finding and mounting the real root device (and other stuff) and chaining to /sbin/init there
<robotgeek> Keybuk: my macs do allow that, my pc doesn't
<Kamion> robotgeek: Fabio only fixed grub-installer to allow that recently (post-Breezy)
<robotgeek> Kamion: i tht i put grub on the external boot disk with a shipit
<Kamion> it certainly didn't do it automatically ...
<Kamion> well, not unless you have a "special" BIOS, which isn't out of the question :)
<Keybuk> "spethial"
<robotgeek> Kamion: i booted from the install cd , it detected my external usb hdd, and asked me if i was sure if i wanted to install it there
<Kamion> lucky, then :)
<robotgeek> any good resources on where to read up on the process we follow for booting?
<Keybuk> LWN have done some good articles on it
<robotgeek> don't want to ask you stupid questions and waste your time :)
<Keybuk> also our Wiki contains many of the specs we've followed
<Keybuk> in particular, read EarlyUserspace, UdevRoadmap, HardwareDetection, ProbeForRootFilesystem, BootFromUSB, etc.
<robotgeek> okay, i'll check CatergorySpec then
<Keybuk> also the source code can often help :)
<Keybuk> fortunately much of it is written in plain old shell
<robotgeek> i'm okay with bash scripting, so i guess i won't have much of an issue
<Abecedarian> I'm a bit of a n00b...  But I'm a little confused.  If the goal is to boot *to* usb rather than *from* it, what is the relationship between the two reverse methods?
<Keybuk> you never boot to something
<Keybuk> so the phrase doesn't make sense :)
<Keybuk> you boot from something
<Keybuk> how much of the boot process you can do from that item is up to your computer's bios, usually
<Abecedarian> *lol*  Okay, well, run it from usb but boot it from cd.
<Keybuk> with BootFromUSB, our goal is that you can insert the key and supporting BIOS will boot directly from it
<robotgeek> we were more interested in making a bootable cd which along with our external hdd, we could take our ubuntu where ever we go
<Keybuk> with non-supporting BIOS you need a boot-strapping tool, like a LiveCD, floppy "boot" disk, or internal HDD -- which contains the kernel and initramfs
<robotgeek> Keybuk: do they have to match the version installed?
<Keybuk> robotgeek: they should, yes
<Abecedarian> Our goal is a bit of a helper for yours...  To make it work even on computers without the BIOS supporting USB booting.
<Keybuk> Abecedarian: we intend to support this out of the box
<Keybuk> it should work now
<robotgeek> well, that's a relief :)
<Keybuk> install Flight 3 onto your USB key, and boot it by inserting the Flight 3 Live-CD and changing the root= line to be root=/dev/disk/by-label/VOLNAME where VOLNAME is the name of your USB key
<robotgeek> so, once i get upgrades to flight 3, what happens?
<robotgeek> the kernel on dapper flight 3 wont match the one on the cd?
<Keybuk> righ
<Keybuk> your kernel needs to match the userland you're booting
<Keybuk> because the drivers are on the USB key :)
<robotgeek> true
<Abecedarian> But a dapper flight 3 live cd would work fine, we'd just have to disable updates until a newer livecd comes out?
<robotgeek> maybe we can make a small boot cd everytime we upgrade the kernel
<Keybuk> LiveCDs always come out at the same time as Installer CDs
<Keybuk> yes, you could also place the kernel, initramfs and bootloader on a custom CD of your own
<Keybuk> or, if your computers support PXE, these could be on the network
<robotgeek> nice...gotta try the flight cd's then
<Abecedarian> So we could just take a live cd, "hollow out" most of it, and then tell it to automatically boot to the external saving us having to type it in each time.  And update the kernel to non-flight versions if we do update the dapper kernel on the external?
<robotgeek> looks like someone was pissed when they wrote this. https://wiki.ubuntu.com/UdevRoadmap
<Mithrandir> flight 3 live doesn't support booting off ieee1394, current dailies should
<Mithrandir> (once they're buildable)
<Keybuk> robotgeek: I don't recall being drunk ... why?
<robotgeek> hotplug: Ask the ftpmasters to eject it from the archive like the bitch it is.
<Keybuk> Mithrandir: really, what did we miss to not support that?
<Keybuk> robotgeek: heh, that's just my writing style
<Mithrandir> Keybuk: sbp2 and ohci1394
<Keybuk> Mithrandir: ah, not in the initramfs?
<Mithrandir> corrcet
<Mithrandir> correct, even
<Keybuk> udev loads them if they are, though?
<Mithrandir> yes,
<Mithrandir> so if we could actually get -desktop installable, I could get a test image out so I could ask people to test it
<Keybuk> woo, I rock :)
<Keybuk> why does desktop need to be installable to make Live CDs now?  I never did know why that is
<Kamion> Keybuk: live fs build script fails otherwise
<Kamion> since it's doing apt-get install ubuntu-desktop or similar
<robotgeek> okay guys, thanks for your time. i'll put on dapper cd , and bug you guys later.
<Abecedarian> One other question...  I've been reading that there are efforts to make Ubuntu installed on externals more "adaptable" - ie, like a live cd.  Do you have any recommended documentation on (a) what ways a livecd's adaptability differs from a regular install and (b) developments on fixing it?
<Mithrandir> I'm not sure what you mean.
<Abecedarian> As in a livecd goes out of its way to scan for devices (screen, etc) and reconfigure the gui and other things to work on that computer...
<Abecedarian> While a regular install on an external may sometimes get comfortable on whatever computer it normally is used with and as a result might run into issues when booted on multiple computers.
<Abecedarian> A regular install might flat-out not have any problems constantly being moved around, but without having a working external install yet I should definitely read up as much as possible in case it is an issue.
<Mithrandir> you can do most of that by using a livecd and persistent storage, I'd guess.
<Mithrandir> I've also pondered changing the live cd so it'll allow easy installs and -boots on fat32 and ntfs drives.
<Abecedarian> But using persistent storage is a bit different than using the livecd to boot with root being located on the external, correct?
<Mithrandir> yes.
<Abecedarian> So is the difference significant enough to limit portability of a install, and which documentation should I read up on for figuring out how to resolve it?
<Mithrandir> the problem with doing automatic reconfiguration at each boot is mostly related to stability of configuration.
<Abecedarian> Okay...  is there any documentation you would recommend reading to learn more about increasing stability and reconfiguring?
<Mithrandir> none which springs to my mind immediately, at least
<Mithrandir> it's basically that if you have a working configuration, you don't want to change it, since you might end up ruining hand-tweaked configs or even generated configs.
#ubuntu-boot 2007-01-17
* Starting logfile irclogs/ubuntu-boot.log
<pcollaog> hi
<pcollaog> i need a little help with feisty... doesn't start
#ubuntu-boot 2010-01-19
<spy6> what a wonderfull channel!
#ubuntu-boot 2010-01-21
<andrew9> How can I boot to init 3 or single user from grub? I get a black screen after installing drivers. I cannot login to root prompt shell as I didn't change the password.
<andrew9> Add "single" into boot line
#ubuntu-boot 2010-01-23
<bikcmp> er
#ubuntu-boot 2011-01-18
<Isaac-M> Is no one in here?
<Isaac-M> Wow
<Isaac-M> Keybuk
<Isaac-M> ubuntulog: Keybuk
