Re: Debian Live CD as platform for debian-cd Jigdo download
- Thomas Schmitt wrote: [...] > It would shorten JigdoOnLive if i could point to a guide about getting > Debian Live, putting it on medium, and booting it. I would note that debian-live stable versions are also available via bittorrent, which probably has more peers available, and is easier on the mirrors. Here is a guide in general about getting/writing/using debian-live: http://debian-live.alioth.debian.org/live-manual/stable/manual/html/live-manual.en.html Sorry, it looks like the "en" variant is the only language offered.
9.13 torrents "not found" by tracker
I downloaded https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/archive/9.13.0-live+nonfree/amd64/bt-hybrid/debian-live-9.13.0-amd64-mate+nonfree.iso.torrent and fed it to the "transmission" bittorent client on Sunday, July 19. So far, it gets a "torrent not found" reply every time it asks about this torrent at http://bttracker.debian.org:6969 Today, July 22, I also downloaded https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/archive/9.13.0+nonfree/amd64/bt-cd/firmware-9.13.0-amd64-netinst.iso.torrent and fed it to the same client -- it also gets "torrent not found" every time. I don't need these urgently, so I don't mind patiently waiting, but ISTR that the image releasing magic usually works much faster. Thanks for all that you do!
Re: 9.13 torrents "not found" by tracker
On Wed, 2020-07-22 at 14:51 -0700, Lou Poppler wrote: > So far, it gets a "torrent not found" reply every time it asks about this Working now, thanks! > Thanks for all that you do!
Bug#969224: cdimage.debian.org: Error installing Debian 10.5 from flash stick with Extlinux
Please see the installation instructions: https://www.debian.org/releases/stable/installmanual It is not correct to pre-format your install media, and pre-copy other files onto it, before copying the installation .iso The correct instructions for writing a USB (or other) installation medium are in section 4.3 of that installmanual. In particular, the destination target of your dd command should be something similar to /dev/sdb_NOT_ something like /dev/sdb1 --- and don't forget to `sync` after the dd. If you still have trouble, seek help at the #debian IRC channel at oftc.net. On Sat, 2020-08-29 at 17:10 +0300, Сергей Фёдоров wrote: > Package: cdimage.debian.org > Severity: critical > Justification: breaks the whole system > > > > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.7.0-3-amd64 (SMP w/8 CPU threads) > Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Created a USB flach stick using the" gparted " MBR-partition table. > GPT-partition table failed to get a working version of the Debian > installation. > Created an Ext4-partition and its label. Set the partition "boot" attribute. > > Created a bootable flash drive: > > # dd conv=notrunc bs=440 count=1 if=/usr/lib/EXTLINUX/mbr. bin of=/dev/xxx > where xxx is the name of the u-VA, for example, sdf. > # extlinux --install "folder path" (for example " /media/u1/UP1/"), where" > UP1 " is partition name > > For Debian 10.4 copied from a folder: > > http://ftp.nl.debian.org/debian/dists/Debian10.4/main/installer-amd64/current/images/hd-media/ > or from (for GTK) > http://ftp.nl.debian.org/debian/dists/Debian10.4/main/installer-amd64/current/images/hd-media/gtk/ > > vmlinuz > initrd.gz > > and copied "debian-10.4.0-amd64-DVD-1.iso" > > or > > For Debian 10.5 copied from the folder: > > http://ftp.nl.debian.org/debian/dists/Debian10.5/main/installer-amd64/current/images/hd-media/ > or from (for GTK) > http://ftp.nl.debian.org/debian/dists/Debian10.5/main/installer-amd64/current/images/hd-media/gtk/ > > vmlinuz > initrd.gz > > and copied "debian-10.5.0-amd64-DVD-1.iso» > > In both cases, when installing Debian from a flash drive, I received the > message: > > Load installer components from an ISO installer. > > No modules were found. This pfobably is due to a mismatch between the kernel > by this version of the installer and the kernel version available in the > archieve. > > and the installation had to be stopped. > > For Debian 10.3 copied from the folder: > > http://ftp.nl.debian.org/debian/dists/Debian10.3/main/installer-amd64/current/images/hd-media/ > or from (for GTK) > http://ftp.nl.debian.org/debian/dists/Debian10.3/main/installer-amd64/current/images/hd-media/gtk/ > > vmlinuz > initrd.gz > > and copied "debian-10.3.0-amd64-DVD-1.iso" > > and everything was established without problems. > > Copy Debian 10.3, 10.4, and 10.5 to a USB stick in the device root, download > with it, the installation of Debian passes without problems. > > For example: > > dd if="./debian-10.5.0-amd64-DVD-1.iso" of=/dev/xxx bs=1M status=progress > where xxx is the name of the u-VA, for example, sdf. > > Installing Debian 10.3, 10.4, and 10.5 from a DVD does not cause these > problems. >
Bug#969224: cdimage.debian.org: Error installing Debian 10.5 from flash stick with Extlinux
Сергей: As we tried to tell you yesterday, you should be writing ONLY the .iso image onto your install USB drive. DO NOT ADD OTHER FILES like these init.rd and vmlinuz files from other places. just copy the .iso image. nothing else. On Sun, 2020-08-30 at 13:40 +0300, Сергей Фёдоров wrote: > Package: cdimage.debian.org > Severity: critical > Justification: breaks the whole system > > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.7.0-3-amd64 (SMP w/8 CPU threads) > Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > In both cases, when installing Debian from a flash drive, I received the > message: > > Load installer components from an ISO installer. > > No modules were found. This pfobably is due to a mismatch between the kernel > by this version of the installer and the kernel version available in the > archieve. > > and the installation had to be stopped. > > I think the problem is that the kernel versions for DVD and > installer-amd64/current/images/hd-media/ or > installer-amd64/current/images/hd-media/gtk/ > в initrd.gz > for Debian 10.4 and Debian 10.5 > don't match. > > for Debian 10.5 > 4.19.0-10 - the kernel versions for DVD > 4.19.0-5 - the kernel versions for > http://ftp.nl.debian.org/debian/dists/Debian10.5/main/installer-amd64/current/images/hd-media/ > or (for GTK) > http://ftp.nl.debian.org/debian/dists/Debian10.5/main/installer-amd64/current/images/hd-media/gtk/ > > Для Debian 10.4 > 4.19.0-9 - the kernel versions for с DVD > 4.19.0-5 - the kernel versions for > http://ftp.nl.debian.org/debian/dists/Debian10.4/main/installer-amd64/current/images/hd-media/ > or (for GTK) > http://ftp.nl.debian.org/debian/dists/Debian10.4/main/installer-amd64/current/images/hd-media/gtk/ > > Для Debian 10.3 > 4.19.0-8 - the kernel versions for с DVD > 4.19.0-8 - the kernel versions for > http://ftp.nl.debian.org/debian/dists/Debian10.3/main/installer-amd64/current/images/hd-media/ > or (for GTK) > http://ftp.nl.debian.org/debian/dists/Debian10.3/main/installer-amd64/current/images/hd-media/gtk/ > > For Debian 10.3 everything was established without problems. >
Bug#969224: cdimage.debian.org: Error installing Debian 10.5 from flash stick with Extlinux
On Sun, 2020-08-30 at 08:16 -0700, Lou Poppler wrote: > Сергей: > > As we tried to tell you yesterday, you should be writing ONLY the .iso image > onto your install USB drive. DO NOT ADD OTHER FILES like these init.rd and > vmlinuz files from other places. just copy the .iso image. nothing else. The complete installer and live .iso images are available from this source: > https://cdimage.debian.org/cdimage/ You do not need to mix and match additional files from this other installer hierarchy.
Re: Install Problem
Michael, Not really enough information in your report for a useful reply. I would suggest visiting the #debian IRC channel at irc.debian.org and the friendly folks there could help you get it working. On Thu, 2020-11-05 at 17:10 -0500, slow_sp...@att.net wrote: > Dear Steve, et al. > Thanks for your efforts on trying to bundle non-free with a simple net > install media. > > I tried it on an HP Pavilion G6 that had Windows 8.1. Freed up some > space and gave it a go. > > Everything seems to finish correctly, but upon restart there is no boot > to grub, no Ethernet network connection and no video. > > If I press F9 during boot, I can see the Debian option and that takes me > to grub. > > However, when selecting the first option, I see things trying to load, > and then get to a blank screen and blinking cursor. > > Upon trying it again, I choose the advanced options which will boot to a > terminal prompt, but there is no network connection available. > (connect: Network is unreachable) > > It seems that the installer should look to identify the existing > hardware and let the user confirm the choices and match up non-free > drivers that way. > > Thought you'd like to know. > > Regards, > Michael > >
Re: Release status of i386 for Bullseye and long term support for 3 years?
On Wed, 2020-12-30 at 14:27 +, Andrew M.A. Cater wrote: > On Mon, Dec 07, 2020 at 07:55:11PM +, Andrew M.A. Cater wrote: > > Dear release team > > > > There seems to be only one maintainer. > > > > Still true as far as I can see - others have stepped up to test i386 > executables but no more developers. > > > Is i386 going to be supportable for the next 3 1/2 years and buildable for > > that long (given that almost all machines are now 64 bit capable and we're > > having to build some packages on amd64 for i386 - per ballombe)? I would like to help. I have one "Pentium III (Katmai)" based Gateway2000 machine, with debian_etch, 384MB ram (max possible I think), ethernet, USB1.6, DVD-RW, 3.5" FDD, IDE disks; and one "VIA C7-M" Pentium M based HP 2133 netbook, Jessie installed, 512MB ram, ethernet, USB2.0, 4GB SSD, 32GB SD-card, "Express Card/54" slot, WiFi+Bluetooth; (and one working 486, running an ancient 2.0.30 kernel I compiled myself; plus some more modern machines we actually use here). I volunteer using those pentiums for testing and/or building. I have pretty good internet speeds with pretty large monthly limits here. Both pentiums can run Buster live systems (needing swapspace for DEs), and can be re-installed with any desired releases. Various external USB disks are available. I also volunteer some amount of my own time for this cause -- I have somewhat rusty but hopefully still serviceable experience coding, reviewing code, building, integrating, testing, debugging, troubleshooting. Please suggest any debian lists or IRC channels or webpages I should look at, or other steps to make myself useful. Thanks.
Re: isorecorder
On Sun, 2021-01-10 at 14:37 +0100, The7up wrote: > Hi! > > It looks like isorecorder not available since a while ago. May I remove it > from the list in w.d.o/faq/CD index page? > > At the same time, rufus (https://rufus.ie/) should be mentioned as a great > app on Windows to make bootable usb stick from iso (GNU licensing, source > code available on GitLab). > > Please cc me on the answer, I'm not a member of this list, but you can find > me on debian-www. > > Zibi If you want to recommend rufus, please do so ONLY with a prominent, un-ignoreable warning explaining that the user MUST select rufus' "DD mode" at the prompt immediately before writing the media. If you allow rufus to write in its default "ISO mode", it will replace parts of the debian image with its own recipe of loaders and configurations. I have seen many, many visitors to #debian with hard-to-diagnose installation problems which disappear after we finally discover their image was written in rufus "ISO mode" and counsel them to re-do it in "DD mode".
Re: isorecorder
On Sun, 2021-01-10 at 18:13 +0100, Thomas Schmitt wrote: > Hi, > > Lou Poppler wrote: > > If you want to recommend rufus, please do so ONLY with a prominent, > > un-ignoreable warning explaining that the user MUST select rufus' > > "DD mode" at the prompt immediately before writing the media. > > I understand that manual selection of this mode has been removed in > favor of automatic detection of dd candidates: > https://github.com/pbatard/rufus/issues/1148#issuecomment-395562137 > > I don't use Rufus myself but it is my answer to users of MS-Windows when > they ask what to do with an ISO that is bootable from USB-stick. > > > Have a nice day :) > > Thomas > Hi Thomas, Your github link references changes made in 2018. In September 2020, I tested the latest rufus on a windows system, and found that the ISO mode was still default, DD mode only an option. I corresponded with rufus's author Pete Batard, including some logs from #debian discussing my testing of rufus, and he kindly returned a lengthy response to my email. Everything below are excerpts from his email: On Thu, 1 Oct 2020, Pete Batard wrote: [...] Unfortunately, the Syslinux people have made their modules incompatible from one version to another, and you can't get a core USB/HDD Syslinux bootloader, that is compatible with the Isolinux El-Torito core bootloader, from the ISO itself, so, if the version of Isolinux used by the ISO is different from the one of the USB/HDD Syslinux that Rufus embeds, we need to download it. We will therefore prompt a dialog to do so, to let users know that Rufus is planning to download extra components from the internet. But this is a standard prompt, not an error. Now the one thing that might have thrown this user off is that Rufus always prompts to download these components BEFORE it asks to choose between ISO and DD mode, even as these components are only used for ISO mode, on account that I find it better for users to have the extra Syslinux or GRUB components needed to write in ISO mode available on their machine for subsequent runs. But I can understand how some people may *WRONGLY* assume that, if Rufus asks them to download these, then it's not going to ask them between DD and ISO mode, which is incorrect, as this is really the very next prompt. [...] Finally, I'm not sure why that user is so hell bent on using DD vs ISO. Rufus does actually recommend ISO mode over DD (which is part of the reason why I want to nudge users into downloading the extra remote Syslinux/GRUB components they need) because, if you pay attention to user reports from the internet, especially on social media sites like reddit, you will find that DD-mode image writing does often throw Windows people off, as they think that their drive has been reduced in size to just the ESP since Windows will not mount the main, larger installation partition. This, I'm afraid, is not something that Linux distro maintainers and power-users tend to see, who, I will assert, see ISOHybrid as some kind of panacea, whereas they need to realise that there really exist a lot of Windows users, who are trying to install Linux for the first time and are not familiar with file systems and partitioning that assume, when seeing that the Linux USB they just wrote has apparently been "reduced" to a 16 or 32 MB ESP, that there is an issue with their boot media and do not proceed to attempt installation as a result (a bit like the user below assuming that if they are prompted for files that apply for ISO mode, then it must mean that Rufus will not prompt them for DD mode, which is incorrect). And since I believe that this is ultimately damaging with regards to helping people try Debian or other Linux distros, this is why Rufus tends to recommend ISO mode over DD mode. I therefore have to stress out that distros that are concerned about helping Windows users try or install Linux in the best conditions not put all their eggs in the ISOHybrid "DD" basket, but also ensure that their live or installer system can function with a single FAT32 partition (which, thankfully, the Debian and Ubuntu maintainers seem to readily understand, as far as I can see). So, to summarise: - The DD vs ISO prompt is there. But it only appears after the download Syslinux component prompt, and will obviously not show if you cancel the whole operation on the first prompt. So far, I've had very few reports of users being thrown off by this. [...]
Re: isorecorder
On Sun, 2021-01-10 at 20:19 +, Pete Batard wrote: > > The goal of Rufus is to create a bootable USB with content that is as > close as possible to the ISO content *AND* is bootable as USB media, period. > > As such, when booting in UEFI mode, the *only* element that Rufus may > modify are the labels used in the GRUB/Syslinux config files (kernel > option) for source media lookup, to accommodate FAT32 limitations on > that matter (since FAT limits labels to 11 uppercase characters, and ISO > volumes can and usually do use labels with much longer names). > > Apart from this, everything else is a binary identical copy of the ISO > content, which you can easily validate if needed. > > Then, for BIOS mode, we of course need to install GRUB or Syslinux > bootloaders, which can't come from the ISO but which we produce from > vanilla official releases, [...] Let me emphasize that the unmodified debian installer images, when copied to a USB stick via (unix) dd or cp, boot just fine in both UEFI mode and BIOS mode. They also work just fine when copied unmodified to a CD or DVD.
[Fwd: Re: isorecorder]
Forwarded Message
From: Lou Poppler
To: Pete Batard
Subject: Re: isorecorder
Date: Sun, 10 Jan 2021 18:20:55 -0700
On Sun, 2021-01-10 at 23:57 +, Pete Batard wrote:
> On 2021.01.10 22:23, Lou Poppler wrote:
> > Let me emphasize that the unmodified debian installer images, when copied
> > to a
> > USB stick via (unix) dd or cp, boot just fine in both UEFI mode and BIOS
> > mode.
> > They also work just fine when copied unmodified to a CD or DVD.
> >
>
> I'm afraid I have to disagree with this, from direct empirical evidence.
>
> This is a test I conducted a few moments ago, using the latest AMD64
> netinst testing image (dated 2021.01.09). I didn't use Rufus to create
> the bootable media but instead did it on Linux (up to date Armbian on an
> RK3399 platform) with the exact set of commands below:
You download a testing .iso
then you make a fresh MS vfat partition on sda1
then you rsync [some of] the .iso onto this partition.
Then you have problems booting from this USB.
-
This is radically different from what I suggested above.
Here is my experiment:
lwp@william:~/Downloads$ wget
https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso
lwp@william:~/Downloads$ umount /dev/sdb1
lwp@william:~/Downloads$ sudo bash
root@william:/home/lwp/Downloads# cp debian-testing-amd64-netinst.iso /dev/sdb
root@william:/home/lwp/Downloads#sync
At this point I moved the USB stick to a Toshiba amd64 laptop,
and booted with no problems into the installer.
Notice especially that I did *not* copy the installer .iso onto a partition of
the USB stick,
I copied the image to the bare USB i.e. /dev/sdb _NOT_ /dev/sdb1
Here is what that USB stick looks like now:
root@william:/home/lwp/Downloads# fdisk /dev/sdb
Welcome to fdisk (util-linux 2.29.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/sdb: 14.3 GiB, 15376318464 bytes, 30031872 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5c546723
Device Boot StartEnd Sectors Size Id Type
/dev/sdb1 *0 745471 745472 364M 0 Empty
/dev/sdb23944 98635920 2.9M ef EFI (FAT-12/16/32)
Command (m for help): q
root@william:/home/lwp/Downloads#
[below is the remainder of your procedure]:
> -
>
> root@nano:/mnt/ssd# wget
> https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso
> root@nano:/mnt/ssd# mount -o loop debian-testing-amd64-netinst.iso /mnt/iso
> mount: /mnt/iso: WARNING: device write-protected, mounted read-only.
> root@nano:/mnt/ssd# dd if=/dev/zero of=/dev/sda bs=512 count=34
> 34+0 records in
> 34+0 records out
> 17408 bytes (17 kB, 17 KiB) copied, 0.0113974 s, 1.5 MB/s
> root@nano:/mnt/ssd# dd if=/dev/zero of=/dev/sda bs=512 count=34
> seek=$((`blockdev --getsz /dev/sda` - 34))
> 34+0 records in
> 34+0 records out
> 17408 bytes (17 kB, 17 KiB) copied, 0.0144371 s, 1.2 MB/s
> root@nano:/mnt/ssd# gdisk /dev/sda
> GPT fdisk (gdisk) version 1.0.3
>
> Partition table scan:
>MBR: not present
>BSD: not present
>APM: not present
>GPT: not present
>
> Creating new GPT entries.
>
> Command (? for help): n
> Partition number (1-128, default 1): 1
> First sector (34-234441614, default = 2048) or {+-}size{KMGTP}:
> Last sector (2048-234441614, default = 234441614) or {+-}size{KMGTP}:
> Current type is 'Linux filesystem'
> Hex code or GUID (L to show codes, Enter = 8300): 0700
> Changed type of partition to 'Microsoft basic data'
>
> Command (? for help): w
>
> Final checks complete. About to write GPT data. THIS WILL OVERWRITE
> EXISTING PARTITIONS!!
>
> Do you want to proceed? (Y/N): Y
> OK; writing new GUID partition table (GPT) to /dev/sda.
> The operation has completed successfully.
> root@nano:/mnt/ssd# mkfs.vfat /dev/sda1
> mkfs.fat 4.1 (2017-01-24)
> root@nano:/mnt/ssd# mount /dev/sda1 /mnt/hd
> root@nano:/mnt/ssd# rsync -av /mnt/iso/ /mnt/hd
> sending incremental file list
> rsync: symlink "/mnt/hd/debian" -> "." failed: Operation not permitted (1)
> ./
> README.html
> README.mirrors.html
> README.mirrors.txt
> README.source
> README.txt
> autorun.inf
> g2ldr
> g2ldr.mbr
> md5sum.txt
> setup.exe
> win32-loader.ini
> rsync: symlink "/mnt/hd/dists/testing" -> "bullseye" failed: Operation
> not permitted (1)
> rsync: symlink "/mnt/hd/doc/FAQ/html/basic-defs.h
Re: [Fwd: Re: isorecorder]
On Mon, 2021-01-11 at 02:21 +, Pete Batard wrote: > On 2021.01.11 01:38, Lou Poppler wrote: > > This is radically different from what I suggested above. > > You mentioned cp, which I interpreted as copying extracted ISO files > onto FAT, since this is the mode I explicitly mentioned in my initial reply. > > > Here is my experiment: > > lwp@william:~/Downloads$ wget > > https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso > > lwp@william:~/Downloads$ umount /dev/sdb1 > > lwp@william:~/Downloads$ sudo bash > > root@william:/home/lwp/Downloads# cp debian-testing-amd64-netinst.iso > > /dev/sdb > > root@william:/home/lwp/Downloads#sync > > > > At this point I moved the USB stick to a Toshiba amd64 laptop, > > and booted with no problems into the installer. > > > > Notice especially that I did *not* copy the installer .iso onto a partition > > of the USB stick, > > I copied the image to the bare USB i.e. /dev/sdb _NOT_ /dev/sdb1 > > Which means that you are limiting ISOHybrid use to DD/byte-copy mode > only, which is precisely what I am trying to warn against relying solely on. > > A *proper* ISOHybrid media should be able to be extracted to a FAT32 > formatted partition and boot in UEFI mode. The media we are discussing, debian-testing-amd64-netinst.iso, as copied to my USB stick and booted in BIOS mode on the Toshiba laptop, also boots just fine on this dell amd64 box in UEFI mode. I will stipulate that there may be other architectures or devices which do not work the same as amd64 desktops/laptops. However, in all the varieties of testing I have done on amd64 desktops/laptops, the direct byte-for-byte copying of the installation image onto the base of a USB stick works properly in both BIOS booting and UEFI booting. Perhaps more complicated schemes are needed for other situations, I agree that is possible. I am only trying to explain why I always suggest to amd64 users, on the general #debian IRC channel, that they should directly copy the downloaded image to their USB stick with dd or cp (as you saw in my example previous) or with rufus's DD mode. In this standard situation, any other method of writing the USB stick causes hard to debug problems.
Re: Debian 10.8 live install ENCRYPTION NOT WORKING
It looks like this is the same person who posted the following two youtube URLs into #debian today. https://www.youtube.com/watch?v=7CuJJzn0Mgg https://www.youtube.com/watch?v=8MfKm9zTl-0 If you have documented a problem in debian, please report a "bug" using debian's Bug Tracking System -- http://wiki.debian.org/HowtoUseBTS If you need help getting something to work, visit the IRC channel again, and discuss your problem with the knowledgeable people there. On Fri, 2021-03-12 at 07:19 +0100, Jean-René Dantin Ph.D. wrote: > We have confirmed Debian 10.8 live install ENCRYPTION NOT WORKING on bare > metal on two different machines and in VM. Please have a look at: > > Debian 10 live install NOT WORKING no comment > > https://www.youtube.com/watch?v=dteJXwco4zE > > Hope you appreciate our work. > Stay safe.
D-I on i386 live ISO can't mount squashfs
This is a more detailed do-over of a failed install I encountered earlier today while testing debian-live-10.9.0-i386-cinnamon+nonfree.iso during the 10.9 release testing party on #debian-cd. At the time, we thought this problem comes from not enough memory on the target machine, which is a Gateway Pentium III, with 384 MB of RAM. On this do-over, I frequently checked the output of 'free' on VC2, and never saw the free memory drop below 200,000 bytes. I manually added swap from /dev/sdb1 at time 02:15; the installer declared "Low memory mode" and automatically added swap from /dev/sda3 at time 03:14; but from watching the output of 'free' I don't think any swap was ever used. Below is the complete syslog from the failed install (the last few lines about /dev/sdc are the USB stick I used to copy out the syslog). At the point I copied out the syslog to USB, 'free' told me this: FreeTotal UsedFree MEM 378196 32740 245888 SWAP1959888 0 1959888 I probably should make this into a bug report, but I don't know what package to complain about. Any guidance would be welcome. That installer is still sitting there on the Pentium, a red background screen "Installation step failed". I can poke it further if anyone has suggestions, or I can rerun the installer with any suggested variations. Here is the syslog, from selecting D-I text mode from the Live image on DVD: Mar 28 02:15:17 syslogd started: BusyBox v1.30.1 Mar 28 02:15:17 kernel: klogd started: BusyBox v1.30.1 (Debian 1:1.30.1-4) Mar 28 02:15:17 kernel: [0.00] Linux version 4.19.0-16-686 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.181-1 (2021-03-19) Mar 28 02:15:17 kernel: [0.00] x86/fpu: x87 FPU will use FXSAVE Mar 28 02:15:17 kernel: [0.00] BIOS-provided physical RAM map: Mar 28 02:15:17 kernel: [0.00] BIOS-e820: [mem 0x-0x0009f3ff] usable Mar 28 02:15:17 kernel: [0.00] BIOS-e820: [mem 0x0009f400-0x0009] reserved Mar 28 02:15:17 kernel: [0.00] BIOS-e820: [mem 0x000e7000-0x000f] reserved Mar 28 02:15:17 kernel: [0.00] BIOS-e820: [mem 0x0010-0x040fd7ff] usable Mar 28 02:15:17 kernel: [0.00] BIOS-e820: [mem 0x040fd800-0x040ff7ff] ACPI data Mar 28 02:15:17 kernel: [0.00] BIOS-e820: [mem 0x040ff800-0x040ffbff] ACPI NVS Mar 28 02:15:17 kernel: [0.00] BIOS-e820: [mem 0x040ffc00-0x17ff] usable Mar 28 02:15:17 kernel: [0.00] BIOS-e820: [mem 0xfffe7000-0x] reserved Mar 28 02:15:17 kernel: [0.00] Notice: NX (Execute Disable) protection missing in CPU! Mar 28 02:15:17 kernel: [0.00] SMBIOS 2.1 present. Mar 28 02:15:17 kernel: [0.00] DMI: Gateway /WS440BX, BIOS 4W4SB0X0.15A.0015.P10 09/28/1999 Mar 28 02:15:17 kernel: [0.00] tsc: Fast TSC calibration using PIT Mar 28 02:15:17 kernel: [0.00] tsc: Detected 596.919 MHz processor Mar 28 02:15:17 kernel: [0.027428] e820: update [mem 0x-0x0fff] usable ==> reserved Mar 28 02:15:17 kernel: [0.027442] e820: remove [mem 0x000a-0x000f] usable Mar 28 02:15:17 kernel: [0.027470] last_pfn = 0x18000 max_arch_pfn = 0x10 Mar 28 02:15:17 kernel: [0.027502] MTRR default type: uncachable Mar 28 02:15:17 kernel: [0.027508] MTRR fixed ranges enabled: Mar 28 02:15:17 kernel: [0.027518] 0-9 write-back Mar 28 02:15:17 kernel: [0.027526] A-B uncachable Mar 28 02:15:17 kernel: [0.027533] C-C7FFF write-protect Mar 28 02:15:17 kernel: [0.027541] C8000-D uncachable Mar 28 02:15:17 kernel: [0.027548] E-F write-protect Mar 28 02:15:17 kernel: [0.027553] MTRR variable ranges enabled: Mar 28 02:15:17 kernel: [0.027563] 0 base 0 mask FF000 write-back Mar 28 02:15:17 kernel: [0.027572] 1 base 01000 mask FF800 write-back Mar 28 02:15:17 kernel: [0.027578] 2 disabled Mar 28 02:15:17 kernel: [0.027583] 3 disabled Mar 28 02:15:17 kernel: [0.027588] 4 disabled Mar 28 02:15:17 kernel: [0.027593] 5 disabled Mar 28 02:15:17 kernel: [0.027598] 6 disabled Mar 28 02:15:17 kernel: [0.027604] 7 disabled Mar 28 02:15:17 kernel: [0.029266] x86/PAT: PAT not supported by CPU. Mar 28 02:15:17 kernel: [0.030092] x86/PAT: Configuration [0-7]: WB WT UC- UC WB WT UC- UC Mar 28 02:15:17 kernel: [0.100290] initial memory mapped: [mem 0x-0x10ff] Mar 28 02:15:17 kernel: [0.100622] RAMDISK: [mem 0x16f85000-0x17ff] Mar 28 02:15:17 kernel: [0.100659] ACPI: Early table checksum verification disabled Mar 28 02:15:17 kernel: [0.101283] ACPI: RSDP 0x000F6AC0 14 (v00 PTLTD ) Mar 28 02:15:17 kernel: [0.101308] ACPI: RSDT 0x040FDA87 28 (v01 PTLTDRSDT 000
Re: D-I on i386 live ISO can't mount squashfs
On Sat, 2021-03-27 at 22:42 -0700, Lou Poppler wrote: > [...] the target machine, which is a Gateway Pentium III, > with 384 MB of RAM. On this do-over, I frequently checked the output of > 'free' > on VC2, and never saw the free memory drop below 200,000 bytes. Perhaps obviously, I should have written 200,000 KB, not bytes. > Free Total UsedFree > MEM 378196 32740 245888 > SWAP 1959888 0 1959888 > > I probably should make this into a bug report, but I don't know what package > to > complain about. Any guidance would be welcome.
Re: D-I on i386 live ISO can't mount squashfs
On Mon, 2021-03-29 at 20:16 +0200, J.A. Bezemer wrote: > On Sat, 27 Mar 2021, Lou Poppler wrote: > > > This is a more detailed do-over of a failed install I encountered earlier > > today > > while testing debian-live-10.9.0-i386-cinnamon+nonfree.iso during the 10.9 > > release testing party on #debian-cd. > [...] > > > Mar 28 03:15:07 main-menu[228]: INFO: Menu item 'live-installer' selected > > Mar 28 03:15:17 base-installer: info: Using squashfs support for > > /cdrom/live/filesystem.squashfs > > Mar 28 03:15:17 anna-install: Installing squashfs-modules > > Mar 28 03:15:17 anna[10712]: DEBUG: retrieving > > squashfs-modules-4.19.0-16-686-di 4.19.181-1 > > Mar 28 03:15:18 kernel: [ 3613.491313] squashfs: version 4.0 (2009/01/31) > > Phillip Lougher > > Mar 28 03:15:18 base-installer: error: /cdrom/live/filesystem.squashfs has > > failed to be mounted as squashfs. > > Mar 28 03:15:18 main-menu[228]: (process:10659): modprobe: FATAL: Module > > loop not found in directory /lib/modules/4.19.0-16-686 > > Mar 28 03:15:18 main-menu[228]: (process:10659): mount: can't setup loop > > device: No such device or address > > Mar 28 03:15:18 main-menu[228]: WARNING **: Configuring 'live-installer' > > failed with error code 1 > > Mar 28 03:15:18 main-menu[228]: WARNING **: Menu item 'live-installer' > > failed. > > The problem seems to be that no loop module is available, so the squashfs > can't be loop-mounted from the file on the installer medium. Did the > loop-modules-4.19.0-16-686-di package get lost somewhere? > > Best regards, > Anne Bezemer I don't see it in there, but searching is tedious in busybox (for example no recursive option in ls ?). Here is some sneakernet output from that installer, still running at the same point as before. Other suggestions for searching happily welcomed. ls -al /lib/modules drwxr-xr-x3 root root60 Mar 19 14:29 . drwxr-xr-x 18 root root 1280 Mar 19 14:29 .. drwxr-xr-x3 root root 280 Mar 28 03:15 4.19.0-16-686 ls -al /lib/modules/4.19.0-16-686/ drwxr-xr-x3 root root 280 Mar 28 03:15 . drwxr-xr-x3 root root60 Mar 19 14:29 .. drwxr-xr-x7 root root 140 Mar 19 14:29 kernel -rw-r--r--1 root root 91582 Mar 28 03:15 modules.alias -rw-r--r--1 root root 8 Mar 28 03:15 modules.alias.bin -rw-r--r--1 root root 4417 Mar 19 14:29 modules.builtin -rw-r--r--1 root root 5829 Mar 28 03:15 modules.builtin.bin -rw-r--r--1 root root 20699 Mar 28 03:15 modules.dep -rw-r--r--1 root root 32618 Mar 28 03:15 modules.dep.bin -rw-r--r--1 root root 150 Mar 28 03:15 modules.devname -rw-r--r--1 root root145963 Mar 19 14:29 modules.order -rw-r--r--1 root root 226 Mar 28 03:15 modules.softdep -rw-r--r--1 root root113692 Mar 28 03:15 modules.symbols -rw-r--r--1 root root135364 Mar 28 03:15 modules.symbols.bin ls -al /lib/modules/4.19.0-16-686/kernel drwxr-xr-x7 root root 140 Mar 19 14:29 . drwxr-xr-x3 root root 280 Mar 28 03:15 .. drwxr-xr-x3 root root 380 Mar 28 03:03 crypto drwxr-xr-x 30 root root 600 Mar 28 03:07 drivers drwxr-xr-x 14 root root 300 Mar 28 03:15 fs drwxr-xr-x4 root root 260 Mar 28 03:03 lib drwxr-xr-x 10 root root 200 Mar 28 03:03 net ls -al /lib/modules/4.19.0-16-686/kernel/fs drwxr-xr-x 14 root root 300 Mar 28 03:15 . drwxr-xr-x7 root root 140 Mar 19 14:29 .. drwxr-xr-x2 root root60 Mar 28 03:03 btrfs drwxr-xr-x2 root root60 Mar 22 07:28 configfs drwxr-xr-x2 root root60 Mar 28 03:03 crypto drwxr-xr-x2 root root60 Mar 28 03:03 efivarfs drwxr-xr-x2 root root60 Mar 28 03:03 ext4 drwxr-xr-x2 root root80 Mar 22 07:28 fat drwxr-xr-x2 root root60 Mar 22 07:28 isofs drwxr-xr-x2 root root60 Mar 28 03:03 jbd2 drwxr-xr-x2 root root60 Mar 28 03:03 jfs -rw-r--r--1 root root 12131 Mar 19 14:29 mbcache.ko drwxr-xr-x2 root root 100 Mar 22 07:28 nls drwxr-xr-x2 root root60 Mar 28 03:15 squashfs drwxr-xr-x2 root root60 Mar 28 03:03 xfs ls -al /lib/modules/4.19.0-16-686/kernel/fs/squashfs drwxr-xr-x2 root root60 Mar 28 03:15 . drwxr-xr-x 14 root root 300 Mar 28 03:15 .. -rw-r--r--1 root root 64603 Mar 19 14:29 squashfs.ko ls -al /lib/modules/4.19.0-16-686/kernel/fs/isofs drwxr-xr-x2 root root60 Mar 22 07:28 . drwxr-xr-x 14 root root 300 Mar 28 03:15 .. -rw-r--r--1 root root 46655 Mar 19 14:29 isofs.ko
Re: D-I on i386 live ISO can't mount squashfs
On Mon, 2021-03-29 at 20:16 +0200, J.A. Bezemer wrote: > > The problem seems to be that no loop module is available, so the squashfs > can't be loop-mounted from the file on the installer medium. Did the > loop-modules-4.19.0-16-686-di package get lost somewhere? Update: Steve McIntyre spent some time on IRC helping to debug this. The problem is "Low Memory" mode getting too aggressive kicking out components from the RAM FS, including that loop module. We found a low-mem menu that is supposed to load and keep that module (and others) but it doesn't seem to be working correctly right now. I even anna-install'ed the module again from the network on one attempt, but the installer couldn't find it anymore. Just to be clear, we are talking here about trying to use the text-mode installer from the boot menu of a buster debian-live ISO image. I'm trying to take a look at the lowmem code now.
Re: D-I on i386 live ISO can't mount squashfs
On Mon, 2021-03-29 at 18:40 -0700, Lou Poppler wrote: > On Mon, 2021-03-29 at 20:16 +0200, J.A. Bezemer wrote: > > > > The problem seems to be that no loop module is available, so the squashfs > > can't be loop-mounted from the file on the installer medium. Did the > > loop-modules-4.19.0-16-686-di package get lost somewhere? > > Update: Steve McIntyre spent some time on IRC helping to debug this. > The problem is "Low Memory" mode getting too aggressive kicking out components > from the RAM FS, including that loop module. We found a low-mem menu that is > supposed to load and keep that module (and others) but it doesn't seem to be > working correctly right now. I even anna-install'ed the module again from the > network on one attempt, but the installer couldn't find it anymore. > > Just to be clear, we are talking here about trying to use the text-mode > installer from the boot menu of a buster debian-live ISO image. > I'm trying to take a look at the lowmem code now. > loop.ko is in /lib/modules/4.19.0-16-686/kernel/drivers/block/ which is deleted by the following aggressive code in lowmem-1.47/partman/init.d/05lowmem_modules - #!/bin/sh set -e if [ ! -e /var/lib/lowmem ]; then exit 0 fi # Let's not delete anything yet if no discs have been found if [ "$(list-devices disk)" ]; then if cd /lib/modules/*/kernel/drivers; then rm -rf net cdrom ide ieee1394 input scsi usb video parport block fi fi -- I defeated this by removing /var/lib/lowmem at VC2 before partman, and this allowed the installer to find the loop.ko module. However it failed soon after: Mar 30 14:17:22 kernel: [ 1004.240890] Adding 979960k swap on /dev/sda3. Priority:-3 extents:1 across:979960k FS Mar 30 14:17:23 kernel: [ 1005.647027] EXT4-fs (sda8): mounted filesystem with ordered data mode. Opts: errors=remount-ro Mar 30 14:17:23 kernel: [ 1005.700346] EXT4-fs (sda1): mounting ext3 file system using the ext4 subsystem Mar 30 14:17:23 kernel: [ 1005.871947] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) Mar 30 14:17:25 apt-install: Queueing package e2fsprogs for later installation Mar 30 14:17:26 main-menu[227]: INFO: Falling back to the package description for brltty-udeb Mar 30 14:17:26 main-menu[227]: INFO: Falling back to the package description for brltty-udeb Mar 30 14:17:26 main-menu[227]: INFO: Menu item 'live-installer' selected Mar 30 14:17:28 base-installer: info: Using squashfs support for /cdrom/live/filesystem.squashfs Mar 30 14:17:28 anna-install: Installing squashfs-modules Mar 30 14:17:28 anna[8759]: ERROR **: can't find packages file Mar 30 14:17:29 kernel: [ 1011.708557] loop: module loaded Mar 30 14:17:29 base-installer: error: /cdrom/live/filesystem.squashfs has failed to be mounted as squashfs. Mar 30 14:17:29 main-menu[227]: (process:8706): modprobe: FATAL: Module squashfs not found in directory /lib/modules/4.19.0-16-686 Mar 30 14:17:29 main-menu[227]: (process:8706): mount: mounting /dev/loop0 on /mnt failed: No such device -- I need to investigate more with this. At the failure point above, free RAM is 212100 KB. What I am leaning toward suggesting is to modify the code in lowmem-1.47/debian-installer-startup.d/S15lowmem to allow the user to set lowmem=0 on the installer command line (and add more detail to the install manual documentation of lowmem).
Re: D-I on i386 live ISO can't mount squashfs
On Tue, 2021-03-30 at 09:38 -0700, Lou Poppler wrote: [...] > Mar 30 14:17:28 base-installer: info: Using squashfs support for > /cdrom/live/filesystem.squashfs > Mar 30 14:17:28 anna-install: Installing squashfs-modules > Mar 30 14:17:28 anna[8759]: ERROR **: can't find packages file > Mar 30 14:17:29 kernel: [ 1011.708557] loop: module loaded > Mar 30 14:17:29 base-installer: error: /cdrom/live/filesystem.squashfs has > failed to be mounted as squashfs. > Mar 30 14:17:29 main-menu[227]: (process:8706): modprobe: FATAL: Module > squashfs not found in directory /lib/modules/4.19.0-16-686 > Mar 30 14:17:29 main-menu[227]: (process:8706): mount: mounting /dev/loop0 on > /mnt failed: No such device > > -- > I need to investigate more with this. At the failure point above, free RAM is > 212100 KB. What I am leaning toward suggesting is to modify the code in > lowmem-1.47/debian-installer-startup.d/S15lowmem > to allow the user to set lowmem=0 on the installer command line > (and add more detail to the install manual documentation of lowmem). For comparison, I ran the same installer from the same debian-live-10.9.0-i386-cinnamon+nonfree.iso image copied to a USB stick, on the i686 netbook with 512 MB RAM. It installed OK, with no drama, and boots to the cinnamon desktop now.
